[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.
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.
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.
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.
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.
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.
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.
Thanks for your comments - I'm currently taking a look at 1.3 and
hopefully will have a better understanding soon.
-- Andreas
--
Andreas Hartmann, CTO
BeCompany GmbH
http://www.becompany.ch
Tel.: +41 (0) 43 818 57 01
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
