Usecase framework question

Does it make sense to provide a usecase with the opportunity
to do a 
test before the generic tests are ran? Something like Cut
doesn't need 
to call getNodesToLock and go through that mess if a live
version 
exists. If we assume that the site will mostly be live, this
will make 
the site tab much quicker. However, it would appear that the
first call 
is to checkPreconditions, which is final for some reason and
doesn't 
call a method that can be overridden until after
getNodesToLock.

Does any of this make sense?

Richard

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

On 3/18/08, Andreas Hartmann <andreasapache.org> 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: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org

On 3/19/08, Andreas Hartmann <andreasapache.org> wrote:
> solproviderapache.org 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: dev-unsubscribelenya.apache.org
For additional commands, e-mail: dev-helplenya.apache.org