You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/03/13 09:36:10 UTC
[RT] Flow as a block
The flow stuff is an "optional" component, which means I can use it
or not. Cocoon started as a web publishing framework and as flow is
not directly a core component for web publishing but for web
applications, I really would like to see flow as an own block
that I can either install or not.
Don't get me wrong, I like flow and I see the use of it, but flow
is an optional component in the same sense that for example the
portal framework is an optional component.
Unfortunately, separating out the flow stuff into an own block is
not that easy, I guess, as the main sitemap engine had to be extended
for it.
I'm thinking since last year about making the sitemap syntax pluggable,
so the basic idea is to install an own block that adds more syntax and
features to the sitemap. With that implemented, it would be easy
to make flow an own block.
I know that making the sitemap pluggable has some dangers, so this
is only a thought.
Anyway, regardless how it is solved, I would like to have the flow
separated into a block.
What do you think?
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
Re: [RT] Flow as a block
Posted by Upayavira <uv...@upaya.co.uk>.
> Ok. So we have some. I'll have a look at this.
Great. I'd be pleased to hear what you find.
> Ah, and there's no need to CC me privately as I closely monitor this
> list ;-)
Ok. My benevolent emailer does this for me without asking!!
Upayavira
Re: [RT] Flow as a block
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Upayavira wrote:
>>Do we have hard dependencies on servlet ? AFAIK we have some for those
>>components that can't live without it (e.g. JSPGenerator), but are
>>there others ?
>>
>>
>
>Try running the CLI without a reference to servlet-XXX.jar. It fails whilst loading in
>configs. I tried to work out why, but it was beyond my current expertise (probably
>because I don't have Avalon source installed). And the CLI certainly shouldn't need to
>know about servlet stuff.
>
>
Ok. So we have some. I'll have a look at this.
Ah, and there's no need to CC me privately as I closely monitor this
list ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: (In)Dependence on servlet - (Re: [RT] Flow as a block)
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Carsten Ziegeler wrote, On 14/03/2003 8.23:
>
>> Upayavira wrote_
>>
>>>> Do we have hard dependencies on servlet ? AFAIK we have some for those
>>>> components that can't live without it (e.g. JSPGenerator), but are
>>>> there others ?
>>>
>>>
>>> Try running the CLI without a reference to servlet-XXX.jar. It fails
>>> whilst loading in configs. I tried to work out why, but it was beyond
>>> my current expertise (probably because I don't have Avalon source
>>> installed). And the CLI certainly shouldn't need to know about
>>> servlet stuff.
>>>
>>
>> Ah, that's bad - it did work without the servlet api some time ago.
>
>
> Well, the fact is that some parts reference the CocoonServlet, and the
> StreamGenerator is usable only on Servlets! Ok, this has already been
> discussed, so I think we should get to a conclusion here.
>
> Proposal:
>
> 1) move all environments in separate ./src/environments dirs, that each
> generate a separate jar, exactly like the blocks are done ATM. In the
> future the blocks will be runtime pluggable, while environments will
> remain as static jars at load time.
True, this is another reason to have modules vs. blocks. Modules won't
be run-time pluggable.
> 2) add a methid to the Environmment to get a Stream from the request and
> make the StreamGenerator use it. It's true that Requests can have
> multiple streams, but I'll leave that case to a future discussion.
Yes, solve the issues when they arise.
> These two items will clearly show us the dependencies in our code, and
> eventually lighten the dependency between our Enviroment implementations.
True.
> Does this sound reasonable?
Yes, totally.
Re: (In)Dependence on servlet - (Re: [RT] Flow as a block)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Just a couple of corrections.
Carsten Ziegeler wrote, On 14/03/2003 14.13:
...
> Ok, we should consider adding libs to an environment directory as well,
> so the servlet.jar could become part of the servlet environment.
+1
...
> Shouldn't this be added to the Request? The StreamGenerator does not
> have access to the Environment obejct.
Sorry, I keep talking about the concept and use the classname.
Yes, it's the Request.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: (In)Dependence on servlet - (Re: [RT] Flow as a block)
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Well, the fact is that some parts reference the CocoonServlet, and the
> StreamGenerator is usable only on Servlets! Ok, this has already been
> discussed, so I think we should get to a conclusion here.
>
> Proposal:
>
> 1) move all environments in separate ./src/environments dirs, that each
> generate a separate jar, exactly like the blocks are done ATM. In the
> future the blocks will be runtime pluggable, while environments will
> remain as static jars at load time.
>
Ok, we should consider adding libs to an environment directory as well,
so the servlet.jar could become part of the servlet environment.
> 2) add a methid to the Environmment to get a Stream from the request and
> make the StreamGenerator use it. It's true that Requests can have
> multiple streams, but I'll leave that case to a future discussion.
>
Shouldn't this be added to the Request? The StreamGenerator does not
have access to the Environment obejct.
> These two items will clearly show us the dependencies in our code, and
> eventually lighten the dependency between our Enviroment implementations.
>
> Does this sound reasonable?
>
Yes!
Carsten
(In)Dependence on servlet - (Re: [RT] Flow as a block)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote, On 14/03/2003 8.23:
> Upayavira wrote_
>
>>>Do we have hard dependencies on servlet ? AFAIK we have some for those
>>>components that can't live without it (e.g. JSPGenerator), but are
>>>there others ?
>>
>>Try running the CLI without a reference to servlet-XXX.jar. It
>>fails whilst loading in
>>configs. I tried to work out why, but it was beyond my current
>>expertise (probably
>>because I don't have Avalon source installed). And the CLI
>>certainly shouldn't need to
>>know about servlet stuff.
>>
>
> Ah, that's bad - it did work without the servlet api some time ago.
Well, the fact is that some parts reference the CocoonServlet, and the
StreamGenerator is usable only on Servlets! Ok, this has already been
discussed, so I think we should get to a conclusion here.
Proposal:
1) move all environments in separate ./src/environments dirs, that each
generate a separate jar, exactly like the blocks are done ATM. In the
future the blocks will be runtime pluggable, while environments will
remain as static jars at load time.
2) add a methid to the Environmment to get a Stream from the request and
make the StreamGenerator use it. It's true that Requests can have
multiple streams, but I'll leave that case to a future discussion.
These two items will clearly show us the dependencies in our code, and
eventually lighten the dependency between our Enviroment implementations.
Does this sound reasonable?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Upayavira wrote_
>
> > Do we have hard dependencies on servlet ? AFAIK we have some for those
> > components that can't live without it (e.g. JSPGenerator), but are
> > there others ?
>
> Try running the CLI without a reference to servlet-XXX.jar. It
> fails whilst loading in
> configs. I tried to work out why, but it was beyond my current
> expertise (probably
> because I don't have Avalon source installed). And the CLI
> certainly shouldn't need to
> know about servlet stuff.
>
Ah, that's bad - it did work without the servlet api some time ago.
Carsten
Re: [RT] Flow as a block
Posted by Upayavira <uv...@upaya.co.uk>.
> Do we have hard dependencies on servlet ? AFAIK we have some for those
> components that can't live without it (e.g. JSPGenerator), but are
> there others ?
Try running the CLI without a reference to servlet-XXX.jar. It fails whilst loading in
configs. I tried to work out why, but it was beyond my current expertise (probably
because I don't have Avalon source installed). And the CLI certainly shouldn't need to
know about servlet stuff.
Regards, Upayavira
Re: [RT] Flow as a block
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
>
> Sylvain Wallez wrote, On 13/03/2003 13.43:
> ...
>
>> Furthermore, I second Carsten's opinion : there are a lot of projects
>> that don't need the flow (e.g. all publication apps). But every
>> application requires the sitemap, because XML pipelines are the very
>> heart of Cocoon.
>
>
> Or embedded ones, someone was working on it, right? ;-)
You got me ;-)
Since we're talking about futurisc things (or not that much, after all),
I still keep on my todo list (with a rather low priority) the
possibility to implement continuations on Java bytecode. The experience
of Brakes shows that this _is_ possible, and would then allow for
writing flow logic in Java.
> So in this spirit, I'd also like to see the environments separated (ie
> no more servlet hard dependency)
Do we have hard dependencies on servlet ? AFAIK we have some for those
components that can't live without it (e.g. JSPGenerator), but are there
others ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Flow as a block
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote, On 13/03/2003 13.43:
...
> Furthermore, I second Carsten's opinion : there are a lot of projects
> that don't need the flow (e.g. all publication apps). But every
> application requires the sitemap, because XML pipelines are the very
> heart of Cocoon.
Or embedded ones, someone was working on it, right? ;-)
So in this spirit, I'd also like to see the environments separated (ie
no more servlet hard dependency)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Flow as a block
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
>
> Carsten Ziegeler wrote, On 13/03/2003 9.36:
>
>> The flow stuff is an "optional" component, which means I can use it
>> or not. Cocoon started as a web publishing framework and as flow is
>> not directly a core component for web publishing but for web
>> applications, I really would like to see flow as an own block
>> that I can either install or not.
>> Don't get me wrong, I like flow and I see the use of it, but flow
>> is an optional component in the same sense that for example the
>> portal framework is an optional component.
>
>
> Honestly, I don't see this... I see the flow on par with the sitemap,
> and the sitemap is not an optional components.
>
> But the sitemap is pluggable so the flow should be too? I feel bells
> ringing about flexibility syndrome, with everything pluggable... I
> don't see that this will give us a big gain now, apart from some kind
> of architectural componentization.
This is exactly that : architectural componentization. Strongly separate
the components that don't _require_ to be hard linked.
Going back to the sitemap engine, we have to remember that in the early
2.0 versions, the Cocoon core had hard links to the compiled sitemap
engine. This prevented the use of an alternative implementation.
So before writing the treeprocessor, I started by cutting that link.
Without that, we would not have the treeprocessor that a lot of people
are enjoying today...
Furthermore, I second Carsten's opinion : there are a lot of projects
that don't need the flow (e.g. all publication apps). But every
application requires the sitemap, because XML pipelines are the very
heart of Cocoon.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote, On 13/03/2003 12.20:
> ...
> > I guess this comes down to the question of "what is the cocoon core?".
>
> AAARGGG, is this version two of the module-blocks naming discussion?
> ;-)))))
Yupp, it is :)
>
> Ok, I'm not necessarily agaisnt it, I'm trying to see the bigger
> picture, ie where it leads us to.
>
Ok.
> What is Cocoon... let's put it this way: what is the smallest unit of a
> working Cocoon? What should it do? Please bear me in this crazy RT, I
> think it's not so far fetched.
>
>
> Imagine that we have brought Cocoon componentization to the extreme.
> We could have these layers:
>
> Flow framework| implementation
> |----------------------------|-----------------|
> Sitemap framework| implementation
> |---------------------------|----------------|
> SAX pipeline framework| implementation
> |--------------------------|---------------|
> SAX components framework|implementation
> |----------------------------------------|
>
> The minimal Cocoon "thing" would be an Avalon Component called Block
> that can be reused as-is. For example, we could simply do in any part of
> a Java class:
>
> CocoonComponentManager.get("fop");
>
> And we could use that Component as a normal Java component.
>
> Then we could need to make a pipeline, and have the pipeline API, and
> implementation that can use the blocks.
>
> Then a sitemap, that aggregates these pipelines as we all know.
>
> Finally the flow, that does the workflow between requests.
>
>
> Where does this come from?
> Simply, I'm getting fed up with rewriting code always just to manage
> components in my projects, or hand-code pipelines ala JAXP. I'd like to
> use these patrts indipendently, but Cocoon is not made with this in
> mind, it even still does not have a simple way of programmatically
> setting up a simple SAX pipeline with inputstream->outputstream.
>
Yes, you're rt is not so far away; I guess, with the "real" blocks
we are very close to it. So we should keep this in mind when it comes
to the blocks implementation after 2.1
Carsten
Re: [RT] Flow as a block
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote, On 13/03/2003 12.20:
...
> I guess this comes down to the question of "what is the cocoon core?".
AAARGGG, is this version two of the module-blocks naming discussion?
;-)))))
> I talked last year with Stefano about this, and we both agreed that
> everything that is not required to run Cocooon, is optional and therefore
> a block. And we agreed that flow is optional and therefore a block.
> (Stefano, I hope I remember the discussion correctly here).
>
> Anyway, if we look at the current blocks, we have for example an html
> block. It is really hard to argument whether this block belongs to
> the core or not. The same applies for flow.
>
> Now, I think answering the question "Does flow belong to the core?" is
> very simple as it is introduced with 2.1, so it wasn't in 2.0 and is
> therefore an extension or optional.
> I have done many Cocoon projects over the last years and not a single
> project requires flow. (And this does *not* imply that flow is useless!)
>
> Making flow optional reduces the Cocoon core.
Ok, I'm not necessarily agaisnt it, I'm trying to see the bigger
picture, ie where it leads us to.
What is Cocoon... let's put it this way: what is the smallest unit of a
working Cocoon? What should it do? Please bear me in this crazy RT, I
think it's not so far fetched.
Imagine that we have brought Cocoon componentization to the extreme.
We could have these layers:
Flow framework| implementation
|----------------------------|-----------------|
Sitemap framework| implementation
|---------------------------|----------------|
SAX pipeline framework| implementation
|--------------------------|---------------|
SAX components framework|implementation
|----------------------------------------|
The minimal Cocoon "thing" would be an Avalon Component called Block
that can be reused as-is. For example, we could simply do in any part of
a Java class:
CocoonComponentManager.get("fop");
And we could use that Component as a normal Java component.
Then we could need to make a pipeline, and have the pipeline API, and
implementation that can use the blocks.
Then a sitemap, that aggregates these pipelines as we all know.
Finally the flow, that does the workflow between requests.
Where does this come from?
Simply, I'm getting fed up with rewriting code always just to manage
components in my projects, or hand-code pipelines ala JAXP. I'd like to
use these patrts indipendently, but Cocoon is not made with this in
mind, it even still does not have a simple way of programmatically
setting up a simple SAX pipeline with inputstream->outputstream.
For example, if someone wants to use the POI block to simply read an xml
file and create the corresponding xls file on disk, or do it through a
servlet... does he have to use all Cocoon, set it ip, and also have the
servlet API just to pass in the stream?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote, On 13/03/2003 9.36:
> > The flow stuff is an "optional" component, which means I can use it
> > or not. Cocoon started as a web publishing framework and as flow is
> > not directly a core component for web publishing but for web
> > applications, I really would like to see flow as an own block
> > that I can either install or not.
> > Don't get me wrong, I like flow and I see the use of it, but flow
> > is an optional component in the same sense that for example the
> > portal framework is an optional component.
>
> Honestly, I don't see this... I see the flow on par with the sitemap,
> and the sitemap is not an optional components.
>
> But the sitemap is pluggable so the flow should be too? I feel bells
> ringing about flexibility syndrome, with everything pluggable... I don't
> see that this will give us a big gain now, apart from some kind of
> architectural componentization.
>
I'm not sure if I understand you correctly, I don't want to make "flow
by itself pluggable". I want to make the sitemap pluggable, so that I
can plug-in the flow.
I guess this comes down to the question of "what is the cocoon core?".
I talked last year with Stefano about this, and we both agreed that
everything that is not required to run Cocooon, is optional and therefore
a block. And we agreed that flow is optional and therefore a block.
(Stefano, I hope I remember the discussion correctly here).
Anyway, if we look at the current blocks, we have for example an html
block. It is really hard to argument whether this block belongs to
the core or not. The same applies for flow.
Now, I think answering the question "Does flow belong to the core?" is
very simple as it is introduced with 2.1, so it wasn't in 2.0 and is
therefore an extension or optional.
I have done many Cocoon projects over the last years and not a single
project requires flow. (And this does *not* imply that flow is useless!)
Making flow optional reduces the Cocoon core.
Carsten
Re: [RT] Flow as a block
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote, On 13/03/2003 9.36:
> The flow stuff is an "optional" component, which means I can use it
> or not. Cocoon started as a web publishing framework and as flow is
> not directly a core component for web publishing but for web
> applications, I really would like to see flow as an own block
> that I can either install or not.
> Don't get me wrong, I like flow and I see the use of it, but flow
> is an optional component in the same sense that for example the
> portal framework is an optional component.
Honestly, I don't see this... I see the flow on par with the sitemap,
and the sitemap is not an optional components.
But the sitemap is pluggable so the flow should be too? I feel bells
ringing about flexibility syndrome, with everything pluggable... I don't
see that this will give us a big gain now, apart from some kind of
architectural componentization.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> >I'm thinking since last year about making the sitemap syntax pluggable,
> >so the basic idea is to install an own block that adds more syntax and
> >features to the sitemap. With that implemented, it would be easy
> >to make flow an own block.
> >
>
> I remember a discussion about this. What you would like is to have the
> treeprocessor configuration be defined in cocoon.xconf. I don't like it
> since I find cocoon.xconf to be way too complicated, too large and
> contain a lot of configuration that are "core" and never modified by the
> user (XSP logicsheets also fall into this category).
Ah, yes, one of my favorite discussions last year :) I guess, you know
my opinion about this, so...
(Note: the above is not ment seriously and Sylvain knows that)
>
> So what about some intermediate solution : the treeprocessor
> configuration would be based on a system-defined "base configuration"
> which can be augmented in cocoon.xconf. This would avoid having all of
> the core sitemap language in cocoon.xconf while offering the ability to
> extend it for specific blocks like the flow engine.
>
Sounds good to me!
> >I know that making the sitemap pluggable has some dangers, so
> this is only a thought.
> >
>
> One of the initial goals of the treeprocessor was to have a sitemap
> engine with an extensible and pluggable syntax. This was at a time where
> the flowscript did not existed and we were thinking of extending the
> sitemap language or inventing a new XML-based language for handling the
> flow. So all the infrastructure exists, we just have to polish the way
> the treeprocessor gets its configuration.
>
Ah, tricky! So, if we two have the same idea, it can't be wrong!
Great, I really like the tree processor more and more. It's not only
fast but extensible as well. Awesome.
So here is a big +10 for this.
Carsten
Re: [RT] Flow as a block
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>The flow stuff is an "optional" component, which means I can use it
>or not. Cocoon started as a web publishing framework and as flow is
>not directly a core component for web publishing but for web
>applications, I really would like to see flow as an own block
>that I can either install or not.
>
+1
>Don't get me wrong, I like flow and I see the use of it, but flow
>is an optional component in the same sense that for example the
>portal framework is an optional component.
>
Same feeling.
>Unfortunately, separating out the flow stuff into an own block is
>not that easy, I guess, as the main sitemap engine had to be extended
>for it.
>
Yes and no : some new types of nodes were defined, which implement the
flow-related sitemap syntax. All this is defined in the TreeProcessor
configuration file which, by default, is treeprocessor-builtins.xml.
>I'm thinking since last year about making the sitemap syntax pluggable,
>so the basic idea is to install an own block that adds more syntax and
>features to the sitemap. With that implemented, it would be easy
>to make flow an own block.
>
I remember a discussion about this. What you would like is to have the
treeprocessor configuration be defined in cocoon.xconf. I don't like it
since I find cocoon.xconf to be way too complicated, too large and
contain a lot of configuration that are "core" and never modified by the
user (XSP logicsheets also fall into this category).
So what about some intermediate solution : the treeprocessor
configuration would be based on a system-defined "base configuration"
which can be augmented in cocoon.xconf. This would avoid having all of
the core sitemap language in cocoon.xconf while offering the ability to
extend it for specific blocks like the flow engine.
>I know that making the sitemap pluggable has some dangers, so this is only a thought.
>
One of the initial goals of the treeprocessor was to have a sitemap
engine with an extensible and pluggable syntax. This was at a time where
the flowscript did not existed and we were thinking of extending the
sitemap language or inventing a new XML-based language for handling the
flow. So all the infrastructure exists, we just have to polish the way
the treeprocessor gets its configuration.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: (In)Dependence on servlet
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Upayavira wrote, On 14/03/2003 22.50:
>>
>>Well, actually the CLI has an additional jar needed, the CLI jar (soon
>>switch as Avalon is doing to commons-cli).
>
> Let me know when we're ready to do so, and I'll happily send in a patch to move to
> the commons-cli.
Even now. the sooner tha better :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: (In)Dependence on servlet
Posted by Upayavira <uv...@upaya.co.uk>.
> > Minor point, but seeing as the cli uses the bean, surely the CLI
> > environment should be replaced with a 'more generic'
> > bean-environment, rather than there being one of each.
>
> Well, actually the CLI has an additional jar needed, the CLI jar (soon
> switch as Avalon is doing to commons-cli).
Let me know when we're ready to do so, and I'll happily send in a patch to move to
the commons-cli.
> So I would not want to need to include that jar just for the "bean".
> So I'd keep them still separate but with one dependent on another.
Fair enough.
Upayavira
Re: (In)Dependence on servlet
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Upayavira wrote, On 14/03/2003 18.19:
> On 14 Mar 2003 at 10:54, Nicola Ken Barozzi wrote:
>
>
>>./src/modules/flow
>>./src/modules/servlet-environment
>>./src/modules/cli-environment
>>./src/modules/bean-environment
>>./src/modules/instrumentation
>>./src/deprecated <-- move it here for consistency
>
>
> Minor point, but seeing as the cli uses the bean, surely the CLI environment should
> be replaced with a 'more generic' bean-environment, rather than there being one of
> each.
Well, actually the CLI has an additional jar needed, the CLI jar (soon
switch as Avalon is doing to commons-cli).
So I would not want to need to include that jar just for the "bean". So
I'd keep them still separate but with one dependent on another.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
RE: (In)Dependence on servlet
Posted by Upayavira <uv...@upaya.co.uk>.
On 14 Mar 2003 at 10:54, Nicola Ken Barozzi wrote:
> ./src/modules/flow
> ./src/modules/servlet-environment
> ./src/modules/cli-environment
> ./src/modules/bean-environment
> ./src/modules/instrumentation
> ./src/deprecated <-- move it here for consistency
Minor point, but seeing as the cli uses the bean, surely the CLI environment should
be replaced with a 'more generic' bean-environment, rather than there being one of
each.
Upayavira
Re: [RT] Flow as a block
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Niclas Hedhman wrote, On 15/03/2003 11.01:
> On Saturday 15 March 2003 17:37, Nicola Ken Barozzi wrote:
>
...
>>Any suggestion on what you would want to have to create your customized
>>version of Cocoon given the above point?
>
> Well, I am not in that position, just came yo think about the possibility...
> OTOH, a lot can be solved with Java codebase security as well, so....???
But your's is indeed an important point. *Very* important, and more I
think of it, the more it becomes so to my eyes.
Thanks for pointing it out, it's fundamental we keep the eye on the
ball, and that means especially the Cocoon providers.
Someone has any ideas on this? Could simply removing some
implementations solve the problem, or have I overlooked something?
Correlated: where do we put all component implementations that till now
were in the core because they don't add dependencies?
When we talked about it last time in real life, it was between having
them in a "standard" block or keeping them in the core. But this still
doesn't give us granularity... maybe looking at them one by one will
give us more info...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Flow as a block
Posted by Niclas Hedhman <ni...@internuscorp.com>.
On Saturday 15 March 2003 17:37, Nicola Ken Barozzi wrote:
> Niclas Hedhman wrote, On 15/03/2003 9.25:
> > On Friday 14 March 2003 22:01, Nicola Ken Barozzi wrote:
> >>Stefano Mazzocchi wrote, On 14/03/2003 14.49:
> >>>But I would like to be able to build cocoon without them and prevent
> >>>people with the ability to use them to solve their problems. Just like
> >>>Carsten wants to do with the flow or XSP.
> >>
> >>That's not the reason IIUC.
> >>Flow adds new dependencies to Cocoon as jars, actions do not. What is
> >>the technical reason why actions have to be able to be removed?
> >>
> >>If you don't want to use them, don't. Since people will be able to
> >>compile with the support in, they will do so, and you will not prevent
> >>them to use actions (nor ATM it's desireable).
> >
> > Well, if you become a Cocoon hosting service, you may have a different
> > opinion of what other people can do in their sitemaps.
>
> Good point... if only removing actions would be a solution. If I were a
> Cocoon hosting service, I would want complete control on all the
> components that users can use, but that has nothing to do with Actions
> per se IIUC, but about the implementations of Cocoon components and the
> possibility of using them.
>
> Any suggestion on what you would want to have to create your costomized
> version of Cocoon given the above point?
Well, I am not in that position, just came yo think about the possibility...
OTOH, a lot can be solved with Java codebase security as well, so....???
Niclas
Re: [RT] Flow as a block
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Niclas Hedhman wrote, On 15/03/2003 9.25:
> On Friday 14 March 2003 22:01, Nicola Ken Barozzi wrote:
>
>>Stefano Mazzocchi wrote, On 14/03/2003 14.49:
>>
>>>But I would like to be able to build cocoon without them and prevent
>>>people with the ability to use them to solve their problems. Just like
>>>Carsten wants to do with the flow or XSP.
>>
>>That's not the reason IIUC.
>>Flow adds new dependencies to Cocoon as jars, actions do not. What is
>>the technical reason why actions have to be able to be removed?
>>
>>If you don't want to use them, don't. Since people will be able to
>>compile with the support in, they will do so, and you will not prevent
>>them to use actions (nor ATM it's desireable).
>
> Well, if you become a Cocoon hosting service, you may have a different opinion
> of what other people can do in their sitemaps.
Good point... if only removing actions would be a solution. If I were a
Cocoon hosting service, I would want complete control on all the
components that users can use, but that has nothing to do with Actions
per se IIUC, but about the implementations of Cocoon components and the
possibility of using them.
Any suggestion on what you would want to have to create your costomized
version of Cocoon given the above point?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Flow as a block
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Niclas Hedhman wrote, On 15/03/2003 9.25:
> On Friday 14 March 2003 22:01, Nicola Ken Barozzi wrote:
>
>>Stefano Mazzocchi wrote, On 14/03/2003 14.49:
>>
>>>But I would like to be able to build cocoon without them and prevent
>>>people with the ability to use them to solve their problems. Just like
>>>Carsten wants to do with the flow or XSP.
>>
>>That's not the reason IIUC.
>>Flow adds new dependencies to Cocoon as jars, actions do not. What is
>>the technical reason why actions have to be able to be removed?
>>
>>If you don't want to use them, don't. Since people will be able to
>>compile with the support in, they will do so, and you will not prevent
>>them to use actions (nor ATM it's desireable).
>
> Well, if you become a Cocoon hosting service, you may have a different opinion
> of what other people can do in their sitemaps.
Good point... if only removing actions would be a solution. If I were a
Cocoon hosting service, I would want complete control on all the
components that users can use, but that has nothing to do with Actions
per se IIUC, but about the implementations of Cocoon components and the
possibility of using them.
Any suggestion on what you would want to have to create your costomized
version of Cocoon given the above point?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Flow as a block
Posted by Stefano Mazzocchi <st...@apache.org>.
Niclas Hedhman wrote:
> On Friday 14 March 2003 22:01, Nicola Ken Barozzi wrote:
>
>>Stefano Mazzocchi wrote, On 14/03/2003 14.49:
>>
>>>But I would like to be able to build cocoon without them and prevent
>>>people with the ability to use them to solve their problems. Just like
>>>Carsten wants to do with the flow or XSP.
>>
>>That's not the reason IIUC.
>>Flow adds new dependencies to Cocoon as jars, actions do not. What is
>>the technical reason why actions have to be able to be removed?
>>
>>If you don't want to use them, don't. Since people will be able to
>>compile with the support in, they will do so, and you will not prevent
>>them to use actions (nor ATM it's desireable).
>
>
> Well, if you become a Cocoon hosting service, you may have a different opinion
> of what other people can do in their sitemaps.
That's for one.
But it's also for any product/service that I might want to build using
cocoon as the internal engine.
Just like I didn't vote -1 on the actions when they were proposed
because I didn't want to block the evolution of this project, I
appreciated the fact that people that disliked the flow approach didn't
vote -1 but now ask to be able to remove it.
I just ask the same freedom to remove support on my own builds for
things I don't like. Also to force myself to think at better solutions.
Note that they will be included by default, so this doesn't create any
back-compatibility issue whatsoever. It's just an additional freedom for
those of us who need to personalize their builds.
Stefano.
Re: [RT] Flow as a block
Posted by Niclas Hedhman <ni...@internuscorp.com>.
On Friday 14 March 2003 22:01, Nicola Ken Barozzi wrote:
> Stefano Mazzocchi wrote, On 14/03/2003 14.49:
> > But I would like to be able to build cocoon without them and prevent
> > people with the ability to use them to solve their problems. Just like
> > Carsten wants to do with the flow or XSP.
>
> That's not the reason IIUC.
> Flow adds new dependencies to Cocoon as jars, actions do not. What is
> the technical reason why actions have to be able to be removed?
>
> If you don't want to use them, don't. Since people will be able to
> compile with the support in, they will do so, and you will not prevent
> them to use actions (nor ATM it's desireable).
Well, if you become a Cocoon hosting service, you may have a different opinion
of what other people can do in their sitemaps.
Niclas
Re: [RT] Flow as a block
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 14/03/2003 14.49:
> Nicola Ken Barozzi wrote:
>
...
>> - people don't like/use actions and would like to see support for it
>> removed
>>
>> ? I regard actions on par with all other Cocoon Sitemap Components.
>
> I, for one, don't.
We know, we know ;-P
>> They are part of our basic sitemap contract IMHO, I would keep them
>> in, also because it does not bloat Cocoon or add additional dependencies.
>
> But I would like to be able to build cocoon without them and prevent
> people with the ability to use them to solve their problems. Just like
> Carsten wants to do with the flow or XSP.
That's not the reason IIUC.
Flow adds new dependencies to Cocoon as jars, actions do not. What is
the technical reason why actions have to be able to be removed?
If you don't want to use them, don't. Since people will be able to
compile with the support in, they will do so, and you will not prevent
them to use actions (nor ATM it's desireable).
Is this a soft deprecation of actions? ;-)
>> - people dont' like/use the avalon instrumentation and would like to
>> see support for it removed
>>
>> This is tricky, Instrumentation is an "aspect", and thus cannot
>> cleanly be separated ala OOP. How do we do this?!?
>
> Yes, tricky. I wonder how useful instrumentation is given that java 1.4
> has pretty damn serious remote debugging interfaces.
And damn slow I may say. Instrumentation can instead be used in
production to monitor the app. A different domain AFAIK.
>> All the above can be done, but a question remains: how do we
>> physically manage them?
>>
>> That is, I propose the we simply compile them as the blocks are
>> compiled now, with explicit dependencied and needed jars, the
>> compilation exclustions, and samples...
>>
>> Shall e have a .src/modules/** hierarchy?
>>
>> ./src/modules/flow
>> ./src/modules/servlet-environment
>> ./src/modules/cli-environment
>> ./src/modules/bean-environment
>> ./src/modules/instrumentation
>> ./src/deprecated <-- move it here for consistency
>> ...
>
>
> it doesn't matter where we put it, but how we do it.
>
> removing actions and the flow is just a matter of moving classes and
> patching the treeprocess configurations. xconftool can be used for that.
>
> removing XSP and the compiled language components can be done by moving
> them and patching the configurations with the xconftool
>
> I don't know about the servlet dependency.
Easy: put the code as outlined above, and see if it compiles (as said on
the other thread). As done with the blocks.
> I have no idea on the instrumentation since we might require to
> 'aspectize' our code and this means java pre-processing and I don't
> think I like this approach. What about virtual AOP thru proxies? but
> that should be something done by the classloader, I think...hmmm.
Yes, but not easy ATM. Instead of thinking in theory, where is
instrumentation used? (the lines of code)
Where should it be used?
Then we can see if it can be done with runtime code decoration.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Flow as a block
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Stefano Mazzocchi wrote, On 14/03/2003 10.31:
> ...
>
>> First of all, there is a major architectural difference between moving
>> the portal-framework into a block and moving flow into a block. Why?
>> because the first is 'on top' of cocoon, the second is 'in cocoon'.
>
>
> Nicely worded. I agree.
>
>> Now, I agree with Carsten that there are people that don't like some
>> of the cocoon functionalities and would like them removed.
>
>
> Yes (this is the need we need to solve, let's look at the solution)
>
>> So, since these are RT, let us say that we have:
>>
>> - blocks -> things that implement functionality on top
>> - modules -> things that add functionality inside
>>
>> why this difference?
>>
>> Because I expect the number of blocks to grow wildly in the next few
>> years, but I DO NOT want to see modules grow wildly or this will only
>> reflect on poor ability for us to define, document and validate them.
>
>
> Here it is. It's the same conclusion we had come to some time back, but
> now things are more clear and IMHO the time is more "right" now.
>
>> - o -
>>
>> So, how do we do it?
>
>
> Ok, let's see them one by one:
>
>
> - people use cocoon in a non-servlet environment and would like to see
> all servlet hooks removed
>
>
> See the thread (In)Dependence on servlet, IMHO it's big enough to want a
> separate thread.
>
>
> - people don't like/use XSP and would like to see dependencies on java
> compilers removed
>
> Agreed. Now that the sitemap is not compiled, it makes sense.
>
>
> - people don't like/use the flow and would like to see support for it
> removed
>
> Ok.
>
> - people don't like/use actions and would like to see support for it
> removed
>
> ? I regard actions on par with all other Cocoon Sitemap Components.
I, for one, don't.
> They
> are part of our basic sitemap contract IMHO, I would keep them in, also
> because it does not bloat Cocoon or add additional dependencies.
But I would like to be able to build cocoon without them and prevent
people with the ability to use them to solve their problems. Just like
Carsten wants to do with the flow or XSP.
> - people dont' like/use the avalon instrumentation and would like to
> see support for it removed
>
> This is tricky, Instrumentation is an "aspect", and thus cannot cleanly
> be separated ala OOP. How do we do this?!?
Yes, tricky. I wonder how useful instrumentation is given that java 1.4
has pretty damn serious remote debugging interfaces.
> All the above can be done, but a question remains: how do we physically
> manage them?
>
> That is, I propose the we simply compile them as the blocks are compiled
> now, with explicit dependencied and needed jars, the compilation
> exclustions, and samples...
>
> Shall e have a .src/modules/** hierarchy?
>
> ./src/modules/flow
> ./src/modules/servlet-environment
> ./src/modules/cli-environment
> ./src/modules/bean-environment
> ./src/modules/instrumentation
> ./src/deprecated <-- move it here for consistency
> ...
it doesn't matter where we put it, but how we do it.
removing actions and the flow is just a matter of moving classes and
patching the treeprocess configurations. xconftool can be used for that.
removing XSP and the compiled language components can be done by moving
them and patching the configurations with the xconftool
I don't know about the servlet dependency.
I have no idea on the instrumentation since we might require to
'aspectize' our code and this means java pre-processing and I don't
think I like this approach. What about virtual AOP thru proxies? but
that should be something done by the classloader, I think...hmmm.
Re: [RT] Flow as a block
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 14/03/2003 10.31:
...
> First of all, there is a major architectural difference between moving
> the portal-framework into a block and moving flow into a block. Why?
> because the first is 'on top' of cocoon, the second is 'in cocoon'.
Nicely worded. I agree.
> Now, I agree with Carsten that there are people that don't like some of
> the cocoon functionalities and would like them removed.
Yes (this is the need we need to solve, let's look at the solution)
> So, since these are RT, let us say that we have:
>
> - blocks -> things that implement functionality on top
> - modules -> things that add functionality inside
>
> why this difference?
>
> Because I expect the number of blocks to grow wildly in the next few
> years, but I DO NOT want to see modules grow wildly or this will only
> reflect on poor ability for us to define, document and validate them.
Here it is. It's the same conclusion we had come to some time back, but
now things are more clear and IMHO the time is more "right" now.
> - o -
>
> So, how do we do it?
Ok, let's see them one by one:
- people use cocoon in a non-servlet environment and would like to see
all servlet hooks removed
See the thread (In)Dependence on servlet, IMHO it's big enough to want a
separate thread.
- people don't like/use XSP and would like to see dependencies on java
compilers removed
Agreed. Now that the sitemap is not compiled, it makes sense.
- people don't like/use the flow and would like to see support for it
removed
Ok.
- people don't like/use actions and would like to see support for it
removed
? I regard actions on par with all other Cocoon Sitemap Components. They
are part of our basic sitemap contract IMHO, I would keep them in, also
because it does not bloat Cocoon or add additional dependencies.
- people dont' like/use the avalon instrumentation and would like to
see support for it removed
This is tricky, Instrumentation is an "aspect", and thus cannot cleanly
be separated ala OOP. How do we do this?!?
All the above can be done, but a question remains: how do we physically
manage them?
That is, I propose the we simply compile them as the blocks are compiled
now, with explicit dependencied and needed jars, the compilation
exclustions, and samples...
Shall e have a .src/modules/** hierarchy?
./src/modules/flow
./src/modules/servlet-environment
./src/modules/cli-environment
./src/modules/bean-environment
./src/modules/instrumentation
./src/deprecated <-- move it here for consistency
...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Flow as a block
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
>> Now, if my sitemap doesn't use *any* flow elements, would the jar need
>> to be in the classloader?
>
> Nope, since the flow-related treeprocessor classes deal with flow
> interfaces rather than with the JS implementation. So we need the
> flow-related interfaces (only o.a.c.c.flow.Interpreter AFAICS) to be
> present in the core, but can perfectly live without the implementation
> jars.
Uh, cool. I don't think that Carsten is against having a few Kb of
classes in the cocoon.jar as long as he can take the rhyno.jar away.
That would pretty much solve the issue without having to do anything.
Carsten?
Re: [RT] Flow as a block
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>>>
>>>> But won't work :-(
>>>>
>>>>
>>>
>>>
>>> :)
>>>
>>>
>>>
>>>> Why ? Well, yes, a sitemap element = a builder class. But the
>>>> configuration file that defines them is used to feed a
>>>> ComponentSelector, which will try to load the class and the result is
>>>> that you will get an Exception in the initialization phase of the
>>>> TreeProcessor...
>>>>
>>>> The only viable solution is for the declaration to be _not present_ in
>>>> the treeprocessor configuration.
>>>>
>>>>
>>>
>>>
>>> This is not the best solution, as it would required to change the
>>> treeprocessor conf for adding/removing flow.
>>>
>>> Could the treeprocessor check the availability of a class before
>>> feeding
>>> it into the selector? If the class is not available, a dummy
>>> implementation
>>> could be perhaps added that could - when used - throw a meaningfull
>>> exception.
>>>
>>>
>>
>> Well, this would mean rewriting a ComponenentSelector specifically
>> for this purpose, since the TreeProcessor does nothing more than
>> delegating all this stuff to a CS : see
>> DefaultTreeBuilder.createBuilderSelector().
>>
>> Mmmh... A good solution may be to have a FakeFlowNodeBuilder that
>> delegates to a RealFlowNodeBuilder if it's present in the classpath,
>> and otherwise fails with a nice error message saying that the flow
>> isn't installed.
>>
>> That way, we don't have to open wide the sitemap language definition,
>> which could lead to abuses : map:flow becomes an optional element
>> that is however pre-configured in the sitemap definition. Just drop
>> in the flow jar and it becomes available, without touching a single
>> configuration file.
>>
>> Thoughts ?
>
>
> I personally don't like it. Adding fake facades for just one thing
> doesn't sound right at all.
>
> I think that Carsten's problem is to have an external dependency on
> the rhino jar. Please, Carsten, correct me if I'm wrong.
>
> Now, if my sitemap doesn't use *any* flow elements, would the jar need
> to be in the classloader?
Nope, since the flow-related treeprocessor classes deal with flow
interfaces rather than with the JS implementation. So we need the
flow-related interfaces (only o.a.c.c.flow.Interpreter AFAICS) to be
present in the core, but can perfectly live without the implementation jars.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Flow as a block
Posted by Vadim Gritsenko <va...@verizon.net>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
>> Carsten Ziegeler wrote:
>
<snip/>
>>> Could the treeprocessor check the availability of a class before
>>> feeding
>>> it into the selector? If the class is not available, a dummy
>>> implementation
>>> could be perhaps added that could - when used - throw a meaningfull
>>> exception.
>>
>>
>> Well, this would mean rewriting a ComponenentSelector specifically
>> for this purpose, since the TreeProcessor does nothing more than
>> delegating all this stuff to a CS : see
>> DefaultTreeBuilder.createBuilderSelector().
>>
>> Mmmh... A good solution may be to have a FakeFlowNodeBuilder that
>> delegates to a RealFlowNodeBuilder if it's present in the classpath,
>> and otherwise fails with a nice error message saying that the flow
>> isn't installed.
>>
>> That way, we don't have to open wide the sitemap language definition,
>> which could lead to abuses : map:flow becomes an optional element
>> that is however pre-configured in the sitemap definition. Just drop
>> in the flow jar and it becomes available, without touching a single
>> configuration file.
>>
>> Thoughts ?
>
>
> I personally don't like it. Adding fake facades for just one thing
> doesn't sound right at all.
<me-too/>
Please let's do without kludges.
Vadim
Re: [RT] Flow as a block
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stefano Mazzocchi wrote, On 20/03/2003 12.23:
>
>> Carsten Ziegeler wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>> Why can't se simply postpone module-creation this after 2.1? I don't
>>>> think it's worth delaying further for a simple 50kb less of cocoon.jar
>>>>
>>>
>>> I agreed that we move this issue into 2.2 or whatever and that this
>>> should not delay 2.1 - so for me, it's pretty clear that these
>>> discussions
>>> do not affect 2.1.
>>
>>
>> Ok, good.
>>
>> So, for now, let's fix the FOM in the best elegant way we can find.
>
>
> I agree. Just one thing... anyone against me (in case) making a module
> for the servlet-environment so to hash out servlet dependency?
Please don't, we'll think about modules for 2.2, we have enough stuff to
do for 2.1 already.
Stefano.
Re: [RT] Flow as a block
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 20/03/2003 12.23:
> Carsten Ziegeler wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> Why can't se simply postpone module-creation this after 2.1? I don't
>>> think it's worth delaying further for a simple 50kb less of cocoon.jar
>>>
>>
>> I agreed that we move this issue into 2.2 or whatever and that this
>> should not delay 2.1 - so for me, it's pretty clear that these
>> discussions
>> do not affect 2.1.
>
> Ok, good.
>
> So, for now, let's fix the FOM in the best elegant way we can find.
I agree. Just one thing... anyone against me (in case) making a module
for the servlet-environment so to hash out servlet dependency?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Flow as a block
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>>Why can't se simply postpone module-creation this after 2.1? I don't
>>think it's worth delaying further for a simple 50kb less of cocoon.jar
>>
>
> I agreed that we move this issue into 2.2 or whatever and that this
> should not delay 2.1 - so for me, it's pretty clear that these discussions
> do not affect 2.1.
Ok, good.
So, for now, let's fix the FOM in the best elegant way we can find.
Stefano.
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Why can't se simply postpone module-creation this after 2.1? I don't
> think it's worth delaying further for a simple 50kb less of cocoon.jar
>
I agreed that we move this issue into 2.2 or whatever and that this
should not delay 2.1 - so for me, it's pretty clear that these discussions
do not affect 2.1.
Carsten
Re: [RT] Flow as a block
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>>I personally don't like it. Adding fake facades for just one thing
>>doesn't sound right at all.
>>
>>I think that Carsten's problem is to have an external dependency on the
>>rhino jar. Please, Carsten, correct me if I'm wrong.
>>
>
> Not exactly. Yes, I don't want to have the rhino jar (and possibly others
> only used by flow). But I also want to have meaningful error messages,
> if I use flow in the sitemap but does not have "installed" flow.
> And if, for example, flow would be implemented by "a lot of classes" in
> Cocoon, I also don't want to have this overhead.
> So, in the end: if I don't want to use flow in my app, I simly don't want
> any part of it, neither any jars nor any compiled cocoon flow stuff. :)
Well, it is pretty evident from all these discussions that flow is not a
block but a module and modules represent *aspects* of the core and can't
be removed without major refactoring/rearchitecting.
currently the flow in simplemented with a some 50Kb of java+javascript
files inside cocoon.jar. I don't think those 50kb will kill anybody.
If you don't use them, you can avoid shipping rhino with it (there is
nothing else used by the flow).
As for meaningful messages, the treeprocessor should give *meaningful*
messages for everything that is missing, not only flow.
>>Now, if my sitemap doesn't use *any* flow elements, would the jar need
>>to be in the classloader?
>
> I don't think that this is always working. If a flow class in Cocoon
> directly references/uses one of the rhino classes, then this might cause
> problems.
If the treeprocessor doesn't pre-load instances of the interface that
define those components, there is no direct reference. if this is not
the case, it's a bug and it's easily fixed.
> So, getting technically: the treeprocessor uses a selector that returns
> for an element used in the sitemap the corresponding builder. I still
> think, that this selector could return a dummy implementation, if the
> required builder class is not available.
This needs a specially crafted cocoon component manager or a
treeprocessor-specific wrapper around it.
> The flow would still be configured in the tree processor configuration
> and I can leave out everything of the flow stuff if I don't need it.
> And in addition: the dummy implementation can give meaningful error
> messages.
>
> What do you think?
Why can't se simply postpone module-creation this after 2.1? I don't
think it's worth delaying further for a simple 50kb less of cocoon.jar
Stefano.
Re: [RT] Flow as a block
Posted by Christopher Oliver <re...@verizon.net>.
Uh, Rhino isn't only used by the flow. It appears to also be used by:
JSGenerator.java
CompiledJavaScriptLanguage.java
Also, for what it's worth, although the jxpath jar is in lib/optional
there seem to be dependencies on it elsewhere in the core (not just in
flow code), e.g:
org/apache/cocoon/components/modules/input/AbstractJXPathModule.java
org/apache/cocoon/components/modules/input/JXPathMetaModule.java
org/apache/cocoon/components/validation/schematron/SchematronFactory.java
org/apache/cocoon/components/validation/schematron/SchematronValidator.ja
org/apache/cocoon/transformation/XMLFormTransformer.java
Do you hava a plan for removing the InputModule and XMLForm code from
the core as well?
Regards,
Chris
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>>I personally don't like it. Adding fake facades for just one thing
>>doesn't sound right at all.
>>
>>I think that Carsten's problem is to have an external dependency on the
>>rhino jar. Please, Carsten, correct me if I'm wrong.
>>
>
> Not exactly. Yes, I don't want to have the rhino jar (and possibly others
> only used by flow). But I also want to have meaningful error messages,
> if I use flow in the sitemap but does not have "installed" flow.
> And if, for example, flow would be implemented by "a lot of classes" in
> Cocoon, I also don't want to have this overhead.
> So, in the end: if I don't want to use flow in my app, I simly don't want
> any part of it, neither any jars nor any compiled cocoon flow stuff. :)
>
>
>>Now, if my sitemap doesn't use *any* flow elements, would the jar need
>>to be in the classloader?
>
> I don't think that this is always working. If a flow class in Cocoon
> directly references/uses one of the rhino classes, then this might cause
> problems.
>
> So, getting technically: the treeprocessor uses a selector that returns
> for an element used in the sitemap the corresponding builder. I still
> think, that this selector could return a dummy implementation, if the
> required builder class is not available.
> The flow would still be configured in the tree processor configuration
> and I can leave out everything of the flow stuff if I don't need it.
> And in addition: the dummy implementation can give meaningful error
> messages.
>
> What do you think?
>
> Carsten
>
> Carsten Ziegeler
> Open Source Group, S&N AG
> http://radio.weblogs.com/0107211/
>
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> I personally don't like it. Adding fake facades for just one thing
> doesn't sound right at all.
>
> I think that Carsten's problem is to have an external dependency on the
> rhino jar. Please, Carsten, correct me if I'm wrong.
>
Not exactly. Yes, I don't want to have the rhino jar (and possibly others
only used by flow). But I also want to have meaningful error messages,
if I use flow in the sitemap but does not have "installed" flow.
And if, for example, flow would be implemented by "a lot of classes" in
Cocoon, I also don't want to have this overhead.
So, in the end: if I don't want to use flow in my app, I simly don't want
any part of it, neither any jars nor any compiled cocoon flow stuff. :)
> Now, if my sitemap doesn't use *any* flow elements, would the jar need
> to be in the classloader?
I don't think that this is always working. If a flow class in Cocoon
directly references/uses one of the rhino classes, then this might cause
problems.
So, getting technically: the treeprocessor uses a selector that returns
for an element used in the sitemap the corresponding builder. I still
think, that this selector could return a dummy implementation, if the
required builder class is not available.
The flow would still be configured in the tree processor configuration
and I can leave out everything of the flow stuff if I don't need it.
And in addition: the dummy implementation can give meaningful error
messages.
What do you think?
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
http://radio.weblogs.com/0107211/
Re: [RT] Flow as a block
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
>>
>>> But won't work :-(
>>>
>>>
>>
>> :)
>>
>>
>>
>>> Why ? Well, yes, a sitemap element = a builder class. But the
>>> configuration file that defines them is used to feed a
>>> ComponentSelector, which will try to load the class and the result is
>>> that you will get an Exception in the initialization phase of the
>>> TreeProcessor...
>>>
>>> The only viable solution is for the declaration to be _not present_ in
>>> the treeprocessor configuration.
>>>
>>>
>>
>> This is not the best solution, as it would required to change the
>> treeprocessor conf for adding/removing flow.
>>
>> Could the treeprocessor check the availability of a class before feeding
>> it into the selector? If the class is not available, a dummy
>> implementation
>> could be perhaps added that could - when used - throw a meaningfull
>> exception.
>>
>>
>
> Well, this would mean rewriting a ComponenentSelector specifically for
> this purpose, since the TreeProcessor does nothing more than delegating
> all this stuff to a CS : see DefaultTreeBuilder.createBuilderSelector().
>
> Mmmh... A good solution may be to have a FakeFlowNodeBuilder that
> delegates to a RealFlowNodeBuilder if it's present in the classpath, and
> otherwise fails with a nice error message saying that the flow isn't
> installed.
>
> That way, we don't have to open wide the sitemap language definition,
> which could lead to abuses : map:flow becomes an optional element that
> is however pre-configured in the sitemap definition. Just drop in the
> flow jar and it becomes available, without touching a single
> configuration file.
>
> Thoughts ?
I personally don't like it. Adding fake facades for just one thing
doesn't sound right at all.
I think that Carsten's problem is to have an external dependency on the
rhino jar. Please, Carsten, correct me if I'm wrong.
Now, if my sitemap doesn't use *any* flow elements, would the jar need
to be in the classloader?
Stefano.
Re: [RT] Flow as a block
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>But won't work :-(
>>
>>
>>
>:)
>
>
>
>>Why ? Well, yes, a sitemap element = a builder class. But the
>>configuration file that defines them is used to feed a
>>ComponentSelector, which will try to load the class and the result is
>>that you will get an Exception in the initialization phase of the
>>TreeProcessor...
>>
>>The only viable solution is for the declaration to be _not present_ in
>>the treeprocessor configuration.
>>
>>
>>
>This is not the best solution, as it would required to change the
>treeprocessor conf for adding/removing flow.
>
>Could the treeprocessor check the availability of a class before feeding
>it into the selector? If the class is not available, a dummy implementation
>could be perhaps added that could - when used - throw a meaningfull
>exception.
>
>
Well, this would mean rewriting a ComponenentSelector specifically for
this purpose, since the TreeProcessor does nothing more than delegating
all this stuff to a CS : see DefaultTreeBuilder.createBuilderSelector().
Mmmh... A good solution may be to have a FakeFlowNodeBuilder that
delegates to a RealFlowNodeBuilder if it's present in the classpath, and
otherwise fails with a nice error message saying that the flow isn't
installed.
That way, we don't have to open wide the sitemap language definition,
which could lead to abuses : map:flow becomes an optional element that
is however pre-configured in the sitemap definition. Just drop in the
flow jar and it becomes available, without touching a single
configuration file.
Thoughts ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> But won't work :-(
>
:)
> Why ? Well, yes, a sitemap element = a builder class. But the
> configuration file that defines them is used to feed a
> ComponentSelector, which will try to load the class and the result is
> that you will get an Exception in the initialization phase of the
> TreeProcessor...
>
> The only viable solution is for the declaration to be _not present_ in
> the treeprocessor configuration.
>
This is not the best solution, as it would required to change the
treeprocessor conf for adding/removing flow.
Could the treeprocessor check the availability of a class before feeding
it into the selector? If the class is not available, a dummy implementation
could be perhaps added that could - when used - throw a meaningfull
exception.
Carsten
Re: [RT] Flow as a block
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Stefano Mazzocchi wrote:
>
>
>><SNIP/>
>>
>>
>>
>>>So, perhaps Sylvain has a clever idea on how to implement this in the
>>>treeprocessor.
>>>
>>>
>>I think that using xconftool is enough.
>>
>>
>>
>Yes, after thinking about it, for now we even don't need the xconftool
>but a clever exception handling/message.
>
>(Sylvain, correct me if I'm wrong)
>The configuration for the tree processor defines for an XML element a
>builder class. This builder is used when the sitemap contains this XML
>element. My idea is now, that this builder class is only invoked,
>when the XML element is used in the sitemap.
>
>So, if you have flow installed, the corresponding builder classes are
>available and you don't get any problem if you use flow or not.
>
>If flow is not installed and you don't use flow, the builder classes are
>not used -> no problem.
>If flow is not installed and you use flow, the builder classes are
>tried to be used but not available -> exception "class not found"
>-> clever message to the user.
>
>Sound easy...
>
But won't work :-(
Why ? Well, yes, a sitemap element = a builder class. But the
configuration file that defines them is used to feed a
ComponentSelector, which will try to load the class and the result is
that you will get an Exception in the initialization phase of the
TreeProcessor...
The only viable solution is for the declaration to be _not present_ in
the treeprocessor configuration.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> <SNIP/>
>
> > So, perhaps Sylvain has a clever idea on how to implement this in the
> > treeprocessor.
>
> I think that using xconftool is enough.
>
Yes, after thinking about it, for now we even don't need the xconftool
but a clever exception handling/message.
(Sylvain, correct me if I'm wrong)
The configuration for the tree processor defines for an XML element a
builder class. This builder is used when the sitemap contains this XML
element. My idea is now, that this builder class is only invoked,
when the XML element is used in the sitemap.
So, if you have flow installed, the corresponding builder classes are
available and you don't get any problem if you use flow or not.
If flow is not installed and you don't use flow, the builder classes are
not used -> no problem.
If flow is not installed and you use flow, the builder classes are
tried to be used but not available -> exception "class not found"
-> clever message to the user.
Sound easy...
Carsten
Re: [RT] Flow as a block
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>>>But: during the last two years, from time to time I had the need
>>>to extend the sitemap syntax, because that would have made some things
>>>much more easier. As it was not possible, we used some other methods
>>>like actions etc.
>>
>>Having a solid contracts doesn't mean we can't extend it if a real need
>>emerges.
>>
>>I'll be happy to discuss any needs for changes that appeared in
>>your needs.
>>
>
> Thanks. Currently, I simply don't have time to write my thoughts down,
> but when the time comes, I will post my RTs.
No prob. I have a few RTs on sitemap additions myself but I hold them
for post 2.1 final.
>>>Ok. How can we then make flow a block (or a module)?
>>
>>Create a way to have internal parts of cocoon to be removed at
>>compile time.
>>
>>The sitemap semantics remain the same: just like we don't remove
>>map:act, we don't remove map:flow but cocoon will run even if there is
>>no rhyno in the classpath and will give you an error message like
>>
>> 'flow is not supported in this build'
>>
>>or something like that. The same can be done for actions.
>>
>>so, if you want to ship your cocoon without stuff you do the equivalent of
>>
>> ./configure --disable-flow --disable-xsp
>>
>>What do you think?
>>
>
> Ah, ok - so, basically like using the fop serializer when fop is not
> available. Hmm, for making flow etc. optional, this is ok. So, yes, agreed.
Ok.
> This has of course the danger, that some clever users start moving out
> not only actions (like you want), but readers, selectors or matchers etc.
well, the get the source, they can remove anything they want. I'm just
talking about provoding a modules.properties file with the modules that
you can remove, just like we do for blocks now.
> But it's up to us, to decide what Cocoon as a project makes optional. ok.
Right.
> So, perhaps Sylvain has a clever idea on how to implement this in the
> treeprocessor.
I think that using xconftool is enough.
> Some kind of delegation perhaps?
I don't think we need to change the code, just the way it's assembled by
the build system.
But maybe I'm wrong and there are more clever solutions?
Stefano.
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> > But: during the last two years, from time to time I had the need
> > to extend the sitemap syntax, because that would have made some things
> > much more easier. As it was not possible, we used some other methods
> > like actions etc.
>
> Having a solid contracts doesn't mean we can't extend it if a real need
> emerges.
>
> I'll be happy to discuss any needs for changes that appeared in
> your needs.
>
Thanks. Currently, I simply don't have time to write my thoughts down,
but when the time comes, I will post my RTs.
> > Ok. How can we then make flow a block (or a module)?
>
> Create a way to have internal parts of cocoon to be removed at
> compile time.
>
> The sitemap semantics remain the same: just like we don't remove
> map:act, we don't remove map:flow but cocoon will run even if there is
> no rhyno in the classpath and will give you an error message like
>
> 'flow is not supported in this build'
>
> or something like that. The same can be done for actions.
>
> so, if you want to ship your cocoon without stuff you do the equivalent of
>
> ./configure --disable-flow --disable-xsp
>
> What do you think?
>
Ah, ok - so, basically like using the fop serializer when fop is not
available. Hmm, for making flow etc. optional, this is ok. So, yes, agreed.
This has of course the danger, that some clever users start moving out
not only actions (like you want), but readers, selectors or matchers etc.
But it's up to us, to decide what Cocoon as a project makes optional. ok.
So, perhaps Sylvain has a clever idea on how to implement this in the
treeprocessor. Some kind of delegation perhaps?
Carsten
Re: [RT] Flow as a block
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>> - people don't like/use actions and would like to see support for it
>>removed
>
> No, like Nicola said, these are usual sitemap components.
I don't use actions nor like them so they are not 'usual' for me as much
as flow is not 'usual' for you if you don't like nor use it.
> Ok, I see your
> point here, but I think simple actions are used very commonly.
I could well say this is because there was no other way of solving
issues, but now that there is, things might change a lot, we just don't
have information on this (yet).
>> - people dont' like/use the avalon instrumentation and would like to
>>see support for it removed
>
> Yes.
>
>
>><snip/>
>>it would turn the sitemap into Jelly: people will define ask us to
>>include a feature in the sitemap, we'll reject it, he'll host in on
>>sourceforge and since it's a clever hack with tons of problems down the
>>road but very appealing at first everybody starts using it.
>
> Yes, I'm fully aware of these dangers - and that's why I'm more
> interested in moving flow into a block (or module or whatever) than
> in making the sitemap pluggable.
Good.
> But: during the last two years, from time to time I had the need
> to extend the sitemap syntax, because that would have made some things
> much more easier. As it was not possible, we used some other methods
> like actions etc.
Having a solid contracts doesn't mean we can't extend it if a real need
emerges.
I'll be happy to discuss any needs for changes that appeared in your needs.
>>We should start thinking about modules and how to factor out things, but
>>the sitemap should *NOT* be modifiable by those modules. The sitemap
>>must remain carved in stone and only *US* cocoon development community
>>(as a whole, not me, not you) should define it and keep control of it.
>
> Agreed.
Good.
>>If you want to experiment, we give you scratchpad to incubate your
>>ideas, but I don't want to make it easy for people to add contracts
>>inside cocoon.
>>
>>At the end, my thoughts are:
>>
>> 1) I won't be against having a way to remove dependencies on internal
>>'modules' that are not used (I listed some of them above)
>>
>> 2) I will be against making it any easier to modify/extend the sitemap
>>semantics.
>>
>
> Ok. How can we then make flow a block (or a module)?
Create a way to have internal parts of cocoon to be removed at compile time.
The sitemap semantics remain the same: just like we don't remove
map:act, we don't remove map:flow but cocoon will run even if there is
no rhyno in the classpath and will give you an error message like
'flow is not supported in this build'
or something like that. The same can be done for actions.
so, if you want to ship your cocoon without stuff you do the equivalent of
./configure --disable-flow --disable-xsp
What do you think?
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> These RT propose two things:
>
> 1) move out flow as a block
> 2) make the sitemap syntax pluggable
>
Yes, but I see 1) as a need and would be happy about 2).
> - people use cocoon in a non-servlet environment and would like to see
> all servlet hooks removed
Yes.
>
> - people don't like/use XSP and would like to see dependencies on java
> compilers removed
Big Yes :)
>
> - people don't like/use the flow and would like to see support for it
> removed
Yupp.
>
> - people don't like/use actions and would like to see support for it
> removed
No, like Nicola said, these are usual sitemap components. Ok, I see your
point here, but I think simple actions are used very commonly.
>
> - people dont' like/use the avalon instrumentation and would like to
> see support for it removed
Yes.
> <snip/>
> it would turn the sitemap into Jelly: people will define ask us to
> include a feature in the sitemap, we'll reject it, he'll host in on
> sourceforge and since it's a clever hack with tons of problems down the
> road but very appealing at first everybody starts using it.
Yes, I'm fully aware of these dangers - and that's why I'm more
interested in moving flow into a block (or module or whatever) than
in making the sitemap pluggable.
But: during the last two years, from time to time I had the need
to extend the sitemap syntax, because that would have made some things
much more easier. As it was not possible, we used some other methods
like actions etc.
>
> We should start thinking about modules and how to factor out things, but
> the sitemap should *NOT* be modifiable by those modules. The sitemap
> must remain carved in stone and only *US* cocoon development community
> (as a whole, not me, not you) should define it and keep control of it.
Agreed.
>
> If you want to experiment, we give you scratchpad to incubate your
> ideas, but I don't want to make it easy for people to add contracts
> inside cocoon.
>
> At the end, my thoughts are:
>
> 1) I won't be against having a way to remove dependencies on internal
> 'modules' that are not used (I listed some of them above)
>
> 2) I will be against making it any easier to modify/extend the sitemap
> semantics.
>
Ok. How can we then make flow a block (or a module)?
Carsten
Re: [RT] Flow as a block
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> The flow stuff is an "optional" component, which means I can use it
> or not. Cocoon started as a web publishing framework and as flow is
> not directly a core component for web publishing but for web
> applications, I really would like to see flow as an own block
> that I can either install or not.
> Don't get me wrong, I like flow and I see the use of it, but flow
> is an optional component in the same sense that for example the
> portal framework is an optional component.
>
> Unfortunately, separating out the flow stuff into an own block is
> not that easy, I guess, as the main sitemap engine had to be extended
> for it.
>
> I'm thinking since last year about making the sitemap syntax pluggable,
> so the basic idea is to install an own block that adds more syntax and
> features to the sitemap. With that implemented, it would be easy
> to make flow an own block.
> I know that making the sitemap pluggable has some dangers, so this
> is only a thought.
>
> Anyway, regardless how it is solved, I would like to have the flow
> separated into a block.
>
> What do you think?
These RT propose two things:
1) move out flow as a block
2) make the sitemap syntax pluggable
I'm fully aware of the fact that the treeprocessor is already sort-of
pluggable, but you have to modify its configurations (which are stored
in the cocoon jar) and this is not as easy as tweaking a cocoon.xconf.
And, if you ask me, rightly so.
Now, you know how much I believe the flow will really give cocoon the
extra-power to finally take off and go into orbit for a general-purpose
xml technology.
But Carsten is right saying that the real benefit of Cocoon is having
XML pipelines, the rest are all fancy addons.
Actions included.
First of all, there is a major architectural difference between moving
the portal-framework into a block and moving flow into a block. Why?
because the first is 'on top' of cocoon, the second is 'in cocoon'.
Moving the flow into a block will make it hard to define what a block is
and would require us to add hooks to the blocks to allow them to
'extend' the internal cocoon syntax.
Nicola rightly points out that this reminds of the 'block/module'
discussion.
Now, I agree with Carsten that there are people that don't like some of
the cocoon functionalities and would like them removed. Examples of this
are:
- people use cocoon in a non-servlet environment and would like to see
all servlet hooks removed
- people don't like/use XSP and would like to see dependencies on java
compilers removed
- people don't like/use the flow and would like to see support for it
removed
- people don't like/use actions and would like to see support for it
removed
- people dont' like/use the avalon instrumentation and would like to
see support for it removed
Factoring out those things into blocks is, IMO, architecturally
problematic: a block is something that stays on *TOP* and uses cocoon
contracts exposed, it doesn't change them.
So, since these are RT, let us say that we have:
- blocks -> things that implement functionality on top
- modules -> things that add functionality inside
why this difference?
Because I expect the number of blocks to grow wildly in the next few
years, but I DO NOT want to see modules grow wildly or this will only
reflect on poor ability for us to define, document and validate them.
Carsten suggests the use of namespaces for block-added sitemap contracts.
This would prevent us from moving actions into an external module, for
example, for back compatibility issues.
But most important, it would open the gates for things like:
1) dynamic pipelines
2) sitemap taglibs
3) proprietary extensions
4) behavior modifications
it would turn the sitemap into Jelly: people will define ask us to
include a feature in the sitemap, we'll reject it, he'll host in on
sourceforge and since it's a clever hack with tons of problems down the
road but very appealing at first everybody starts using it.
Then people will post questions on why their sitemap snippet
<map:match pattern="*">
<yourmap:if test="exists({input:session}.authorized)>
<mymap:bad-word-filter dictionary="..."/>
<map:generator type="request"/>
</mymap:bad-word-filter>
...
<yourmap:else>
<yourmap:if test="{my-input:locale}=='IT'">
...
</yourmap:if>
</yourmap:else>
<yourmap:if>
</map:match>
don't work as they expect.
Ah, that's only one of the few abuses I can think of but I'm sure our
users will be very clever in finding creative ways of routing around
years of carefully designed separated concerns.
- o -
So, how do we do it?
We should start thinking about modules and how to factor out things, but
the sitemap should *NOT* be modifiable by those modules. The sitemap
must remain carved in stone and only *US* cocoon development community
(as a whole, not me, not you) should define it and keep control of it.
If you want to experiment, we give you scratchpad to incubate your
ideas, but I don't want to make it easy for people to add contracts
inside cocoon.
At the end, my thoughts are:
1) I won't be against having a way to remove dependencies on internal
'modules' that are not used (I listed some of them above)
2) I will be against making it any easier to modify/extend the sitemap
semantics.
Comments?
RE: [RT] Flow as a block
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Pier Fumagalli wrote:
>
> For what matters to me, I really can't state an opinion on
> whether the flow
> scripting layer should be or shouldn't be implemented as a block.
> It's true
> that I don't use it in all situations, so, in a very minimal or targeted
> installation, I can agree that we might want not to include al the classes
> required to make it work.
>
> But, quite frankly, I am not that happy about having a "pluggable" sitemap
> syntax.
>
> The sitemap as I see it, is IMVHO, the very heart of Cocoon, its syntax is
> that thing we want to carve in stone.
>
Yes, these are the problems or dangers.
> Any sitemap should be validable despite the current Cocoon setup. For
> example, right now, if we have (or not) the FOP block, I'll be able to
> validate a sitemap, although that specific block I rely upon might be or
> might not be available at deployment time.
>
> As I said, I have no problem if you want to move in a block all the
> org.apacje.cococoon.components.flow (well, we should probably keep the
> Interpreter, AbstractInterpreter and InterpreterSelector in core, but all
> the rest can go), but the sitemap syntax and cocoon
> mode-of-operation should
> be carved in stone big time...
>
Hmmm, I don't agree completly. The core sitemap syntax has to be carved in
stone. True.
*if* we would use a different namespace for the plugins, like the flow,
than the sitemap can still be validated without any problems. The
application will of course not run, if your sitemap uses the flow, when
the flow is not available. But the same happens, if the fop serializer
is used and is not available.
I agree with you, if we give the plugins the same namespace as the sitemap
has.
Carsten
Re: [RT] Flow as a block
Posted by Pier Fumagalli <pi...@betaversion.org>.
"Carsten Ziegeler" <cz...@s-und-n.de> wrote:
> The flow stuff is an "optional" component, which means I can use it
> or not. Cocoon started as a web publishing framework and as flow is
> not directly a core component for web publishing but for web
> applications, I really would like to see flow as an own block
> that I can either install or not.
> Don't get me wrong, I like flow and I see the use of it, but flow
> is an optional component in the same sense that for example the
> portal framework is an optional component.
>
> Unfortunately, separating out the flow stuff into an own block is
> not that easy, I guess, as the main sitemap engine had to be extended
> for it.
>
> I'm thinking since last year about making the sitemap syntax pluggable,
> so the basic idea is to install an own block that adds more syntax and
> features to the sitemap. With that implemented, it would be easy
> to make flow an own block.
> I know that making the sitemap pluggable has some dangers, so this
> is only a thought.
>
> Anyway, regardless how it is solved, I would like to have the flow
> separated into a block.
>
> What do you think?
For what matters to me, I really can't state an opinion on whether the flow
scripting layer should be or shouldn't be implemented as a block. It's true
that I don't use it in all situations, so, in a very minimal or targeted
installation, I can agree that we might want not to include al the classes
required to make it work.
But, quite frankly, I am not that happy about having a "pluggable" sitemap
syntax.
The sitemap as I see it, is IMVHO, the very heart of Cocoon, its syntax is
that thing we want to carve in stone.
Any sitemap should be validable despite the current Cocoon setup. For
example, right now, if we have (or not) the FOP block, I'll be able to
validate a sitemap, although that specific block I rely upon might be or
might not be available at deployment time.
As I said, I have no problem if you want to move in a block all the
org.apacje.cococoon.components.flow (well, we should probably keep the
Interpreter, AbstractInterpreter and InterpreterSelector in core, but all
the rest can go), but the sitemap syntax and cocoon mode-of-operation should
be carved in stone big time...
My 0.02 £
Pier