Posted by
Janko Mivšek on
Jan 27, 2012; 2:24pm
URL: https://forum.world.st/Tutorial-bug-with-preferedUrl-tp4332983p4333616.html
Hi Bob,
S, BobCalco piše:
> Another point. :)
>
> I don't like that "URLResolver default changeToPreferedURL:" requires
> a domain object to implement preferedUrl.
>
> URLResolver changeToPreferredURL should take a "plain ol'" domain
> object -- say, MyDomainObject -- and look for a corresponding
> MyDomainObjectApp (as happens anyway in the view subsystem). Then it
> should call MyDomainObjectApp>>preferredUrlFor: aMyDomainObject. It's
> the app's job to know about URLs, not the domain object's, in my
> opinion.
Aida implemented the "every domain object should have its own URL" idea,
coined also by Alan Kay back in 1997. So, URL is object's "address". As
my address is my "property", so the object's URL is its property too and
not from someone else. This is a main idea behind Aida and that's why
#preferedUrl method is in domain object, not on the Aida App side or
somewhere else.
> Not finding a MyDomainObjectApp>>preferredUrlFor: aMyDomainObject, it
> could then just default to the current naming scheme.
This actually happens. Object's URL is defined automatically in form
/object/123345 if object itself does not give some clue in #preferedUrl
what URL it likes to have.
> This is an interesting area in general as I like the RESTful way of
> nesting resources. Such nesting can get out of hand if taken too
> deeply but in any case this kind of thing needs to be negotiated
> between Apps (whose nesting can be implied by the relationships
> between domain objects, really) and not in any way codified in the
> domain objects themselves.
You probably mean nesting URLs, like /first/second/third-level ?
Note that Aida has a flat two-way mapping between objects and their
URLs. And you can nest URLs as you like, this is not a duty of Aida.
Why two-way mapping? URL->object is obvious to route the web request to
a proper domain object while object->URL is Aida specific feature to
make web apps very navigable. It is namely very easy to make some link
simply by pointing to that domain object. See back links in tutorial for
an example.
Why flat mapping? One strong reason is to be free from a way of
structuring/nesting your URL. Disadvantage is that that flat table
cannot be too big, up to 100K entries re acceptable. Reason is hashing
performance in two dictionaries in URLResolver
> This is where a metadata framework like Magritte for Seaside would
> come in handy in Aida. :)
There is actually such framework in work, just not on that field and it
probably won't be :)
Best regards
Janko
> On Jan 27, 10:08 am, Robert Calco <
[hidden email]> wrote:
>> I have implemented the Aida tutorial but notice a quirk when adding new
>> entries, namely, the URL of the new object is always "-c". For example, if
>> you add 'Jack', 'Beanstalk', '1234567890', '
[hidden email]', the URL of
>> the new entity is '/address/-c'. It seems to me it should generate
>> correctly the URL '/address/beanstalk' instead.
>>
>> In order to fix the situation I have to run
>>
>> book addresses do: [ :each | URLResolver default changeToPreferedURL: each
>> ].
>>
>> ... (fortunately I have the 'book' reference in my transcript which I don't
>> dare lose). Then everybody's URL is right.
>>
>> - Bob
>>
>> _______________________________________________
>> Aida mailing list
>>
[hidden email]://lists.aidaweb.si/mailman/listinfo/aida
> _______________________________________________
> Aida mailing list
>
[hidden email]
>
http://lists.aidaweb.si/mailman/listinfo/aida>
--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si_______________________________________________
Aida mailing list
[hidden email]
http://lists.aidaweb.si/mailman/listinfo/aida