On 3/19/08, Andreas Hartmann <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] schrieb: > > I prefer easily understood designs. That usually requires a flat > > hierarchy of classes rather than much indirection. > That depends on the modelling paradigms one is used to. I have experience with many paradigms. From LotusScript with a very shallow DOM (the only implied inheritance is faked) to Microsoft's .Net with more classes than one person could ever learn. Most deep hierarchies indicate design flaws, but exceptions always exist.
> > 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? > From my PoV, the reason to distinguish between AbstractPublication and > FilePublication would not only be simplifying code reuse, but also the > separation of aspects. AbstractPublication should be responsible for > providing a generic implementation of publication functionality, > delegating the persistence to a concrete subclass. FilePublication deals > with the persistence. This way, classes can be kept small and concerns > can be separated. An even better way might be to replace this > inheritance with delegation, e.g. by using an object-XML mapping > framework. But this again might make the code more complex, so a > compromise has to be found. Lenya-1.3 separates Content persistence from the Publication. A Publication contains a Content. If implemented in Lenya-1.2, Publication would delegate to a FileContent class. Lenya-1.3 handles two types of file content and so names classes HierarchicalContent and FlatContent. > > 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. > That sounds like the persistence delegation I mentioned above. In 1.4, > the repository layer (o.a.l.cms.repository) is responsible for this. > Some classes still use the old direct-to-XML-files approach (e.g. the > Publication), this is legacy from the time when the objects were > immutable and the data were treated as configuration. We speak the same language! So 1.4/2.0's repository is similar to 1.3's Content? > > 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. > I guess we all agree on this. In 2.0, the packages are usually > o.a.l.modules.foo for the API and o.a.l.modules.foo.impl for the > implementation. If we arrive at the point where the core is fully > modularized, we could get rid of the "modules" part. Lenya-2.0 modularizes with Java in the modules so this naming convention works. Lenya-1.3 does not allow Java in Modules so this is not an issue. > Does the module system of 1.3 support a kind of polymorphism? IMO this > is a major challenge, and I don't yet know how it could be implemented. > As a simple example, imagine the following publication hierarchy: > ParentPub > ChildPub (template = ParentPub) > ParentPub uses the xhtml module. ChildPub uses the following modules: > * xhtml > * homepage (inherits from xhtml) > * mySpecialXhtml (inherits from xhtml) > With the following two documents > /index (resourceType = homepage) > /tutorial (resourceType = xhtml) > it should be possible that /index uses the XSLT from the homepage module > and /tutorial uses the XSLT from the mySpecialXhtml module. With the > current module architecture in 2.0, I don't see a way to implement this > in a straightforward way. Yes! I will not need to explain Lenya-1.3's Module system to you. What you described is a very simple case. See 13ModuleXML.txt for configuration instructions. Lenya-1.3's Module Inheritance is completely polymorphic. Any Module can inherit from other local Modules, other Publication's Modules, and global Modules. After the Module-specific inheritance is checked, the Publication's inheritance is followed. The global Modules are the last resort. I have not tested these cases, but circular inheritance and global Modules inheriting from Publication Modules should work. The key to the implementation is the module: protocol, which takes fallback to new depths. See o.a.l.cms.modules.ModuleSourceFactory for the entry point. Using a cache was implemented with PublicationModules.getFile(). > > 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? > What do you mean with "ObjectModel"? The objectModel map passed to > Cocoon services? AFAIK it depends on the current request, doesn't it? > I see that you're using the ContextMap from o.a.log in the Exalibur > distribution. IMO it's not immediately transparent to use static methods > for thread-local information (I prefer parameters), but this might be a > matter of preference. Yes, that is the objectModel. CocoonServlet adds the objectModel to the ContextMap and associates the ContextMap with the Thread. All values in the objectModel are scoped to the Thread. As seen in the Globals class, retrieving those values does not require passing the objectModule as a parameter. Maybe the Globals class should be renamed to ThreadLocalValues, but Globals is easier to type and handles non-thread-local functions like createUUID(). Using static methods for the thread-local values may be a matter of preference, but the great reduction in code from this paradigm should improve performance. > Thanks for your comments - I'm currently taking a look at 1.3 and > hopefully will have a better understanding soon. > -- Andreas Somebody is looking at Lenya-1.3! Yeah! Check the ToDo list if anything does not seem to work correctly because an entry means work is still needed. Please ask about anything no matter how inconsequential it seems. My best programs develop when I am able to watch users to see when they frown. solprovider --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
