Re: [Proposal] Move Sources and Modules as top-level Cocoon components
Carsten Ziegeler wrote: Nicola Ken Barozzi wrote: Sources and Modules are incresingly important in Cocoon, and should be used and documented with more visibility. Yes. [...] Thus, I propose that input modules and sources have heir place in the org.apache.cocoon.* package space, and that are defined in the sitemap alongside other components, like their parents generators and actions. I totally agree with InputModules - and we discussed this already some weeks ago in the thread about the InputModules Interface. If you look at it, this interface was not directly intended for the use in the sitemap. So we should fix this (already discussed, too) as well. Ok, cool. Perhaps there is a better name for inputmodules but as I don't want to start a new thread about "what is the best name". I would like o.a.c.sitemap.inputmodules.* Ok, no thread ;-) but if anyone tonight has an illumination about the name, please let us know... :-> Ok, now to the sources... :) - the sources are a configuration on the application level, you once define which protocols you can use in your application and that's it. So, the cocoon.xconf is in my eyes the right place. Furthermore I see some technical problems with declaring a source in the sitemap. Now, if you follow this road, that every important aspect has to be in the sitemap, you can add the xsp logicsheet definitions there as well, because in the sitemap they are more visible for XSP developers. And so on. Actually I always thought that having them in cocoon.xconf was wrong, because it necessarily places them Cocoon-wide. So I would be +1 for it too. IMHO cocoon.xconf should keep only the Components needed by Cocoon itself, like the store... not developer resources. So I think we should leave them where they are. Your logic makes sense. IMV, but just IMV, Sources should be Components that are always used for Generators. But this actually is probably something that should be done in a revisitation of the Cocoon pipelines: This would actually decouple the Generator from the "get the stuff to process" part in a clearly defined way... probably food for thought for Cocoon3, dunno. Bottom line: let's keep sources Cocoon-wide till we find a compelling use-case, or till we have the decoupled sitemap.xconf working. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Proposal] Move Sources and Modules as top-level Cocoon components
Nicola Ken Barozzi wrote: > > Sources and Modules are incresingly important in Cocoon, and should be > used and documented with more visibility. > Yes. > Sources are IMHO a fundamental piece in Cocoon, because they separate > the retrival of data from the actual generation of SAX events in a > Generator. > > Input Modules are equally fundamental, as they give another degree of > freedom to the sitemap use-space. Yet they are defined in the xconf and > not in the sitemap as other components. > > Thus, I propose that input modules and sources have heir place in the > org.apache.cocoon.* package space, and that are defined in the sitemap > alongside other components, like their parents generators and actions. > I totally agree with InputModules - and we discussed this already some weeks ago in the thread about the InputModules Interface. If you look at it, this interface was not directly intended for the use in the sitemap. So we should fix this (already discussed, too) as well. Perhaps there is a better name for inputmodules but as I don't want to start a new thread about "what is the best name". I would like o.a.c.sitemap.inputmodules.* Ok, now to the sources... :) - the sources are a configuration on the application level, you once define which protocols you can use in your application and that's it. So, the cocoon.xconf is in my eyes the right place. Furthermore I see some technical problems with declaring a source in the sitemap. Now, if you follow this road, that every important aspect has to be in the sitemap, you can add the xsp logicsheet definitions there as well, because in the sitemap they are more visible for XSP developers. And so on. So I think we should leave them where they are. Bye Carsten Carsten Ziegeler Open Source Group, S&N AG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
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: > >>> > >> > >> > 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 > ? > > >>>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 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 > 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 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 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]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
Giacomo Pati wrote:
On Sat, 14 Dec 2002, Sylvain Wallez wrote:
Giacomo Pati wrote:
On Sat, 14 Dec 2002, Sylvain Wallez wrote:
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
?
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.
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.
This means that a block's sitemap will also contain a large
section, just like root sitemaps.
Therefore, with blocks, we will not only have large in
the root sitemap, but also in every block's sitemap.
Hope it's clearer ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
On Sat, 14 Dec 2002, Sylvain Wallez wrote: > Giacomo Pati wrote: > > >On Sat, 14 Dec 2002, Sylvain Wallez wrote: > > > > > > > >>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 > >> ? > >> > >> > > > >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. Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
Giacomo Pati wrote:
On Sat, 14 Dec 2002, Sylvain Wallez wrote:
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
?
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.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
On Sat, 14 Dec 2002, Sylvain Wallez wrote: > Giacomo Pati wrote: > > >On Fri, 13 Dec 2002, Nicola Ken Barozzi wrote: > > > > > > > >>Sylvain Wallez wrote: > >>[...] > >> > >> > >>> is getting bigger and bigger, and often bigger than > >>> itself. So what about allowing it to be in a separate > >>>file : > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>This can also be a first step towards the future structure of blocks. > >>> > >>> > >>At one time we wanted all the components in sitemap.xmap, at other times > >>we leaned to putting them in cocoon.xconf. > >> > >>After some time, this is MHO on the subject: > >> > >> - cocoon.xconf is just about the components that make up Cocoon > >>the contents are hardcoded or added by the build system for the > >>"features" and "environments" > >> > >> - sitemap.xmap is about defining the sitemap. Its components > >>can be declared in a separate file it references > >> > >> - components.xmap, or components.xcomp or sitemap.xcomp > >>or sitemap.xconf ... > >>holds component declarations for sitemaps, that can reference it. > >> > >>I know it's what you have just said, I just can't help being formal > >>these days ;-) > >> > >> > > > >I'm not very happy to add semantics for inclusion to the sitemap syntax. > >Can't we stick with DTD Entities to do it? > > > > > > Mmmmh... this is an immediate solution, even if I don't like it much : > it looks more like a hack to hide the problem. I know, ok. > Also, what about automatic reloading when the entity-defined part > changes ? Do we already handle this ? No, probably not. > >The details of the block architecture should give a solution to these > >problems (at least I see it that way). > > > > > > 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 > ? Yes. But the problem is IIRC only with the root sitemap, right? Giacomo > > >What do you think? > > > > Well, we have the problem _now_, and blocks aren't going to be there > tomorrow... > > Sylvain > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
Giacomo Pati wrote:
On Fri, 13 Dec 2002, Nicola Ken Barozzi wrote:
Sylvain Wallez wrote:
[...]
is getting bigger and bigger, and often bigger than
itself. So what about allowing it to be in a separate
file :
This can also be a first step towards the future structure of blocks.
At one time we wanted all the components in sitemap.xmap, at other times
we leaned to putting them in cocoon.xconf.
After some time, this is MHO on the subject:
- cocoon.xconf is just about the components that make up Cocoon
the contents are hardcoded or added by the build system for the
"features" and "environments"
- sitemap.xmap is about defining the sitemap. Its components
can be declared in a separate file it references
- components.xmap, or components.xcomp or sitemap.xcomp
or sitemap.xconf ...
holds component declarations for sitemaps, that can reference it.
I know it's what you have just said, I just can't help being formal
these days ;-)
I'm not very happy to add semantics for inclusion to the sitemap syntax.
Can't we stick with DTD Entities to do it?
Mmmmh... this is an immediate solution, even if I don't like it much :
it looks more like a hack to hide the problem.
Also, what about automatic reloading when the entity-defined part
changes ? Do we already handle this ?
The details of the block architecture should give a solution to these
problems (at least I see it that way).
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
?
What do you think?
Well, we have the problem _now_, and blocks aren't going to be there
tomorrow...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
On Fri, 13 Dec 2002, Nicola Ken Barozzi wrote: > > Sylvain Wallez wrote: > [...] > > is getting bigger and bigger, and often bigger than > > itself. So what about allowing it to be in a separate > > file : > > > > > > > > > > > > > > > > This can also be a first step towards the future structure of blocks. > > At one time we wanted all the components in sitemap.xmap, at other times > we leaned to putting them in cocoon.xconf. > > After some time, this is MHO on the subject: > > - cocoon.xconf is just about the components that make up Cocoon > the contents are hardcoded or added by the build system for the > "features" and "environments" > > - sitemap.xmap is about defining the sitemap. Its components > can be declared in a separate file it references > > - components.xmap, or components.xcomp or sitemap.xcomp > or sitemap.xconf ... > holds component declarations for sitemaps, that can reference it. > > I know it's what you have just said, I just can't help being formal > these days ;-) I'm not very happy to add semantics for inclusion to the sitemap syntax. Can't we stick with DTD Entities to do it? The details of the block architecture should give a solution to these problems (at least I see it that way). What do you think? Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
On Fri, 13 Dec 2002, Sylvain Wallez wrote: > is getting bigger and bigger, and often bigger than > itself. So what about allowing it to be in a separate file : > > > > > > One can still use Entities to externalize sections. Giacomo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
Christian Haul wrote: On 13.Dec.2002 -- 01:07 AM, Nicola Ken Barozzi wrote: Thus, I propose that input modules and sources have heir place in the org.apache.cocoon.* package space, and that are defined in the sitemap alongside other components, like their parents generators and actions. What's wrong with org.apache.cocoon.components.* ? These were IIRC originally only components that Cocoon and Cocoon components use to run themselves, not the components that the Cocoon sitemap contains. IE they are not the building blocks of the sitemap, but external services that Cocoon uses. [...] Thus we would have them in blocks; the ones with external dependencies in their own blocks, the others in a single block for each group. what would prevent this with the current package names ?? It's not the package names per se. If we make them into standard cocoon components, they are handled in blocks like other cocoon components, and can be referenced in sitemaps as such. Having Cocoon Components (ie Components for which Cocoon is the container) in mixed packages is confusing IMHO, but as you note not a technical issue. "generators and sources are of the same type in cocoon? Then why are the packages treated differently?" in addition +1 for sitemap.xconf / components.xconf Which already reduces the possible names :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
On 13.Dec.2002 -- 01:07 AM, Nicola Ken Barozzi wrote:
> Thus, I propose that input modules and sources have heir place in the
> org.apache.cocoon.* package space, and that are defined in the sitemap
> alongside other components, like their parents generators and actions.
What's wrong with org.apache.cocoon.components.* ?
> org.apache.cocoon.sources.*
+0.5
> org.apache.cocoon.modules.*
+0.5
>
> Also:
>
>
>
> ^^
>
>
>
>
>
>
>
> ^^
>
>
>
+1 (a default may be difficult for modules: {:something} ??)
> Thus we would have them in blocks; the ones with external dependencies
> in their own blocks, the others in a single block for each group.
what would prevent this with the current package names ??
in addition +1 for sitemap.xconf / components.xconf
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
Sylvain Wallez wrote: [...] is getting bigger and bigger, and often bigger than itself. So what about allowing it to be in a separate file : This can also be a first step towards the future structure of blocks. At one time we wanted all the components in sitemap.xmap, at other times we leaned to putting them in cocoon.xconf. After some time, this is MHO on the subject: - cocoon.xconf is just about the components that make up Cocoon the contents are hardcoded or added by the build system for the "features" and "environments" - sitemap.xmap is about defining the sitemap. Its components can be declared in a separate file it references - components.xmap, or components.xcomp or sitemap.xcomp or sitemap.xconf ... holds component declarations for sitemaps, that can reference it. I know it's what you have just said, I just can't help being formal these days ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Proposal] Move Sources and Modules as top-level Cocoon components
Nicola Ken Barozzi wrote:
Sources and Modules are incresingly important in Cocoon, and should be
used and documented with more visibility.
Sources are IMHO a fundamental piece in Cocoon, because they separate
the retrival of data from the actual generation of SAX events in a
Generator.
Agree. Sources allow some of the magical features of Cocoon : retreive a
content whatever its source using the same components as files.
Input Modules are equally fundamental, as they give another degree of
freedom to the sitemap use-space. Yet they are defined in the xconf
and not in the sitemap as other components.
Thus, I propose that input modules and sources have heir place in the
org.apache.cocoon.* package space, and that are defined in the sitemap
alongside other components, like their parents generators and actions.
+1
org.apache.cocoon.datasources.*
-1 : the word "datasource" is too much related to database stuff.
or
org.apache.cocoon.sources.*
+1.
I was wondering about the plural "source_s_" considering that most often
parckage names are singular. IMO, in this particular case it makes
sense, since it is a collection of Cocoon-specific implementations of an
interface defined elsewhere (in Excalibur).
and
org.apache.cocoon.inputmodules.*
or
org.apache.cocoon.modules.*
+1. Wondering also about plural here. But it's also OK, becaus we will
have "input", "output" and "inputoutput" subpackages.
Also:
^^
^^
+1.
is getting bigger and bigger, and often bigger than
itself. So what about allowing it to be in a separate file :
This can also be a first step towards the future structure of blocks.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
