2012/1/27 Janko Mivšek
<[hidden email]>
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 required.
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 instances.
> 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.
K.
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% rule.
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