Tutorial bug with preferedUrl?
Locked
 
|
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] http://lists.aidaweb.si/mailman/listinfo/aida |
|
|
Oh, I omitted to mention that I dispensed with the '.html' part in the
tutorial. So my preferedUrl looks like: preferedUrl ^ '/address/', self surname Also, I note there is a mismatch between parts of the tutorial that use surname and parts that use lastName. I opted for surname all the way through in my implementation. :) - Bob 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 |
|
|
In reply to this post by bobcalco
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. Not finding a MyDomainObjectApp>>preferredUrlFor: aMyDomainObject, it could then just default to the current naming scheme. 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. This is where a metadata framework like Magritte for Seaside would come in handy in Aida. :) - Bob 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 |
URL to object mapping (was Tutorial bug with preferedUrl?)
|
|
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 |
|
|
Hi Janko,
:)
2012/1/27 Janko Mivšek <[hidden email]> Hi Bob, 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.
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.
Well I agree it shouldn't be Aida's job. Which is why I'm seeking a metadata solution as the middle man.
K.
I'm sorry... is this a disadvantage of flat mapping? If so, is this a performance constraint for Aida?
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.
_______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
URL duplicates (was Tutorial bug with preferedUrl?)
|
|
In reply to this post by bobcalco
S, Robert Calco piše:
> 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] > <mailto:[hidden email]>', the URL of the new entity is > '/address/-c'. It seems to me it should generate correctly the URL > '/address/beanstalk' instead. This is how duplicates of URLs are resolved. If you see '-a', '-b', '-c' etc, in URLs, then you certainly have an URL duplicate situation. URL duplicate situation arises when two or more objects suggest the same URL by their #preferedUrl method. When an address is created (by an App), we don't know name and surname yet, but Aida already needs his URL. So his #preferedUrl returns '/address/'. and because the previous one already registered this URL, Aida resolvs the duplicate by registering '/address/-a'. > In order to fix the situation I have to run > > book addresses do: [ :each | URLResolver default changeToPreferedURL: > each ]. Another possibility is to change new person URL after adding it to the address book, because at that point name and surname is entered. I just updated the tutorial adding and explaining changeToPreferedURL: for this case. > ... (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] > 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 |
|
|
Janko,
2012/1/27 Janko Mivšek <[hidden email]> S, Robert Calco piše: This makes sense except for one thing: I don't have any duplicates with surname 'Beanstalk' that would have conflicted. I get -c no matter what I add. And all is well when I run the URLResolver code; if there were a duplicate, then running that should not change matters.
This is another area of interest, as 'the one and only URI' of an object should be guaranteed unique, in terms of the object itself, but it could have any number of URLs that are defined by its relationships with other objects.
Thanks Janko... - Bob
_______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
|
|
Janko,
You must have been right, because adding modifying actionAdd to: ADemoAddressApp>>actionAdd self observee parent addAddress: self observee.
self site urlResolver changeToPreferedURL: self observee. self redirectToView: #main.
...works; but I don't understand why there would have been a duplicate conflict. Incidentally, the update to the tutorial page lost the formatting for code samples, such that nearly all of them show no indenting (most lines in code samples start at col 0).
- Bob
On Fri, Jan 27, 2012 at 6:02 PM, Robert Calco <[hidden email]> wrote: Janko, _______________________________________________ Aida mailing list [hidden email] http://lists.aidaweb.si/mailman/listinfo/aida |
Re: URL duplicates (was Tutorial bug with preferedUrl?)
|
|
Hi Bobo,
S, Robert Calco piše: > You must have been right, because adding modifying actionAdd to: > > ADemoAddressApp>>actionAdd > self observee parent addAddress: self observee. > *self site urlResolver changeToPreferedURL: self observee.* > self redirectToView: #main. > > ...works; but I don't understand why there would have been a duplicate > conflict. When you were redirected to empty address form, Aida needed an URL already and because you didn't have a chance to enter surname yet, a duplicate situation occurred. > > Incidentally, the update to the tutorial page lost the formatting for > code samples, such that nearly all of them show no indenting (most lines > in code samples start at col 0). Yes, that damn TinyMCE editor doesn't edit preformated text corectly and loosing spaces. I'm just raw editing raw HTML to restore formatting... Janko > On Fri, Jan 27, 2012 at 6:02 PM, Robert Calco <[hidden email] > <mailto:[hidden email]>> wrote: > > Janko, > > 2012/1/27 Janko Mivšek <[hidden email] > <mailto:[hidden email]>> > > S, Robert Calco piše: > > 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] <mailto:[hidden email]> > > <mailto:[hidden email] <mailto:[hidden email]>>', the > URL of the new entity is > > '/address/-c'. It seems to me it should generate correctly the URL > > '/address/beanstalk' instead. > > This is how duplicates of URLs are resolved. If you see '-a', > '-b', '-c' > etc, in URLs, then you certainly have an URL duplicate situation. > > URL duplicate situation arises when two or more objects suggest > the same > URL by their #preferedUrl method. > > > This makes sense except for one thing: I don't have any duplicates > with surname 'Beanstalk' that would have conflicted. I get -c no > matter what I add. And all is well when I run the URLResolver code; > if there were a duplicate, then running that should not change matters. > > This is another area of interest, as 'the one and only URI' of an > object should be guaranteed unique, in terms of the object itself, > but it could have any number of URLs that are defined by its > relationships with other objects. > > > > When an address is created (by an App), we don't know name and > surname > yet, but Aida already needs his URL. So his #preferedUrl returns > '/address/'. and because the previous one already registered > this URL, > Aida resolvs the duplicate by registering '/address/-a'. > > > In order to fix the situation I have to run > > > > book addresses do: [ :each | URLResolver default > changeToPreferedURL: > > each ]. > > Another possibility is to change new person URL after adding it > to the > address book, because at that point name and surname is entered. > > I just updated the tutorial adding and explaining > changeToPreferedURL: > for this case. > > > Thanks Janko... > > - Bob > > > > > > > > > > > > > _______________________________________________ > > Aida mailing list > > [hidden email] <mailto:[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] <mailto:[hidden email]> > http://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 |
«
Return to AIDA/Web
|
1 view|%1 views
| Free forum by Nabble | Edit this page |