[Zope-CMF] Re: Method Aliases

[Kapil Thangavelu]

On Wednesday, October 1, 2003, at 12:24  AM, Yuppie wrote:

> 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=pasade 
>> na &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.

i hated making that argument even as i wrote it, because as you  
correctly surmise it leads to stasis of the status quo in terms of  
urls. as for principals, i do agree with the principle that meaningful  
urls are 'nice', and i think its that most zope developers could concur  
with esp. as zope naturally lends itself to this which serves as a  
point of differentiation for zope.

yet i disagree with tres's comment

>>> Users *do* look at URLs, often before clicking through  to
>>> links, in order to get clues about what to expect on the other side.

as i find that the reality of 'natural' in the wild is such that i  
don't see how users can interpret application urls like those  above,  
yet those represent some very successful sites, ergo.. users rely on ui  
for navigation. this isn't a cause for not changing things but merely  
an attempt to accurately depict what i see as what users do rely on for  
context, namely navigation.

ignoring that for the moment and taking the benefit of meaningful urls  
as a clue to context,  what's the contextual difference between
content/ + (document_edit_form || document_edit_form.html  vs.  
edit.html || il18n edit url)

imo, minor.

regarding the i18n url, sure on a single language non english site it  
would be nice, but on a multilingual site, is this really a solution?..  
it doesn't look like it, again navigational context and translation is  
key.

nevertheless, i also agree with tres's statement that

>>> The current name-mangling is an undesirable artifact of using
>>> acquisition to find software;  aliases put back "natural" names for
>>> methods.

yet, i find the actuality of the contextual difference here with the  
examples given in the proposal to be negligible, though this is  
subjective. what i do take issue with here is the current  
implementation as i abhor the use of a traversal hook in the core  
machinery without significant gains to be had. is a subjective choice  
over the value of a meaningful url significant?

sigh.. i really don't want get into this discussion, i can live with  
method aliases and i want to fold my cards. no more antes ;-)

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

amen.

>
> 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.
>
sure but aliases don't magically fix that, both systems require fixing  
templates, scripts and editing actions to achieve definitive urls for  
content.


>> 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.
>

ok, first off i think my specific needs are adaptable to the new  
implementation. if you don't want to read through a description of them  
skip to the bottom -> # end


well wrt to my specific needs, i was thinking of two product sets.  
CMFDeployment needs to discover defined url end points for a content  
item when its rewriting rendered content so that it can map them onto  
new url endpoints taken into account possible host changes and  
extension additions done for static webservers to correctly serve up  
mimetypes to the browser. on this issue i think the issue is fairly  
easily solvable at the cost of increasing the size of the url db with  
the aliases.. not an issue i think.

the second product set are basically gateway products, they use  
pretraversal/traversal hooks to allow transparent access to objects  
residing on the filesystem or subversion as content. the interaction  
with the pretraversal hook in the current implementation of method  
aliases is not so good here, but its solvable i think by just  
incorporating the body of the dynamic type pretraversal hook impl with  
minor mods. as example of some of the traversal hooks i'm talking about  
take a look at

http://cvs.sourceforge.net/viewcvs.py/collective/CMFSubversionBrowser/ 
Traversal.py?rev=1.3&content-type=text/vnd.viewcvs-markup

it basically uses the pretraversal hook to associate a subpath with the  
gateway ala pscripts or zpt and uses that to introspect into a foriegn  
system to construct a chain of objects for return by the traverse hook  
on the gateway object. (the code for this is a little old but the same  
principle applies, the recent versions are in by odd chance a  
subversion repository ;-)

# end specific needs monologue

it would be cool if there were a wiki with future cmf  
proposals/enhancements instead of them getting lost in mailing list  
archives.

cheers,

-kapil