Andreas Hartmann wrote:
Jörn Nettingsmeier schrieb:
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.
<snip>
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 proxy transformation is configurable (absolute/relative URLs).
Can we assume that a global setting is sufficient, or do we need this
per publication?
if people need to configure that, we provide a configuration option
(maybe in publication.xml), which the global pipeline looks up. less
boilerplate code in pubs, better maintainability.
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").
Would the sole purpose of this pipeline be to deliver the content to
editor clients? If yes, maybe we should place it in the editors module?
no. whenever a document is needed, it should be done via that pipeline.
there is no win as long as fetching a document is as trivial as saying
<map:generate src="lenya-document:<uuid>/>, but users may want to be
able to apply quick-and-dirty hacks in some central place - imaging
company changes its name from foo to bar: one transformation hacked into
the repository pipeline will keep management off your back and give you
time to think of a proper solution.
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.
Would you mind elaborating a bit more on the delegation? As I understand
it, the rendering can't be delegated to the server. Even if it was
technologically possible, it wouldn't make sense from a performance
point of view.
sorry. with rendering, i don't mean the actual display - that happens in
the browser, with the help of either design mode or javascript magic.
i mean the aggregation and preparation of page content (see tinymce: no
custom code, the aggregation is done by mounting the publication sitemap).
IMO it will be very hard to find a common approach for editor-side
page rendering. An example for a simple approach:
When integrating Xopus, I once built an infrastructure to generate an
XSLT stylesheet on the fly which contained all navigation elements,
context-dependent widgets etc. and sent it to the editor to render the
page. The stylesheet could also be used to render the actual page, but
only if everything was cached.
i don't know xopus, but i think all editors could be rewritten not to
duplicate aggregations and transformations from the publication - by
delegating it. every editor is free to apply another post-processing
step and tweak the content as it wants (see tiny again: the rendered
page from the publication sitemap is augmented with the necessary
javascript snippets).
"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.
Yes, I guess there's no way to avoid that.
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.
Or we could provide a simple-to-use service which can be used by all
editors (delegation).
another possible solution. but why this extra indirection?
i'd prefer a generic usecase handler, because for example we still don't
have consistent locking behaviour across editors and have been fixing a
number of bugs for each editor independently.
it all could be done with a generic class. hard cases could be
subclasses imho. i know it's not en vogue, but i don't know why. if
there are disadvantages to subclassing in this context, please educate me.
--
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]
