Jörn Nettingsmeier schrieb: > 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.
OK, that sounds reasonable. >>> 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. Hmm, do you think this is worth the overhead generated by the pipeline, especially the performance overhead? Apart from that, you'd always have to use the cocoon:// protocol to request a document, and would lose the nice unambiguous lenya-document: syntax contract. IMO the post-processing hacks you mentioned should happen in the repository, not the Cocoon application (which we even considered to get rid of as far as the repository layer is concerned). >>> 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). OK, I see. But doesn't this require a special editor architecture (embedded in the page as a JavaScript widget)? Would it work with BXE too? >> 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). OK, I hope you're right :) I'm not quite sure yet what this would look like, but I guess I'll see as soon as there is some example code. [...] >>> 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? A separate service has many advantages: * single-purpose interface * easier to understand * smaller classes * better reusability (complementary functionalities) A very nice example how not to do it is the LuceneIndexTransformer. Service functionality (indexing) mixed with XML processing functionality. This class is a PITA - sorry, Thorsten :) - to read. > i'd prefer a generic usecase handler, Sure, that would be good, but it doesn't contradict delegating some functionality to a distinct service. > 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. If you search the web for "composition vs. inheritance" you'll find some articles, e.g. http://www.artima.com/designtechniques/compoinh4.html Here's a section from an interview with Erich Gamma: http://www.artima.com/lejava/articles/designprinciplesP.html (scroll down to "Composition versus inheritance") -- Andreas -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
