[Zope-CMF] Re: Method Aliases

Yuppie schubbe at web.de
Wed Oct 1 03:24:58 EDT 2003


Hi!


Kapil Thangavelu wrote:
> 
> On Tuesday, September 30, 2003, at 11:58  AM, Tres Seaver wrote:
> 
>> On Tue, 2003-09-30 at 14:46, Kapil Thangavelu wrote:

>>> the only justification i'm seeing for this feature is that pretty urls
>>> are good for being pretty, or features for features sake. if i'm
>>> missing something please enlighten me.
>>
>>
>> "Pretty" isn't the issue;  "meaningful" is.  Many clients, for  instance,
>> expect filename extensions, but Python methods can't have them.
>> Likewise, aliases allow localization of the otherwised Anglo-centric
>> method names.  Users *do* look at URLs, often before clicking through  to
>> links, in order to get clues about what to expect on the other side.
>> The current name-mangling is an undesirable artifact of using
>> acquisition to find software;  aliases put back "natural" names for
>> methods.
>>
> 
> thanks for the reply, tres
> 
> while i agree with those principals, i find looking at the current  
> state/reality of the web to be a far cry from it. here are some example  
> urls from sites i went today. i think the reality here is that  
> *developers* look at urls, users have become so inured of the current  
> state of application servers that urls like those below are taken for  
> granted, to the extent that i would posit, users rely on navigation  
> systems for semantic context almost soley.
> 
> http://www.amazon.com/exec/obidos/subst/home/home.html/102-3479385- 4471337
> http://story.news.yahoo.com/news?tmpl=story&cid=578&e=2&u=/nm/20030930/ 
> ts_nm/bush_leak_dc
> http://store.apple.com/1-800-MY-APPLE/WebObjects/AppleStore.woa/72601/ 
> wo/SUwYS87rbaxu2T37RuL1vqDg2ac/0.0.7.1.0.5.21.1.1.1.1.0.0.1.0
> http://slashdot.org/articles/03/09/30/ 
> 170259.shtml?tid=103&tid=117&tid=185&tid=99
> http://www.computerweekly.com/articles/ 
> article.asp?liArticleID=125053&liFlavourID=1&sp=1
> http://go.vicinity.com/mbe/ 
> GeoFind.d?E=sPaM9SYDqSw6R6pi&AD4=USA&AD2=1001+E.+Mentor+St&CITY=pasadena 
> &STATE=ca&ZIP=91106
> 
> i realize the alias mechanism solves a more generic case of the  
> extension issue in that it will work for object methods, but afaics  
> nothing prevents using directory view types with extensions.. ala  
> document_view.html.pt which can be directly referenced in the action.
> 
> since imo, users are using navigation mechanisms, i18n of urls seems to  
> be of questionable value.. compared to i18n of action  
> names/descriptions in the ui, though i confess i remain ignorant of  
> i18n issues in general.

Is this summary correct?
- you agree with the principals of meaningful URLs
- the current state of application servers leads to monster URLs
- monster URLs lead to ignorance regarding all URLs
-> changing the current state of application servers is useless

This is a very pessimistic view of things. I think application servers 
should give developers a chance to use meaningful URLs.


A related issue is the quantity of URLs. Navigation should link to one 
page with one unique URL.

Look at search results, breadcrumbs and actions in Plone or CMFDefault.
You'll find myDoc.html, myDoc.html/, myDoc.html/view and 
myDoc.html/document_view - sometimes more than one version in one page.

This is a Bad Thing because it confuses users (did I see that page 
already?), pollutes search machines and doubles traffic (your software 
will not know the page is already in the cache).

I know there are other ways to resolve this. But Method Aliases make it 
pretty easy.

> anyways, i think the writing is on the wall here, the code's in cvs,  
> and i'm late to the party.  so i fold my cards. it looks as though i  
> can work around these 'features' since alias names can be discovered  
> given an object, although working around the pretraversal hook will  
> require some detective work...

I don't know what your special needs are. But if there's a way to make 
your live easier by improving interface or implementation we should 
discuss changes.


Cheers,
Yuppie





More information about the Zope-CMF mailing list