[aida] URL to object mapping (was Tutorial bug with preferedUrl?)
bobcalco at gmail.com
Fri Jan 27 17:16:31 CET 2012
2012/1/27 Janko Mivšek <janko.mivsek at eranova.si>
> Hi Bob,
> 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.
An object's 'address' is one thing, but there are many paths to it,
relative to the other objects in its universe (domain).
I think of URI as it's address and URLs (plural) as paths to it from some
object's relative location.
In my opinion, an object's address is metadata, not data, and an object
need (and arguably should) not have knowledge of any particular URL scheme
-- nested, flat or otherwise.
I suppose you can say it has one URI, but one to many URLs. The URI is the
object at it's root location, and the rest are referenceUrls. The URI may
be intrinsic and something the object should know, but the rest I think
should be decoupled from any particular URL scheme.
My idealistic goal is a data model that can be plug-n-play with whatever UI
(web or desktop) or persistence layer I need.
This gets harder to do when you start needing to have the models themselves
implement stuff that really is used to render or manipulate them in
specific frameworks or platforms. I want all the fiddling of this kind of
thing in a different layer, so the model is unaffected by such variables as
persistence or presentation framework.
> > 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.
I really wish it was more dynamic and a call to URLResolver was not
To recapitulate: It's not working properly in the tutorial... I'm not
getting object/12345 or the scheme I require when I save a new ADemoAddress
> > 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.
Well I agree it shouldn't be Aida's job. Which is why I'm seeking a
metadata solution as the middle man.
> 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
I'm sorry... is this a disadvantage of flat mapping? If so, is this a
performance constraint for Aida?
> > 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 :)
Well a metadata framework should be generic anyway, no?
I'm just saying I'd like an interface so that Aida can give me the ability
to decide on my mapping, and maybe supply a couple defaults for the 80%
> Best regards
> > On Jan 27, 10:08 am, Robert Calco <bobca... at gmail.com> 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,
> >> you add 'Jack', 'Beanstalk', '1234567890', 'j... at beanstalk.com', 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:
> >> ].
> >> ... (fortunately I have the 'book' reference in my transcript which I
> >> dare lose). Then everybody's URL is right.
> >> - Bob
> >> _______________________________________________
> >> Aida mailing list
> >> A... at aidaweb.sihttp://lists.aidaweb.si/mailman/listinfo/aida
> > _______________________________________________
> > Aida mailing list
> > Aida at aidaweb.si
> > http://lists.aidaweb.si/mailman/listinfo/aida
> Janko Mivšek
> Smalltalk Web Application Server
> Aida mailing list
> Aida at aidaweb.si
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Aida