On 3/18/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > BTW, checkPreconditions() is final to enforce the template method > pattern (http://en.wikipedia.org/wiki/Template_method_pattern). > -- Andreas
Hi Andreas and All, Since I am hoping Lenya devs will look at Lenya-1.3, I should explain some of my design decisions. Design Patterns are great for discussing designs. Implementation still requires a good designer. I worked with a programmer who chose a Design Pattern for everything. The problem was he usually chose the wrong pattern, often not even a pattern from the same category suggested by the problem. Most patterns in a category produce similar solutions, but choosing the wrong category makes a mess. I prefer easily understood designs. That usually requires a flat hierarchy of classes rather than much indirection. In Lenya-1.2, Publication is an interface, FilePublication is almost empty, and AbstractPublication contains most of the code. Has anybody ever implemented another type of Publication? The JCRPublication might. Lenya-1.3 uses a Content package of interfaces. The Publication contains a Content -- the type of datastore does not affect the Publication, only content retrieval. A Content.JCR package would contain all the datastore-specific code. The same could be done with Content.Domino, Content.SQL, and Content.Subversion packages. I prefer function-based organization. This is obvious in Lenya-1.3. Lenya-1.2 kept all InputModules in one directory and all SourceFactories in another directory. The Content package containing an InputModule, a SourceFactory, and a Transformer (and two more Transformers will be moved there from the Content.Flat package.) The Modules package contains two Generators, an InputModule, and a SourceFactory. BTW, the two SourceFactories mentioned replace almost all protocols used in Lenya-1.2 (e.g. file and fallback.) The new Module system could be attributed to many patterns. The XML Module contains code to display any XML document (although it currently assumes that any fields below the first level of children are part of a rich-text field.) Most document types can be implemented with just a resource definition. Display can be controlled by overriding page2xhtml.xsl. This is not really the template pattern because control is passed to the Type Module which is not required to inherit from a Root Type Module. In practice, I expect most developers will inherit as much as possible. A big change in Lenya-1.3 is to use a Globals static class for everything depending on the ObjectModel. Why have a globally accessible ObjectModel and then pass it from class to class? - Deprecated the PageEnvelopeFactory -- its sole function is replaced by the static PageEnvelope.getCurrent(). Why have a Factory class that has only one function, and that one function requires a global variable to enter as a parameter? - The PublicationFactory is similar. The Global class is using it because I was lazy. The Global class supplies the ObjectModel to simplify calls from other classes without needing access to the ObjectModel.Globals.getPublication() returns the current Publication and Globals.getPublication(id) can return any Publication. I could have deprecated the PublicationFactory in the time I spent writing this. No Lenya-1.2 classes have been deleted. One specification for the first release of Lenya-1.3 is complete backwards-compatibility with Lenya-1.2. That requires keeping cruft. Once this version is stable, the next version can start by deleting the cruft (or better, copying files to a new project until everything works.) Just a quick peek into my brain -- I should have cleaned first, but my maid retired. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
