#30 — Embed version info in URL

by Frank Bennett — last modified Feb 21, 2009 08:53 PM

State	Confirmed
Version:	1.0rc1
Area	Functionality
Issue type	Patch
Severity	Medium
Submitted by	Frank Bennett
Submitted on	Aug 07, 2006
Responsible	—
Target release:	1.1

Return to tracker

There are a couple of reasons why it would make sense to use a fixed URL for repository content, with not query string:

- Because repository content is by definition static, it makes sense to cache it when using Squid or Apache as a caching proxy. A query string makes it difficult to do this.

- Repository content is a natural target for RDF utilities such as Annozilla. In the case of Annozilla, the current version ignores query strings, which means that if they are used to distinguish between versions, a commented view of any version of a page will get _all_ of the comments for that page -- and mostly in the wrong locations.

The attached patch against 1.0rc1 enables a fixed URL scheme for versioned content. The syntax is explained in the patched CHANGES.txt file. URL elements are mapped into REQUEST values; no changes are made to internal code, and the old addressing scheme will still work.

I would like to propose this for incorporation into CMFEditions trunk. I have placed a patched version of the trunk in SVN at branches/bierce-version_embedded_urls.

Many thanks!
Frank Bennett

Steps to reproduce:: Not applicable.

Attached:

cmfeditions_url.patch — differences between files, 11 kB (11434 bytes)

Added by Gregoire Weber on Oct 13, 2006 03:46 PM

Target release: 1.1 → None

Looks quite nice! This was planed (in my mind) for a future release! Much Thanks!

May you give us a compatibility list with supported Zope and Plone versions?
Is there a Five feature used that prevents CMFEditions running with Plone 2.1 and Zope 2.7.7 or 2.8.1?

We like to go with the lowest Zope versions required for the current Plone 2.1.x and Plone 2.5.x releases.

Added by Alec Mitchell on Oct 13, 2006 08:04 PM

I would say that turning every object into a Local Site, is a very bad idea. We need some more appropriate way to do this. PublishTraverse adapters are probably the way to go, but they are not available to us until Zope 2.9+ (maybe even not until 2.10). Though the feature is great and useful, the implementation is unfortunately far from ideal.

Added by Frank Bennett on Oct 15, 2006 01:11 AM

Alec's point is very happily taken. My knowledge is limited, narrow, and partial, and I am always fearful of throwing a spanner into the works. I will study PublishTraverse adapters when I have time, and try to come up with something more sensible. (I have a full time job that does not include programming, so measure this in months, not days).

Meanwhile, I don't have any special claim to this, and would be delighted if someone who knows better what they are doing were to take it on. :)

Added by Gregoire Weber on Oct 21, 2006 01:41 PM

Target release: None → 1.1

The "right" technical solution has to be fleshed out first.

Added by Gregoire Weber on Oct 21, 2006 01:46 PM

Issue state: unconfirmed → open

Added by Frank Bennett on Oct 25, 2006 07:21 AM

Breaking my undertaking to put this off for awhile, I sat down over traversal adapters today. Unfortunately, I've come up empty-handed. I have done my best to deduce the correct way of setting one up from Z3 Book, the source code under zope.app, and various comments made on the Net. After a couple of hours of small tweaks and restarts, I have concluded that (a) I am able to crash Five by putting in bad code, and (b) when my code loads safely, it never runs. It won't do any good for me to spend more time "working" on this, since I'm obviously missing one or more of the necessary elements.

If anyone can point me at a worked example of a traversal adapter running on Five, please reply. Otherwise, I'm afraid I'm stumped.

No responses can be added.