Andreas Hartmann schrieb:
[...]
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.
Another option would be to move the core module APIs - i.e. the
functionality which shall be available across the whole application -
back to the core. The corresponding modules would export only additional
components and utilities (e.g., Cocoon components), which could be used
by higher-level modules.
OTOH, we have to be very careful to put all non-API code in the private
packages of the modules. Otherwise we'd risk the danger that the core
grows very large again. I'd rather live with some code duplication in
custom modules than with exposing too many implemenation classes.
This approach has already been taken for access control, observation,
templating, and workflow. IMO it works very well. Other candidates are
search and linking.
For search, we could introduce the package
org.apache.lenya.cms.search
containing the interface
DocumentSearcher {
Document[] find(Area area, Query query);
}
and maybe some helper classes to build queries.
For linking, the API could contain the interfaces and classes
Link
LinkConverter
LinkRewriter
IncomingLinkRewriter
OutgoingLinkRewriter
ServletLinkRewriter
UrlToUuidRewriter
UuidToUrlRewriter
LinkResolver
LinkTarget
LinkException
The other classes should IMO not be part of the core API.
-- 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]
