On Tue, 5 Mar 2002, Nicola Ken Barozzi wrote: > From: "Sylvain Wallez" <[EMAIL PROTECTED]>
<snipped/> > > In the interpreted sitemap engine, the <map:components> section is > > handled as regular component manager configuration (i.e. a .xconf file), > > so you can add any component you wish in it. > > > > The only piece that's missing is a classloader per subsitemap to load > > additionnal jars. But we should be careful with that since this places > > code in areas that are potentially visible from the client browser (the > > servlet engine hides the contents of WEB-INF). A solution could be for > > the sitemap engine (or Cocoon itself ?) to forbid access to all URIs > > containing 'WEB-INF/'. > > I'm definately +1 on having some kind of user.xconf. > I'd be +10 for a directory where you can plug in Cocoon blocks. Yes, block. user.xconf as well as user.roles must be organized so that every Cocoon Block has at least a set of it (we can discuss if it should be bound to a sitemap, and thus be hierarchically organized instead of flat, but ... FS?) > From a previous interesting discussion on the list, I understood that Cocoon > needs 3 levels of pluggability: components, blocks and apps. This is > probably reflected from the fact that it uses Avalon, and Phoenix is > organized this way. > > 1 Components > ------------------- > Components are all components under ./components. Some are of Cocoon proper, > some used only by blocks. > > 2 Blocks > ---------- > blocks are the Cocoon proper components (Generators, Transformers, etc). > They may need Components, and they must not need other blocks. They should > be IMHO easily deployable. As you mentioned Avalon Phoenix there Blocks CAN use other Blocks as a Block is defined as a Service. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
