cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject Re: [cocoon 2] removing bottenecks
Date Wed, 24 May 2000 12:52:32 GMT

Jonathan Stimmel wrote:

> Let me give a specific example. arch/config/ contains:
> (an interface)
> (an abstract class)
> I honestly don't see the need for both an interface and an abstract
> base class; it only serves to increase the complexity and maintenance
> overhead. I mentioned this and another exampl in my comments on
> DirectoryGenerator (separate thread).

In defense of this structure, our company has adopted the
practice that every interface should have a base class to make
implementation easier.  We use interfaces to define components and
don't use them when we are dealing with simple objects.

Now our company also uses the practice that if you have a concrete
class that everything else will build upon, the abstract class isn't
necessary--but usually included anyway to avoid confusion and
questions of why something was done one time, but not another.

Configuration should be a component, but datums are not.

> In all fairness, I am fairly detail-oriented, and I am probably
> going over this with a more critical eye than is really necessary.
> I also feel that lack of documentation is a large part of the problem;
> if classes explained why they existed - even if only briefly - I
> wouldn't have to spend so much time "reinventing the thought process".
> Some of what I'm seeing is also not necessarily cocoon's fault (inherent
> in using SAX, for example).

I'm the same way, and I agree 225% with the documentation.  The
question comes then who has done the architectural design and
analysis, and is the UML/FooBar notation available?  If you know
of a good tool (open source or free preferrably) that will give me
a GUI for docbook style XML, I would be interrested in creating
the system specification and design docs.  I work in windows, but
use Linux at home--so if I could use a program that works in both
places, that would be better.

Why reinvent the wheel, when somebody has the grand design in
their brain?  Another doc that would be good is one that explains
what coding conventions beyond the Java coding standards (that
are very generic) the project uses--aka every interface should have
an abstract base class, place a comment after the close bracket
restating in plain english what it was enclosing (our own standard
that really helps when nesting blocks), etc.

> > if you want a good mini project, that might be a good place to start -
> > document the major interfaces and classes in the cocoon2 package.
> Not a bad idea (didn't someone already start working on this?),
> and I will try to do some work towards this end. Of course, I
> can't document something well unless I understand how (and why)
> it works the way it does.

Who did start on that?  If I wanted to contribute to that end, where
should I send my stuff?

View raw message