You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by so...@apache.org on 2006/08/21 05:36:23 UTC

Code Organization

This is not a suggestion for 1.4 or any other release currently being
developed.  I offer it for discussion for a future release, if we
decide to implement it, and even I have not decided if I like it.

In 1.2, the files were organized by type.  The XMAPs are in the
Publication root.  The configuration files were under one directory.
The XSLTs were in one directory.  The content was under two
directories: one for XML Documents and one for everything else.  There
are some exceptions, but most files followed the rules.  When I worked
on the Search function, the files were in 6 different directories.

With 1.3 and 1.4, we reorganized to follow function.  All the content
is moved to one datastore.  The program files are in Modules.  An
XMAP, an XSLT, and some XML configuration that work together are kept
in one directory.  Everything for Search is kept in one directory.

The Java code is still organized how it works.  The Generators are in
one directory.  The Transformers are in another.  The SourceFactories
have their own directory.  The InputModules have their own directory.
PageEnvelopeModule is not in the same directory as PageEnvelope.

I just added a subsystem with a SourceFactory, an InputModule, and a
Transformer.  Following the current rules, the files are in 3
different packages/directories.  All of the work in handled in the
SourceFactory.  The other files had to import the SourceFactory
because they are not in the same package.

Would it be good to reorganize so each package contains all Java files
related to the function?

solprovider

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org


Re: Code Organization

Posted by Andreas Hartmann <an...@apache.org>.
solprovider@apache.org wrote:
> This is not a suggestion for 1.4 or any other release currently being
> developed.  I offer it for discussion for a future release, if we
> decide to implement it, and even I have not decided if I like it.
> 
> In 1.2, the files were organized by type.  The XMAPs are in the
> Publication root.  The configuration files were under one directory.
> The XSLTs were in one directory.  The content was under two
> directories: one for XML Documents and one for everything else.  There
> are some exceptions, but most files followed the rules.  When I worked
> on the Search function, the files were in 6 different directories.
> 
> With 1.3 and 1.4, we reorganized to follow function.  All the content
> is moved to one datastore.  The program files are in Modules.  An
> XMAP, an XSLT, and some XML configuration that work together are kept
> in one directory.  Everything for Search is kept in one directory.
> 
> The Java code is still organized how it works.  The Generators are in
> one directory.  The Transformers are in another.  The SourceFactories
> have their own directory.  The InputModules have their own directory.
> PageEnvelopeModule is not in the same directory as PageEnvelope.
> 
> I just added a subsystem with a SourceFactory, an InputModule, and a
> Transformer.  Following the current rules, the files are in 3
> different packages/directories.  All of the work in handled in the
> SourceFactory.  The other files had to import the SourceFactory
> because they are not in the same package.

I totally agree, this has always struck me as odd.

> Would it be good to reorganize so each package contains all Java files
> related to the function?

Big +1
This could even improve SoC since it enforces designing a component
for one specific purpose.

-- Andreas

-- 
Andreas Hartmann
Wyona Inc.  -   Open Source Content Management   -   Apache Lenya
http://www.wyona.com                      http://lenya.apache.org
andreas.hartmann@wyona.com                     andreas@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org