On 3/18/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > Jörn Nettingsmeier schrieb: > > Thorsten Scherler wrote: > >> like sounded in the thread around Cocoon 2.2 FOP NG update we need to > >> look into updating to cocoon 2.2. Further our famous 1.3 branch that > >> brings some nice ideas should merge with the 2.0.x branch. > >> > >> Maybe we can take the chance to merge both branch in an upcoming 3.0. > >> Would it make sense to have a clean cut? > >> > >> I meaning starting first with a requirements/architecture document and > >> ten develop the code around it (using as much good as we have right > >> now). Do you think it would be possible?
Everybody seems to agree that starting with a specification is good. Please tell me about any desired functions that are not in Lenya-1.3 or on its ToDo list. > Yes, the closer we stay to Cocoon, the better. > IMO we don't emphasize the connection to Cocoon enough: > - "Based on Cocoon" is very good marketing. > - Cocoon users are potential Lenya users. > - If your customer uses Lenya, you can sell Cocoon-based add-ons. > - Staying up-to-date with Cocoon allows to use their latest goodies. I agree that capturing the Cocoon market would be good. I am not certain about moving to Cocoon-2.2 or later. Cocoon-2.2 expects Maven. This is good for developing with ever-changing dependencies. This is not good when trying to maintain stable business applications. The Cocoon devs seem excited about losing functionality. One faction wants to migrate to Spring, which cannot handle much of the dynamic decisions Lenya uses everywhere. Another faction is creating a mini-Cocoon that removes most of the good functions Lenya uses. A near-future release of Cocoon may require a completely rewritten and more complex Lenya because backwards-compatibility does not seem to be a priority. More important, the Cocoon market will likely shrink when current users realize their current applications will not work on the future releases. After Lenya-1.3, I might work on Cocoon-2.1. My top three improvements are: - Aggregators using Generators so <map:part type="x"> would work without creating extra pipelines. (This one is so obvious that I cannot believe the first Aggregator was not implemented this way.) - Selectors work inside Generators, Transformers, and Seriaizers to reduce code duplication. (This may have been lost when the two-phase processing was implemented.) - MatchSelector and RegexpSelector could replace most current Matchers and Selectors, increasing functionality while decreasing learning time. (General functions are always better than specific functions. Cocoon-2.1.11 includes a specialized RegexpSelectors for request parameters and headers without including the easier general case.) These three patches could eliminate half the code developed for Cocoon. . A Lenya based on a easier-to-learn-and-use and easy-for-upgrades Cocoon-2.1 might capture the audience of people frustrated by the Cocoon project's current direction. > > but there are also a number of other things on the agenda: > > * get rid of areas > That would be nice, especially since it could simplify the codebase, but > from my POV the other issues have a higher priority. Areas were removed from Lenya-1.3. The first code written was a simple patch to 1.2 to use the Area portion of the URL for Modules as standardized Usecases without the querystring syntax. When Lenya-1.3 became a real goal, I discovered this Module system removed the need for XMAPs in the publication directory. Adding file-based inheritance made most Modules extremely simple since the Resource root types (xml, file, link, text) contain most of the code needed by most Modules. This also allows function-based (rather than file-type) file organization (e.g. homepage/page2xhtml.xsl rather than xslt/page2xhtml-homepage.xsl, and no file if inheriting from a parent Module rather than a file containing only an import statement.) > > * revisit content repository > Very important point. People keep asking why we don't support JCR. > Jackrabbit has arrived at release 1.4, I have the feeling that the > integration would now be much more painless than two years ago. Of > course we should also consider other options, but I have the feeling > that JCR support would give us a big marketing advantage. Lenya-1.3 prefers a flat datastore. Lenya-1.2's hierarchical datastore still works in Lenya1.3, but mostly uses code from Lenya-1.2. The Content interface is used by both datastores. A JCR implementation should be easy, but is very low on my priority list; maybe next year's SOC project? > > * generic editor handlers > Unfortunately it looks like the future of this issue is not too bright. > Unless we get Christian Stocker (BXE), Thomas Comiotto, and maybe the > HTML editor folks (TinyMCE, FCKEditor etc.) to talk to each other, I'm > afraid the situation won't change much. Neutron is certainly a nice > idea, but it won't succeed if other editor vendors don't participate in > the specification process. Lenya-1.3 does not use the FCKEditor (which I used for a project last year) because FCKEditor wants to send the entire XHTML page. My specification for Lenya-1.3's editor was it had to play nice with other fields and be able to run multiple instances on one page. FCKEditor does not meet those specifications. (I thought we had licensing issues with FCKEditor. I lost a day trying to compile Cocoon because jcr-1.0.jar and many other libraries are missing. If some code does not fit the Apache license, do not use it. Everything should work out-of-the-box, including the source version.) I was amazed at the amount of code needed to integrate Kupu into Lenya-1.2. Kupu requires storing part of a document being edited on the server. I tried using Kupu with Lenya-1.3 by creating Virtual resources (the Virtual classes are still in svn), but really disliked the algorithm. (When should the server discard abandoned continuations? after one hour? tomorrow? next week?) Lenya-1.3 is currenly using Xinha (derived from HTMLArea that I used many years ago) because multiple rich-text areas could be edited on one page with no temporary data on the server, and because the code and configuration looked easy to understand. I already fixed some bugs and integrated for basic XHTML editing. Full integration with choosing links, images, and other Resources is my third priority (after the Relations Structure Editor and security). TinyMCE looks similar to Xinha. We can create a Lenya-1.3 Module for it. Only 6 lines of code in the "xml" Module enable Xinha so changing the editor to something similar should be easy. Should the editor be configurable in the publication? Probably start with a querystring parameter to keep it simple. Any editor for Lenya should allow multiple rich-text fields to coexist with other fields. That allows Lenya to be used for most business applications. Without that specification, Lenya is just a complicated datastore with some security. solprovider
