Andreas Hartmann wrote: > Hi Lenya devs, > > first I have to say that Lenya 2.0 is starting to be real fun to work > with.
YEAH! > As more standard capabilities have been added, it becomes much easier > to add cool functionality: :-D i like cool functionality. hell, i get itchy to start hacking lenya again. soon as i've (hopefully) passed my master's exam (crafts, not academic :-D) in may, i'll be back on track :) > * 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. sweet! > 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. i think it's ok to compile core modules together. this should be marked in the module.xml file somehow (like <depends class="messy"/> :-D). i agree that some discipline is needed not to jeopardise the hard-won structure we have now... my first reaction was: it's ok for core modules to have (possibly circular) interdependencies, but not for others. but what if users want to introduce their own complex APIs that could introduce messy dependencies? maybe they should also be able to define "groups" of interdependent modules? in short, if we introduce a mechanism to compile a group of module APIs together, it should be generic and accessible to custom deployments as well (even though we should make it very clear in the docs that people should think twice before using this feature for their custom code). > > 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 i wonder: would it help users to introduce a more finely-grained module structure? i don't mean new complicated semantics, just a directory-like structure that helps people figure out what a module does and helps implementers to focus on one particular thing and factor out stuff if necessary. for example: core-api (your list) core-features acusecases administration development export inbox lenyadox linkcheck menubar migration sitemanagement sitetree sourcerepository svg usecase webdav resource-types cforms collection contactform links news opendocument resource usecasedocument xhtml editors common oneform forms bxe cforms fckeditor kupu neutron tinymce xopus optional blog languageselector prettyprinting profiling basically, this would be a voluntary thing, i.e. it makes no real difference where you put a module, it's just to make it easier for humans, and to gently push developers towards good modularisation. we could put a readme into each "subtree" that explains what the modules in there are about and how they talk to the outside world. since there are no compile or runtime semantics involved, users would still be free to combine an editor implementation with a resource type in one module if they want. -- jörn nettingsmeier home://germany/45128 essen/lortzingstr. 11/ http://spunk.dnsalias.org phone://+49/201/491621 Kurt is up in Heaven now. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
