About Lenya 1.3 Lenya 1.3.0-dev is developed for Java 1.4 and Cocoon 2.1.11. === History February 2006: Started a private fork of Lenya 1.2.2. June 2006: The other Committers expressed interest in (or demanded) the code. I stopped new development and integrated my code with Lenya 1.2.x (between the 1.2.4 and 1.2.5 releases.) September 2006 - August 2007: I had no time for this project. September 2007: Returned to project. Created as Eclipse 3.2 project. Added latest version of missing libraries and updated code. Completed edit functionality. The security system is next. See the 13TODO.txt for everything still under development. Enjoy, Paul Ercolino (solprovider) === Versions 1.3.0.x Fully compatible with Lenya 1.2.2, 1.2.3, and 1.2.4 Publications. Uses Java 1.4. Upgrade should only require changing Lenya and Cocoon. Cocoon should be upgraded to Cocoon-2.1.11 to include bug fix for http status codes. Includes "flat" module to upgrade 1.2 Publications to 1.3's flat storage. 1.3.1+ (Exact features to be determined before release.) Removal of backwards compatibility with Lenya 1.2. Upgrade to Java 1.5 (to use Generics). Add JCR support. Module to migrate from Flat to JCR storage. Module to migrate from JCR to Flat storage. Module to migrate Lenya1.4/2.0 Publication data. (All functionality cannot be migrated as Lenya 1.4/2.0's modules may contain compiled Java.) === Features The three major design goals for Lenya 1.3 were: 1. Improved plugins with better URLs (Modules). 2. Flat datastore for content. 3. Sensible working security. The new Module system was completed in early 2006 as an add-on for Lenya 1.2. The Flat architecture was easy once Kupu was rejected as the editor. The new security system is designed and being developed. == Modules Lenya1.3 Modules are an evolution of Lenya1.2's Usecases. Eventually, all XMAP code (below global-sitemap.xmap) will be moved to Modules. The advantages are: 1. Standard directory naming. All Modules are in either {pub}/modules or webapp/lenya/modules. A Module is referenced by the directory name. 2. All files for a function in one location. All Flow (JavaScript) code for a function can be in a file named "code.js", and every Module can have one. The homepage XSL is in a file "page2xhtml.xsl" in the "homepage" Module, rather than "page2xhtml-homepage.xsl" mixed with other XSLT files in one directory. The code for caching Resources is in the "cache" module, and is used only if the "cache" Module is included in the Publication. Other Modules use its API when they desire caching. 3. File Inheritance. Any files not in a Module are inherited from the parent Module, which inherits from its parent Module, ad infinitum. If the file is not found in a Publication Module, Lenya checks a global Module. That means a Publication can have a local "homepage" Module that only contains "page2xhtml.xsl". The rest of the functionality is retrieved from the global Module. 4. Integrated into URL. Lenya1.2's "Area" portion of the URL defines functionality rather than revision. Lenya1.2's Usecases are dynamically converted to this format. My belief is all Lenya configuration should be dynamically configurable while Lenya is running. (Do not look at Module Inheritance or Indexing yet. I said Lenya1.3 was not finished.) Note that Lenya1.3 Modules cannot contain Java classes. Programming that requires compilation is the domain of Java programmers who should be capable of integrating their code. I have yet to find a function that cannot be implemented with XMAPs, XSLTs, JS (Flow), and XSP (ServerPages) that does not belong in Lenya's core. Of course, other developers have different opinions. == Flat Content Resources may be type "xml" (Documents), "file" (Assets), or "link". "xml" Resources have a doctype. "file" Resources have an extension associated with each Revision. Architectural files, such as Structures and CSS, will be moved into the datastore after the security system is implemented. The "flat" Module migrates Lenya1.2's Documents and Assets to the new format. See 13UPGRADE.txt. All Resources are siblings. This allows flat views such as all Resources, all Files, all PDFs, etc.. It also allows any Resource to be easily used by another, avoiding Lenya1.2's "An Asset belongs to a Document." Hierarchical Structures maintain tree relationships. This allows multiple trees. Multiple document XML is created by defining Indexes. Indexes can filter either all Resources, or just Resources in a Structure. Most of the benefits will not be evident until Lenya1.3 is finished.