[Zope-CMF] Re: CMF 1.5 beta coming -- last call before feature freeze!

[Gregoire Weber]

Hi Florent,

>>Good question!
>>I see four possibiliies
>>   1) return the object
>>      This results in http://example.com/permalink/1234 returning the
>>      object (good for search engines)
>
>Often you cannot publish an object in a context other than its original context. For instance the page could use relative URLs that would break (unavoidable in case of user-supplied HTML for instance), or create a breadcrumb from the URL (bad idea I know).
> 
>>   2) redirect to the object
>>      This results in http://example.com/original/location/of/item
>
>Ok for me.

Perhaps the result schould be http://example.com/original/location/of/item
if the HTTP_REFERER is another object than item and http://example.com/permalink/1234
else.

This way a user can follow the the permanent link at the bottomof the page 
and bookmark it. The next time he visits the link he gets redirected to the 
original location.

Ok?

>>     (is this good for search engines?)
>
>Don't know.

Does somebody know?


>>   3+4) return/redirect to the view method or to the bare object?
>>        Resulting in http://example.com/permalink/1234 or         
>>        http://example.com/permalink/1234/view or ...
>
>Should be the view method I guess, yes.

I personnally don't like the 'view' appendage but it is necessary for 
images and files at least.


>>And doing the permalink/1234 thing looks like it'll be necessary to make a
>>new content type (hmmm).
>
>Why ?

You're right. It's not necessary. I thought I would have to hook into 
traversal. REQUEST/URL0 snips away the uid but I get it by using
REQUEST/PATH_INFO. Hmmm, does this work in virtual hosting situations?

I'll try with a python script.

Gregoire