On Sun, 15 Dec 2002, Sylvain Wallez wrote: > Giacomo Pati wrote: > > >On Sat, 14 Dec 2002, Sylvain Wallez wrote: > > > >>Giacomo Pati wrote: > >> > >>>On Sat, 14 Dec 2002, Sylvain Wallez wrote: > >>> > >><snip/> > >> > >>>>How will blocks will give a solution ? Is it because a block contains a > >>>>xconf along with an xmap ? Will block sitemap still contain a > >>>><map:components> ? > >>>> > >>>Yes. But the problem is IIRC only with the root sitemap, right? > >>> > >>This is currently a problem with the root sitemap, but actually this is > >>with sitemaps that don't have a parent. Blocks sitemap will fall in this > >>category, otherwise the vision of reusable blocks that can be downloaded > >>from a central repository would not be implementable. > >> > >>So this problem is going to be even more present with blocks. > >> > >> > > > >I don't get this. > > > > > > Let's try it another way : a block has to be as independent as possible.
Indipendant from what? > It can have dependencies on other blocks, but the block's sitemap cannot > IMO rely on a particular set of sitemap components to be declared in the > root sitemap, and must therefore declare _all_ sitemap components that > are used by the block. If you write a block implementation that use all possible kids of components, than yes. But blocks are intended to do spezialized little things and thus don't need that much components as we have today with the root sitemap that, for convenience, defines all the components that our sub sitemaps are supposed to use. We just do that for our samples which is not a production like use case (at least not the way we use it today in our systems). Blocks *will* reduces the size of the root sitemaps <map:component> section and will distribute component definition into the blocks set of sitemap/config files. > This means that a block's sitemap will also contain a large > <map:components> section, just like root sitemaps. I disagree. The block only contains the components that the block needs. If it needs other blocks its their responsability to define all the component that block needs. With the block:// protocol they can expose URIs of which the actor using that block don't have to know which components that URI is using internally. Look, suppose you have a PDFizing block. Does your sitemap needs to define the FOP or IFOR components and the XSLT component to transform into FO/IFOR schema? No, just a reference to the block:URI supposed to deliver the transformation/serialisation is needed. > Therefore, with blocks, we will not only have large <map:components> in > the root sitemap, but also in every block's sitemap. Still I don't see why the roots _and_ the blocks sitemap need to have a huge <map:compoennt> section. > Hope it's clearer ;-) Not really, either you or me don't understand the blocks intend concerning component definitions/referentiation. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
