Re: Real blocks: some thoughts and questions
On Friday, Sep 19, 2003, at 09:35 Europe/Rome, Bertrand Delacretaz wrote: Le Jeudi, 11 sep 2003, à 20:11 Europe/Zurich, Bruno Dumon a écrit : ...Component lookup I'm wondering how component lookup will work. For example, suppose I have a block where I want to use FOP, i.e. the fo2pdf serializer. I'll make my block depend on the fop blok (or the more generic cob:apache.org/cocoon/fo2pdf role). Now how will using the serializer work? I assume I won't have to declare it in the map:components section of my sitemap anymore, since the instances of that serializer will be managed by the component manager of the fop block. So I'll just be able to write somewhere: Now how will the component manager know which of the depended blocks to ask for this component?... Do you mean, a) how to select the component if several blocks provide it, or b) how to avoid wasting time by asking all blocks? For a) I'd say the block manager has to assign priorities to blocks, in case there are multiple choices. For blocks which extend others it is clear, but for "siblings" blocks some rule will have to be set, either configurable priorities or loading order (dangerous if it is not deterministic), and careful logging of choices to be able to trace what's happening (also between core and blocks components). For b), I think the block manager will need one or several lookup maps to be able to quickly find components by role, name and maybe other criteria. I would take a much more brutal approach: the deployment manager will not deploy a block if there is a duplication of provided roles. in my mind, the above will increase cross-pollination between block developers forced by annoyed users. -- Stefano.
Re: Real blocks: some thoughts and questions
Le Jeudi, 11 sep 2003, à 20:11 Europe/Zurich, Bruno Dumon a écrit : ...Component lookup I'm wondering how component lookup will work. For example, suppose I have a block where I want to use FOP, i.e. the fo2pdf serializer. I'll make my block depend on the fop blok (or the more generic cob:apache.org/cocoon/fo2pdf role). Now how will using the serializer work? I assume I won't have to declare it in the map:components section of my sitemap anymore, since the instances of that serializer will be managed by the component manager of the fop block. So I'll just be able to write somewhere: Now how will the component manager know which of the depended blocks to ask for this component?... Do you mean, a) how to select the component if several blocks provide it, or b) how to avoid wasting time by asking all blocks? For a) I'd say the block manager has to assign priorities to blocks, in case there are multiple choices. For blocks which extend others it is clear, but for "siblings" blocks some rule will have to be set, either configurable priorities or loading order (dangerous if it is not deterministic), and careful logging of choices to be able to trace what's happening (also between core and blocks components). For b), I think the block manager will need one or several lookup maps to be able to quickly find components by role, name and maybe other criteria. -Bertrand
Re: Real blocks: some thoughts and questions
On Thursday, Sep 11, 2003, at 20:11 Europe/Rome, Bruno Dumon wrote: I've been reading through the most recent block related threads: Cocoon Blocks 1.1 [1] and Implementing Cocoon Blocks [2]. These two documents pretty much complement each other, the first mostly focussing on the blocks itself (not just a package but also inheritence and polymorphism), the second one more focussing on the block manager and block deployer. yes What I've written below are partly summaries and partly questions. I'm posting it here, if anyone can offer clarifications on some of this than that would be great, and otherwise it'll serve as input for the hackaton. I'll try to fill the gaps. = The main features that cocoon blocks have that are not in pure packaging solutions like war's are: * block dependencies, including polymorphism * block inheritence The first I quite understand, the second not so much. ok Dependencies between blocks --- If I got it right, the only dependencies we got between block are: - a block can use a component from another block (either a sitemap component or a generic Avalon component) - a block can call a pipeline described in the sitemap of another block, using the block: protocol correct Some things that would thus explicitely not be possible (at this point) are: - classloading dependencies: a block cannot depend on classes or jars inside another block yes, this is forbidden because it would create major issues with reloading and hot deployment. going thru the avalon machinery helps with this and keeps things sane. [note this is the same paradigm used in EJB] - resource dependencies: one block cannot directly access files (such as XSL's) in other blocks yes, we decided not to do this, expecially since it would have required two different internal-block URI spaces, one for the URLs provided by the sitemap and one of the one provided by the block. moreover, given the caching facilities we have, using readers to provide a transparent one-2-one mapping is just three sitemap lines away, would it be needed. - other sitemap dependencies: using flows, views or resources from a sitemap in another block. these are hidden on purpose since they very likely don't make sense alone (means: without the sitemap) One exception is that the yet-to-come virtual sitemap components (or whatever they're called) could be used across blocks. yes, since they will be much like other avalon blocks. Extending blocks (block inheritence) Reading the Cocoon Blocks 1.1 proposal [1] makes me think that block inheritance is a file-based thing, i.e. files not found in the extending block are taken from the extended block. Though in some other post in the discussion following on it, Stefano writes: "Here, when a sitemap *extends* another one, it's means of falling back: the two sitemaps are appended and if no matching happens in the first one, it falls back on the extended one." Which implies that the extending is more dynamic, i.e. there exist two sitemap interpreters at runtime etc. Other than that I couldn't find much information on block inheritence, so if anyone can shed more light on it, that would be very welcome. block inheritance started as a resource thing, that's right, but later evolved into a general URL thing. In short, when block A extends block B, the sitemap A is called and, if no pipeline is matched, instead of returning a 404, the sitemap A is called. Only if sitemap A doesn't match, the 404 is triggered. it's as simple as that. The reason for this is that I can "overload" some of the URL present in sitemap A without having to modify it. Mostly useful in skins and the like or in any environments where users of blocks might want to modify a few things of the original block, but without having to create their own version. just like in OOP, extending one object allows one to keep in synch with new versions of the extended objects without cut/paste code. the same will happen for blocks: if you change your logo of our skin, and we improve our skin, the improvements will be automatically inherited and you wouldn't have to do anything. in short terms, the above is sort of an interception mechanism for sitemaps, just very specific, because I don't think we need anything else for now. Component lookup I'm wondering how component lookup will work. For example, suppose I have a block where I want to use FOP, i.e. the fo2pdf serializer. I'll make my block depend on the fop blok (or the more generic cob:apache.org/cocoon/fo2pdf role). Now how will using the serializer work? I assume I won't have to declare it in the map:components section of my sitemap anymore, since the instances of that serializer will be managed by the component manager of the fop block. So I'll just be able to write somewhere: no, well, you have to declare your component as before the component man
Re: Real blocks: some thoughts and questions
I'm thinking aloud -- not claiming I've got the right answers... Bruno Dumon wrote: I've been reading through the most recent block related threads: Cocoon Blocks 1.1 [1] and Implementing Cocoon Blocks [2]. These two documents pretty much complement each other, the first mostly focussing on the blocks itself (not just a package but also inheritence and polymorphism), the second one more focussing on the block manager and block deployer. What I've written below are partly summaries and partly questions. I'm posting it here, if anyone can offer clarifications on some of this than that would be great, and otherwise it'll serve as input for the hackaton. = The main features that cocoon blocks have that are not in pure packaging solutions like war's are: * block dependencies, including polymorphism * block inheritence I'd add what seems to be generalized block services. A block is dependent on another block's service, so maybe they just go hand in hand with dependencies. The definition of exactly what that service is seems very general. In some cases, a file resource. In some a true component. In come, pipelines or pipeline fragments. Maybe more. The first I quite understand, the second not so much. Dependencies between blocks --- If I got it right, the only dependencies we got between block are: - a block can use a component from another block (either a sitemap component or a generic Avalon component) - a block can call a pipeline described in the sitemap of another block, using the block: protocol See above -- I'm not sure this is all there is. Some things that would thus explicitely not be possible (at this point) are: - classloading dependencies: a block cannot depend on classes or jars inside another block I think that's right - no direct dependency on them. - resource dependencies: one block cannot directly access files (such as XSL's) in other blocks Not sure if that's true or not. - other sitemap dependencies: using flows, views or resources from a sitemap in another block. I don't know. One exception is that the yet-to-come virtual sitemap components (or whatever they're called) could be used across blocks. Extending blocks (block inheritence) Reading the Cocoon Blocks 1.1 proposal [1] makes me think that block inheritance is a file-based thing, i.e. files not found in the extending block are taken from the extended block. Though in some other post in the discussion following on it, Stefano writes: "Here, when a sitemap *extends* another one, it's means of falling back: the two sitemaps are appended and if no matching happens in the first one, it falls back on the extended one." Which implies that the extending is more dynamic, i.e. there exist two sitemap interpreters at runtime etc. Other than that I couldn't find much information on block inheritence, so if anyone can shed more light on it, that would be very welcome. I interpret it to be service-based. A block exposes services which are interited/overridden by extending blocks. Component lookup I'm wondering how component lookup will work. For example, suppose I have a block where I want to use FOP, i.e. the fo2pdf serializer. I'll make my block depend on the fop blok (or the more generic cob:apache.org/cocoon/fo2pdf role). Now how will using the serializer work? I assume I won't have to declare it in the map:components section of my sitemap anymore, since the instances of that serializer will be managed by the component manager of the fop block. So I'll just be able to write somewhere: I think you'd have to use the block: protocol as you mention below? Now how will the component manager know which of the depended blocks to ask for this component? Check them one by one? Up to now all component managers are in a parent-child relationship, but blocks will need to use components from sibling blocks. Hope my explanation is clear enough. The block descriptor (block.xml, yet to be fleshed out) declares what a block "exposes". The deploy process wires the dependencies of one block to the exposed services of another. What your example brings up is the question: how does this work when services/resources are called from outside a block, as in a plain sitemap. Hmm, now that I think of it, with the block: protocol there is explicit block addressing: block:dependencyname:/something. Probably we'll have something similar for component lookups? That may answer the above question. Other various stuff --- * I assume the block's sitemaps won't have a parent sitemap, i.e. the Cocoon root sitemap will not be the parent sitemap for block sitemaps. I think that's right. The block mount-points get first crack at requests. They're more like super-sitemaps (not parents because the root sitemap won't inherit from them). * Currently sitemap components are managed by a sitemap component manager. I assume th
Real blocks: some thoughts and questions
I've been reading through the most recent block related threads: Cocoon Blocks 1.1 [1] and Implementing Cocoon Blocks [2]. These two documents pretty much complement each other, the first mostly focussing on the blocks itself (not just a package but also inheritence and polymorphism), the second one more focussing on the block manager and block deployer. What I've written below are partly summaries and partly questions. I'm posting it here, if anyone can offer clarifications on some of this than that would be great, and otherwise it'll serve as input for the hackaton. = The main features that cocoon blocks have that are not in pure packaging solutions like war's are: * block dependencies, including polymorphism * block inheritence The first I quite understand, the second not so much. Dependencies between blocks --- If I got it right, the only dependencies we got between block are: - a block can use a component from another block (either a sitemap component or a generic Avalon component) - a block can call a pipeline described in the sitemap of another block, using the block: protocol Some things that would thus explicitely not be possible (at this point) are: - classloading dependencies: a block cannot depend on classes or jars inside another block - resource dependencies: one block cannot directly access files (such as XSL's) in other blocks - other sitemap dependencies: using flows, views or resources from a sitemap in another block. One exception is that the yet-to-come virtual sitemap components (or whatever they're called) could be used across blocks. Extending blocks (block inheritence) Reading the Cocoon Blocks 1.1 proposal [1] makes me think that block inheritance is a file-based thing, i.e. files not found in the extending block are taken from the extended block. Though in some other post in the discussion following on it, Stefano writes: "Here, when a sitemap *extends* another one, it's means of falling back: the two sitemaps are appended and if no matching happens in the first one, it falls back on the extended one." Which implies that the extending is more dynamic, i.e. there exist two sitemap interpreters at runtime etc. Other than that I couldn't find much information on block inheritence, so if anyone can shed more light on it, that would be very welcome. Component lookup I'm wondering how component lookup will work. For example, suppose I have a block where I want to use FOP, i.e. the fo2pdf serializer. I'll make my block depend on the fop blok (or the more generic cob:apache.org/cocoon/fo2pdf role). Now how will using the serializer work? I assume I won't have to declare it in the map:components section of my sitemap anymore, since the instances of that serializer will be managed by the component manager of the fop block. So I'll just be able to write somewhere: Now how will the component manager know which of the depended blocks to ask for this component? Check them one by one? Up to now all component managers are in a parent-child relationship, but blocks will need to use components from sibling blocks. Hope my explanation is clear enough. Hmm, now that I think of it, with the block: protocol there is explicit block addressing: block:dependencyname:/something. Probably we'll have something similar for component lookups? Other various stuff --- * I assume the block's sitemaps won't have a parent sitemap, i.e. the Cocoon root sitemap will not be the parent sitemap for block sitemaps. * Currently sitemap components are managed by a sitemap component manager. I assume that with blocks, sitemap components will also have to be mangeable by the "main" block component managers? I.e. the fop block won't have to include a sitemap simply to declare the the fo2pdf serializer. That's it for now. [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103619609805268&w=2 [2] http://marc.theaimsgroup.com/?t=10613459123&r=1&w=2 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
