Hi Lenya devs,
first I have to say that Lenya 2.0 is starting to be real fun to work
with. As more standard capabilities have been added, it becomes much
easier to add cool functionality:
* The meta data indexing made it possible to implement an image search
in one or two hours - not by filtering, but by using a query which looks
only for images. This could also be very valuable for asset management
functionality (i.e., the "Insert Image" usecase).
* The "Persistable" interface together with the meta data indexing
allows us to store outgoing links in the meta data when a document is
saved. This makes it possible to use Lucene to find potential broken
links before deactivating a document. This will make the "Deactivate"
GUI much faster. I'm currently working on this.
During this implementation I noticed a major drawback of our current
modularization approach. Since circular dependencies are prohibited,
it's virtually impossible to use other core modules to implement a
certain core functionality. A typical example is the usecase module. It
depends on some other modules, for instance the ac (access control)
module. Since there are also access control related usecases (login,
logout), they had to be put in a separate acusecases module to avoid a
circular dependency.
I already thought a lot about this issue, but I always arrive at one
solution: We'd have to abandon the module dependencies, at least for the
core modules. If each core module can access the APIs of all other core
modules, it will become possible to leverage their functionality. OTOH,
this would increase the danger of violating the separation of concerns,
and therefore requiring a lot of discipline - we have to think twice
before adding a certain functionality to a core module.
IMO the current partitioning in core and "other" modules is not very
appropriate. A major question is: Does the usecase framework belong in
the core? If we intended a strictly layered architecture, the GUI
classes shouldn't be part of the core. In this case, the partitioning
might look like this:
Core Modules (without usecases and other GUI classes)
------------
ac, cache, i18n, janitor, ldap, linking, lucene (or search?), metadata,
monitoring, notification, observation, properties, templating, workflow
Other Modules
-------------
acusecases, administration, blog, bxe, cforms, collection, contactform,
development, editors, export, fckeditor, inbox, kupu, languageselector,
lenyadoc, linkcheck, links, menubar, migration, neutron, news,
opendocument, prettyprinting, profiling, resource, simplesite,
sitemanagement, sitetree, sourcerepository, svg, tinymce, usecase,
usecasedocument, webdav, xhtml, xopus
The usecases from the core modules could either be moved to the
administration or sitemanagement modules or to their own modules (e.g.,
since the notification usecases are related to the inbox functionality,
I'd suggest to extract them into a separate inbox module).
What are your opinions about this issue? TIA!
-- 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]
