Laurence Rowe wrote:
Martin Aspeli wrote:
Geir Bækholt · Plone Solutions wrote:
On 9. mar. 2007, at 17.22, Laurence Rowe wrote:
I would vote for keeping the base tag anyway, as it would make the
site not break if someone makes a wrong link somewhere.
Another possibility to help this would be to make all folderish
content redirect to get the trailing slash, like Apache does.
+1 on redirecting
Historically the Zope mantra has been to return data rather than
redirect to save the overhead of processing an extra request. Plone
is a complex application and I suspect this overhead is negligible
compared to rendering a page. Matching Apache's behaviour would make
things conceptually simpler.
INonStructuralFolders should probably not have a trailing slash
appended.
If INonStructuralFolders don't redirect and don't have base tags,
relative links to the objects contained in them may easily break.
They exhibit the exact same behavior as normal folders…
Yes. An INonStructuralFolder should be treated exactly the same as a
real folder; the interface pertains to the Plone UI only.
isPrincipiaFolderish should be the only thing we check.
Martin
Hmm, I'm not convinced by this. Take a RichDocument for instance. The
rich text field is on the RichDocument object itself. So we're either
going to end up with:
a) treating it like a document:
Relative links in the rich text field to external/sibling images
work like other documents.
Relative links to contained images don't work
b) treating it like a folder:
Relative links in the rich text field end up with an acquired
image (multiple copies get cached) or lead to a page outside the normal
containment hierarchy.
Relative links to contained images and files work fine.
So either way some things don't work as expected. I think this is a UI
question, should URLs to RichDocuments end with a trailing slash? In my
view no as for a RichDocument "It has every method and attribute of the
standard Page/Document type. That is, it can be used as a drop-in
replacement wherever a Page is expected."
My point is just that (a) it needs to work with Kupu selecting images
and (b) the INonStructuralFolder interface is a Plone-specific thing
that has to do with how things like the "add item" menu behaves in Plone.
Therefore, it makes sense to me to base this on the lowest common
denominator, i.e. isPrincipiaFolderish, and keep it as simple as
possible. I personally couldn't care less if I got an extra / at the end
of a RichDocument's URL. :)
Martin
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
