Richard Frovarp wrote:
The question was brought up during the hackathon as to what to do about
the possibility of changing nodes while a document referring to them was
being edited. Didn't we decide that we could just leave links in their
lenya-document form when loading a document to be edited? We can't do
that for images, as the editors need to be able to display those.
However, the chances of a document changing URL is probably greater than
an image changing URL. The form editors are the only editors at the
moment to not translate to a URL upon edit. The link insert that Jörn
came up with does insert lenya-document links, so that part is already
taken care of.
in the grand scheme of things, the problem could be solved as follows:
1. there is a *single* global pipeline in the core that gets to handle
all outgoing content. this pipeline applies the i18n, uuid2uri and proxy
transformations as well as any necessary namespace node cleanups
(probably even prettyprinting, if desired).
the publication is not concerned with that.
moreover, there is a *single* global pipeline that fetches documents
from the repository (sort of the cocoon repository "api").
2. all publications have a single pipeline that does the part of the
renderning the publication is concerned with (which excludes uuid2uri
transformation).
3. all editors delegate the rendering of a page to the publication
pipeline (unless they operate more effectively on the raw document as it
comes from the repository, oneform being an example), and apply
necessary tweaks afterwards. "necessary tweaks" would include resolving
lenya-document:// links to images and possibly storing the orginal uuid
somewhere in the usecase proxy for later restoration.
that way, publications themselves would be totally agnostic to the fact
that out there, lenya-document:// does not exist. which solves the problem.
if the editor usecase stores a mapping of uuid -> uri as it was when the
page was invoked, the correct uuid can be restored regardless of
concurrent sitetree rearrangements by other users.
this is quite a job for the usecase handler, and it would make sense
imho to only attempt that after all editors have been migrated to a
generic usecase handler.
but all of this should happen after 2.0. or do you consider the issue
with changing sitetrees critical?
regards,
jörn
--
Jörn Nettingsmeier
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
