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. 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 proxy transformation is configurable (absolute/relative URLs). Can we assume that a global setting is sufficient, or do we need this per publication? > 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? > 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. 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. 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. > "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). > but all of this should happen after 2.0. or do you consider the issue > with changing sitetrees critical? I can't speak for Richard, but IMO this doesn't need to be addressed before the release (a comment in the release notes would be nice, though). We should tackle it asap after the release. -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
