Jo! & WAR file apps

[Paul Hammant <Pa...@yahoo.com>]

Hendrik,

Does Jo! run Cocoon as a WAR app?

It could be quite a cool way of getting Cocoon inside the Phoenix VM. 
 Actually, it might require some mods as it uses Excalibur, Framework & 
Logkit (sister projects to Phoenix) that are already in the classloader 
tree for Phoenix hosted apps.

Some of us were thinking that we could write some blocks for Cocoon to 
provide a generic Cocoon rendering component, but Jo! hosting the 
existing thing might be a useful way of having that functionality before 
a full block-ization.

Regards,

- Paul H


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Stefano Mazzocchi <st...@apache.org>]

Peter Donald wrote:
 
> I am not sure I fully understand them in this case. So heres my opinion and
> you can tell me how it fits into your model ;) I think the transaformation
> pipeline (and possibly serializers) should be completely internal to the
> proposed cocoon block.

I fully agree with that.
 
> However it should be be fair game for the block to have parameters passed in.

Well, of course, you have to pass some data in, in fact, a request is
"some data in", I would say. But do you really want to fake a request to
have access to this Cocoon block?

> One of these parameters would of course designate the transformation
> pipeline. 

This "parameter" is normally called URI. :) And this is what it should
remain. In fact, a URI is "uniform resource identifier", right? so it
"identifies" a resource (a pipeline, in this case).

> But the question is could one of the parameters passed in be the
> source to be transformed/processed? I'm not sure. 

Well, look: I see it very simple: if you pass the document that should
be processed, you are the generator, then your concern is to generate
something and the block concern would be to transform it.

But Cocoon is designed to be in control of the URI space, otherwise
there is no way you can separate concerns: you ask for something (a
service, a page, in general: a resource) and then Cocoon gives it to
you.

This doesn't mean you can't pass things to Cocoon (as it doesn't mean
you can't do HTTP POST actions to Cocoon, even POST with XML payload
such as SOAP requests), but that this must be information used by Cocoon
not used by "YOU" to drive Cocoon behavior.

Hopefully, the difference is clear. If not, please tell me.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Peter Donald <do...@apache.org>]

On Sat, 3 Nov 2001 22:31, Stefano Mazzocchi wrote:
> I simply do not and for the reason above: IoC means that you ask for a
> resource to Cocoon and it knows what to do.

in this context I agree 

>
> This is a design pattern that must not be altered in any way, under any
> circumstance or Cocoon will be nothing different from
> Xerces+Xalan+FOP+Batik.
>
> I hope you guys understand my strong feelings about IoC.

I am not sure I fully understand them in this case. So heres my opinion and 
you can tell me how it fits into your model ;) I think the transaformation 
pipeline (and possibly serializers) should be completely internal to the 
proposed cocoon block.

However it should be be fair game for the block to have parameters passed in. 
One of these parameters would of course designate the transformation 
pipeline. But the question is could one of the parameters passed in be the 
source to be transformed/processed? Im not sure. In a web application it 
would of course be out of the question but in other cases ... not so sure.


-- 
Cheers,

Pete

*---------------------------------------------------------*
| Programming today is a race between software engineers  |
| striving to build bigger and better idiot-proof         |
| programs,and the universe trying to produce bigger and  |
| better idiots. So far, the universe is winning.         |
|                       - Richard Cook                    |
*---------------------------------------------------------*

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Peter Donald <do...@apache.org>]

On Sat, 3 Nov 2001 22:31, Stefano Mazzocchi wrote:
> I simply do not and for the reason above: IoC means that you ask for a
> resource to Cocoon and it knows what to do.

in this context I agree 

>
> This is a design pattern that must not be altered in any way, under any
> circumstance or Cocoon will be nothing different from
> Xerces+Xalan+FOP+Batik.
>
> I hope you guys understand my strong feelings about IoC.

I am not sure I fully understand them in this case. So heres my opinion and 
you can tell me how it fits into your model ;) I think the transaformation 
pipeline (and possibly serializers) should be completely internal to the 
proposed cocoon block.

However it should be be fair game for the block to have parameters passed in. 
One of these parameters would of course designate the transformation 
pipeline. But the question is could one of the parameters passed in be the 
source to be transformed/processed? Im not sure. In a web application it 
would of course be out of the question but in other cases ... not so sure.


-- 
Cheers,

Pete

*---------------------------------------------------------*
| Programming today is a race between software engineers  |
| striving to build bigger and better idiot-proof         |
| programs,and the universe trying to produce bigger and  |
| better idiots. So far, the universe is winning.         |
|                       - Richard Cook                    |
*---------------------------------------------------------*

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Stefano Mazzocchi <st...@apache.org>]

This thread clearly lost focus.

Uli, please feel free to use Cocoon the way you like the most and if you
come up with Cocoon patches, fell free to send them to us and I
guarantee you that we'll make our best effort to evaluate them.

Take care.

[FYI: I won't bother replying further on this thread]

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Ulrich Mayring <ul...@denic.de>]

Sylvain Wallez wrote:
> 
> > In my mind it does not make sense for the daemon program to open a
> > java.net.URLConnection to Cocoon. The PDF generator and the daemon are
> > both backend components and could both run very sensibly under Phoenix
> > and talk to each other using the well-defined Avalon contracts, instead
> > of stateless HTTP. I hope that example convinces you that the world is
> > not a one-way street, if not perhaps you have a better suggestion for
> > this concrete example. But please don't tell me to move the daemon's
> > functionality into the frontend :)
> 
> The daemon program doesn't have to open a java.net.URLConnection. The
> Cocoon environment is abstracted and two implementations come with the
> distribution : servlet and command line. Just define your own as an
> Avalon service and you're done with what you need.

Well, this is exactly what I was looking for. I haven't found any docs
describing this procedure, that is why I asked on this list.

> It's true that Cocoon Environment was designed with request/response
> paradigm in mind and that it heavily mimics the servlet interface. But
> is a request/response really different from a method call on an
> interface ?

No, if the method is sufficiently abstract. If I have a method I can
pass a couple of Strings into and get a String back, then I can build
whatever I need. But I think this type of access should be standardized
and de-coupled in some way, so I like the first option better, where I
have to implement an interface (if I understood you correctly).

> And if that's not enough for you, Cocoon just an implementation of a
> "Processor" (see org.apache.cocoon.Processor) that builds a Pipeline
> according to a given Environment (http, commandline, whatever). That
> could be the service you're looking for.

Ok, so here's a third option. My question was if there is a standard way
to do it and the response was that I destroy IoC with that idea :)

> About this particular "too proprietary" statement you say often, let me
> say also that I really don't understand it. What do you mean by
> "proprietary" ?

It means that it is not a standard like, say, XML or XSLT or HTTP.

> Contribute ideas and/or code instead of criticisms and you will be
> heard.

What is the difference between an idea and a criticism? An idea means
"let's do it this way" and it implies the criticism "the way we do it
now is not good enough". Anyway, you're taking things to a personal
level, which I don't think is appropriate. It should not be about me or
you and what each of us has done for the project, we should discuss
things on a rational and technical level.

> If this means "not a standard", then this also true : this is not a
> standard from W3C, JDK, whatever. But does it need at all to be a
> standard ? Is Avalon you seem to love so much (I do also) a standard ?
> Not either. Most standards in the software industry emerge today from
> research projects or developper communities. Cocoon is both. Take SAX
> and javax.xml.transform : there are now a standards, but started as the
> work of developper communities.

Well, these are several points, I'll try to address them seperately, but
briefly. If you like to go into more detail, then ask me back:

Does the Sitemap need to be a standard? I think yes. It is THE interface
to userland and it is doing a lot of things. Everyone must decide for
himself, if he can afford to bet his company on this concept. It is very
hard to port a Sitemap-based application to another platform - but if
the boss tells me so I have to do it.

Is Avalon a standard? Nope, but it's much easier to port an application
from Avalon to another platform. Remove some wrappers and you're almost
done. Plus, Avalon is friendly to all kinds of integration.

Standards emerge from developer communities. This is true and I don't
think I have disputed that claim. Allow me some wild speculation on
this: do you believe the W3C would accept the Sitemap as a standard, if
it were written up correctly? I think they would want something more
generic.

> > Again: I don't want to call Cocoon from my programs. That is in fact
> > exactly what I want to avoid. All I want is to ask Cocoon to be nice and
> > not claim exclusive ownership of things like "XML==>XSLFO==>PDF". Cocoon
> > can (and does) claim exclusive ownership of the Sitemap, but it can't
> > (and doesn't) claim exclusive ownership of the URI space. In general:
> > control your invention, but not the inventions of others.
> 
> Cocoon doesn't have any ownership of these : there is no XSL processor
> in Cocoon, but it integrates cleanly with Xalan, Saxon, or XT any other
> XML (not just XSL) transformer. It doesn't have a FO renderer but uses
> smoothly FOP, RenderX or JFor.

Didn't I just know this argument would come? :)

Cocoon uses smoothly FOP, Xalan, RenderX and many more, because these
tools have a well-defined interface for using them. Unfortunately many
of those tools have different interfaces (not considering JAXP and
friends for the moment). Instead of n software developers writing n
wrappers for these interfaces I suggested that the Cocoon project might
be a great place to provide standardized interfaces to the world.

Of course Cocoon doesn't claim ownership of these technologies in the
sense that I cannot use them without Cocoon. But Cocoon does claim
ownership of its interfaces to these technologies and I am kindly asking
to share these interfaces with others.

> What Cocoon does is provide means to assemble all these in pipelines to
> produce resources described by an environment. That's all, but that's
> done in a way that allows each concern not to overlap with others. If
> you want to have a static and hard-coded XML->XSL->FOP pipeline, just
> write down a few dozen lines of glue code and you're done. You don't
> need Cocoon for that.

I need Cocoon for the frontend anyway. Is it really such a strange idea
that I want to re-use what is already there in another context?

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

AW: Jo! & WAR file apps

[Matthew Langham <ml...@s-und-n.de>]

Just jumping in with some "real-world" trivia:

>>
The daemon program doesn't have to open a java.net.URLConnection. The
Cocoon environment is abstracted and two implementations come with the
distribution : servlet and command line. Just define your own as an
Avalon service and you're done with what you need.
<<

We do this inside what we have built. We have functionality defined inside
Cocoon, using pipelines etc. that can be accessed via a browser interface.
When we needed the same functionality in a sort of batch-mode (without HTTP)
we opted to use the CLI. So we have scripts that then call the _same_
functionality via the CLI - reusing what we already had. Works fine for what
we needed.


Matthew


--
Open Source Group               sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30  mlangham@s-und-n.de - http://www.s-und-n.de
=================================================================


-----Ursprüngliche Nachricht-----
Von: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
Gesendet: Dienstag, 6. November 2001 17:42
An: cocoon-dev@xml.apache.org
Betreff: Re: Jo! & WAR file apps




Ulrich Mayring a écrit :
>
> Stefano Mazzocchi wrote:
> >
> > Note: we already agreed on moving all the required components to avalon
> > so that other blocks can use them.
>
> In my mind the stuff could (and perhaps should) remain in the Cocoon
> project, where it's most heavily used, developed and tested. If there is
> a particular advantage in moving it to Avalon, fine. But just because
> you package something as a bunch of blocks (for example) doesn't mean it
> has to go to Avalon. I wasn't talking about actually merging code with
> Avalon.
>
> > Ok, show us what you mean with code, then.
>
> I wrote a couple of taglibs for Cocoon1 and several people downloaded
> and used them. It was possible to do that, because there was a
> well-defined interface for third-party XSP taglibs. If we can't agree on
> a common interface here, then it probably doesn't make much sense if I
> release my code :)
>
> > Well, come back when you have some real problem to solve and not a bunch
> > a technologies to glue together "just because it might be cool to".
>
> Sometimes I like to think ahead, is that against the rules on this list?
>
> > ??? let's make a poll here: did you people ever had to throw something
> > away because of Cocoon?
>
> Usually the decision goes the other way: not to use Cocoon and keep what
> one has.
>
> > 2001: Uli finally gets it. Writes a Generators, asks for an avalon
> > component and use it.
> >
> > The end. :)
> >
> > The problem here, buddy, is that you don't get what inversion of control
> > really is and you still want to call Cocoon (as an avalon block, this
> > time) and not allow it to call you (or your avalon components).
>
> I do understand what IoC is, but I also understand what the real world
> is - and it is not a one-way street. And even if it were a one-way
> street, it is still arbitrary to say the direction is Cocoon ==> World
> and not vice versa. I am not saying this direction is useless, but I am
> defending the direction World ==> Cocoon, which you are cutting short.
>
> Ok, perhaps the point of my little story wasn't clear, so I'll expand on
> that. I'll give a very simple example and ask you to scale it up in your
> mind:
>
> Suppose we have the requirement to design a system that can generate
> dynamic PDFs. Dynamic here means they contain some data from a database.
> There is a backend component (an Avalon .sar application) that scans the
> database and whenever it finds some new data, it generates a new PDF.
> Then there is a frontend component (Cocoon) that presents a
> browser-based GUI to people and whenever they click on some data, a new
> PDF is generated. So we want a central component that does
> XML==>XSLFO==>PDF - for the interactive requests and for the daemon
> program.
>
> In my mind it does not make sense for the daemon program to open a
> java.net.URLConnection to Cocoon. The PDF generator and the daemon are
> both backend components and could both run very sensibly under Phoenix
> and talk to each other using the well-defined Avalon contracts, instead
> of stateless HTTP. I hope that example convinces you that the world is
> not a one-way street, if not perhaps you have a better suggestion for
> this concrete example. But please don't tell me to move the daemon's
> functionality into the frontend :)

The daemon program doesn't have to open a java.net.URLConnection. The
Cocoon environment is abstracted and two implementations come with the
distribution : servlet and command line. Just define your own as an
Avalon service and you're done with what you need.

It's true that Cocoon Environment was designed with request/response
paradigm in mind and that it heavily mimics the servlet interface. But
is a request/response really different from a method call on an
interface ? The cocoon service could have the following simple method :

  public void produce(String resource, Parameters params, OutputStream
out)

"resource" is the name of the resource to produce, "params" are
additional values that tailor the way the resource is produced, and
"out" is where you want to get the result. No servlets here, no
URLConnection, but a different way to represent what the HttpEnvironment
in Cocoon represents using a request URI, request parameters and a
socket connection to the client browser.

And if that's not enough for you, Cocoon just an implementation of a
"Processor" (see org.apache.cocoon.Processor) that builds a Pipeline
according to a given Environment (http, commandline, whatever). That
could be the service you're looking for.

Also, if you find the sitemap "too proprietary", you can write your own
pipeline assembly language : the sitemap has recently been decorrelated
from the Cocoon class so that you can use your own implementation of
Processor : I'm currently writing a new interpreted implementation of
the sitemap that could be the foundation of future other pipeline
assembly languages.

About this particular "too proprietary" statement you say often, let me
say also that I really don't understand it. What do you mean by
"proprietary" ?

If this means "under control of someone", then yes, it's under control :
under control of the Cocoon community. But that community is open and
anyone is welcomed to contribute ideas, enhancements, etc. That's how I
became a Cocoon committer, and I'm proud to be part of that community.
Contribute ideas and/or code instead of criticisms and you will be
heard.

If this means "not a standard", then this also true : this is not a
standard from W3C, JDK, whatever. But does it need at all to be a
standard ? Is Avalon you seem to love so much (I do also) a standard ?
Not either. Most standards in the software industry emerge today from
research projects or developper communities. Cocoon is both. Take SAX
and javax.xml.transform : there are now a standards, but started as the
work of developper communities.

> Now, if the project "moving stuff to Avalon" is to enable exactly this
> kind of scenario, then we have no disagreement. You can call it IoC, I
> can call it componentware and we can all be happy :)

Moving stuff to Avalon means that some of the Cocoon components have a
broader use that Cocoon. IIRC, Avalon component stuff started just like
that : a nice framework that was built for Cocoon2, but proved to be of
very general interest. Later on, the Excalibur component manager
followed the exact same path. The components that we plan to move to
Avalon will allow to use components for XML parsing, XPath queries, XSL
transformation, etc, without having to import an org.apache.cocoon.*
class and thus give them a wider audience. That's all.

> Again: I don't want to call Cocoon from my programs. That is in fact
> exactly what I want to avoid. All I want is to ask Cocoon to be nice and
> not claim exclusive ownership of things like "XML==>XSLFO==>PDF". Cocoon
> can (and does) claim exclusive ownership of the Sitemap, but it can't
> (and doesn't) claim exclusive ownership of the URI space. In general:
> control your invention, but not the inventions of others.

Cocoon doesn't have any ownership of these : there is no XSL processor
in Cocoon, but it integrates cleanly with Xalan, Saxon, or XT any other
XML (not just XSL) transformer. It doesn't have a FO renderer but uses
smoothly FOP, RenderX or JFor.

What Cocoon does is provide means to assemble all these in pipelines to
produce resources described by an environment. That's all, but that's
done in a way that allows each concern not to overlap with others. If
you want to have a static and hard-coded XML->XSL->FOP pipeline, just
write down a few dozen lines of glue code and you're done. You don't
need Cocoon for that.

> Take care,
>
> Ulrich

Thanks :)

Sylvain.

--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[giacomo <gi...@apache.org>]

On Tue, 6 Nov 2001, Sylvain Wallez wrote:

>
>
> Ulrich Mayring a écrit :
> >
> > Stefano Mazzocchi wrote:
> > >
> > > Note: we already agreed on moving all the required components to avalon
> > > so that other blocks can use them.
> >
> > In my mind the stuff could (and perhaps should) remain in the Cocoon
> > project, where it's most heavily used, developed and tested. If there is
> > a particular advantage in moving it to Avalon, fine. But just because
> > you package something as a bunch of blocks (for example) doesn't mean it
> > has to go to Avalon. I wasn't talking about actually merging code with
> > Avalon.
> >
> > > Ok, show us what you mean with code, then.
> >
> > I wrote a couple of taglibs for Cocoon1 and several people downloaded
> > and used them. It was possible to do that, because there was a
> > well-defined interface for third-party XSP taglibs. If we can't agree on
> > a common interface here, then it probably doesn't make much sense if I
> > release my code :)
> >
> > > Well, come back when you have some real problem to solve and not a bunch
> > > a technologies to glue together "just because it might be cool to".
> >
> > Sometimes I like to think ahead, is that against the rules on this list?
> >
> > > ??? let's make a poll here: did you people ever had to throw something
> > > away because of Cocoon?
> >
> > Usually the decision goes the other way: not to use Cocoon and keep what
> > one has.
> >
> > > 2001: Uli finally gets it. Writes a Generators, asks for an avalon
> > > component and use it.
> > >
> > > The end. :)
> > >
> > > The problem here, buddy, is that you don't get what inversion of control
> > > really is and you still want to call Cocoon (as an avalon block, this
> > > time) and not allow it to call you (or your avalon components).
> >
> > I do understand what IoC is, but I also understand what the real world
> > is - and it is not a one-way street. And even if it were a one-way
> > street, it is still arbitrary to say the direction is Cocoon ==> World
> > and not vice versa. I am not saying this direction is useless, but I am
> > defending the direction World ==> Cocoon, which you are cutting short.
> >
> > Ok, perhaps the point of my little story wasn't clear, so I'll expand on
> > that. I'll give a very simple example and ask you to scale it up in your
> > mind:
> >
> > Suppose we have the requirement to design a system that can generate
> > dynamic PDFs. Dynamic here means they contain some data from a database.
> > There is a backend component (an Avalon .sar application) that scans the
> > database and whenever it finds some new data, it generates a new PDF.
> > Then there is a frontend component (Cocoon) that presents a
> > browser-based GUI to people and whenever they click on some data, a new
> > PDF is generated. So we want a central component that does
> > XML==>XSLFO==>PDF - for the interactive requests and for the daemon
> > program.
> >
> > In my mind it does not make sense for the daemon program to open a
> > java.net.URLConnection to Cocoon. The PDF generator and the daemon are
> > both backend components and could both run very sensibly under Phoenix
> > and talk to each other using the well-defined Avalon contracts, instead
> > of stateless HTTP. I hope that example convinces you that the world is
> > not a one-way street, if not perhaps you have a better suggestion for
> > this concrete example. But please don't tell me to move the daemon's
> > functionality into the frontend :)
>
> The daemon program doesn't have to open a java.net.URLConnection. The
> Cocoon environment is abstracted and two implementations come with the
> distribution : servlet and command line. Just define your own as an
> Avalon service and you're done with what you need.
>
> It's true that Cocoon Environment was designed with request/response
> paradigm in mind and that it heavily mimics the servlet interface. But
> is a request/response really different from a method call on an
> interface ? The cocoon service could have the following simple method :
>
>   public void produce(String resource, Parameters params, OutputStream
> out)

This is exacly what we are saying many times since week (or month).
If you need a "Cocoon service" as an Avalon Block, write it, it's simply
another Environment Cocoon can run in.

Giacomo

>
> "resource" is the name of the resource to produce, "params" are
> additional values that tailor the way the resource is produced, and
> "out" is where you want to get the result. No servlets here, no
> URLConnection, but a different way to represent what the HttpEnvironment
> in Cocoon represents using a request URI, request parameters and a
> socket connection to the client browser.
>
> And if that's not enough for you, Cocoon just an implementation of a
> "Processor" (see org.apache.cocoon.Processor) that builds a Pipeline
> according to a given Environment (http, commandline, whatever). That
> could be the service you're looking for.
>
> Also, if you find the sitemap "too proprietary", you can write your own
> pipeline assembly language : the sitemap has recently been decorrelated
> from the Cocoon class so that you can use your own implementation of
> Processor : I'm currently writing a new interpreted implementation of
> the sitemap that could be the foundation of future other pipeline
> assembly languages.
>
> About this particular "too proprietary" statement you say often, let me
> say also that I really don't understand it. What do you mean by
> "proprietary" ?
>
> If this means "under control of someone", then yes, it's under control :
> under control of the Cocoon community. But that community is open and
> anyone is welcomed to contribute ideas, enhancements, etc. That's how I
> became a Cocoon committer, and I'm proud to be part of that community.
> Contribute ideas and/or code instead of criticisms and you will be
> heard.
>
> If this means "not a standard", then this also true : this is not a
> standard from W3C, JDK, whatever. But does it need at all to be a
> standard ? Is Avalon you seem to love so much (I do also) a standard ?
> Not either. Most standards in the software industry emerge today from
> research projects or developper communities. Cocoon is both. Take SAX
> and javax.xml.transform : there are now a standards, but started as the
> work of developper communities.
>
> > Now, if the project "moving stuff to Avalon" is to enable exactly this
> > kind of scenario, then we have no disagreement. You can call it IoC, I
> > can call it componentware and we can all be happy :)
>
> Moving stuff to Avalon means that some of the Cocoon components have a
> broader use that Cocoon. IIRC, Avalon component stuff started just like
> that : a nice framework that was built for Cocoon2, but proved to be of
> very general interest. Later on, the Excalibur component manager
> followed the exact same path. The components that we plan to move to
> Avalon will allow to use components for XML parsing, XPath queries, XSL
> transformation, etc, without having to import an org.apache.cocoon.*
> class and thus give them a wider audience. That's all.
>
> > Again: I don't want to call Cocoon from my programs. That is in fact
> > exactly what I want to avoid. All I want is to ask Cocoon to be nice and
> > not claim exclusive ownership of things like "XML==>XSLFO==>PDF". Cocoon
> > can (and does) claim exclusive ownership of the Sitemap, but it can't
> > (and doesn't) claim exclusive ownership of the URI space. In general:
> > control your invention, but not the inventions of others.
>
> Cocoon doesn't have any ownership of these : there is no XSL processor
> in Cocoon, but it integrates cleanly with Xalan, Saxon, or XT any other
> XML (not just XSL) transformer. It doesn't have a FO renderer but uses
> smoothly FOP, RenderX or JFor.
>
> What Cocoon does is provide means to assemble all these in pipelines to
> produce resources described by an environment. That's all, but that's
> done in a way that allows each concern not to overlap with others. If
> you want to have a static and hard-coded XML->XSL->FOP pipeline, just
> write down a few dozen lines of glue code and you're done. You don't
> need Cocoon for that.
>
> > Take care,
> >
> > Ulrich
>
> Thanks :)
>
> Sylvain.
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Sylvain Wallez <sy...@anyware-tech.com>]

Ulrich Mayring a écrit :
> 
> Stefano Mazzocchi wrote:
> >
> > Note: we already agreed on moving all the required components to avalon
> > so that other blocks can use them.
> 
> In my mind the stuff could (and perhaps should) remain in the Cocoon
> project, where it's most heavily used, developed and tested. If there is
> a particular advantage in moving it to Avalon, fine. But just because
> you package something as a bunch of blocks (for example) doesn't mean it
> has to go to Avalon. I wasn't talking about actually merging code with
> Avalon.
> 
> > Ok, show us what you mean with code, then.
> 
> I wrote a couple of taglibs for Cocoon1 and several people downloaded
> and used them. It was possible to do that, because there was a
> well-defined interface for third-party XSP taglibs. If we can't agree on
> a common interface here, then it probably doesn't make much sense if I
> release my code :)
> 
> > Well, come back when you have some real problem to solve and not a bunch
> > a technologies to glue together "just because it might be cool to".
> 
> Sometimes I like to think ahead, is that against the rules on this list?
> 
> > ??? let's make a poll here: did you people ever had to throw something
> > away because of Cocoon?
> 
> Usually the decision goes the other way: not to use Cocoon and keep what
> one has.
> 
> > 2001: Uli finally gets it. Writes a Generators, asks for an avalon
> > component and use it.
> >
> > The end. :)
> >
> > The problem here, buddy, is that you don't get what inversion of control
> > really is and you still want to call Cocoon (as an avalon block, this
> > time) and not allow it to call you (or your avalon components).
> 
> I do understand what IoC is, but I also understand what the real world
> is - and it is not a one-way street. And even if it were a one-way
> street, it is still arbitrary to say the direction is Cocoon ==> World
> and not vice versa. I am not saying this direction is useless, but I am
> defending the direction World ==> Cocoon, which you are cutting short.
> 
> Ok, perhaps the point of my little story wasn't clear, so I'll expand on
> that. I'll give a very simple example and ask you to scale it up in your
> mind:
> 
> Suppose we have the requirement to design a system that can generate
> dynamic PDFs. Dynamic here means they contain some data from a database.
> There is a backend component (an Avalon .sar application) that scans the
> database and whenever it finds some new data, it generates a new PDF.
> Then there is a frontend component (Cocoon) that presents a
> browser-based GUI to people and whenever they click on some data, a new
> PDF is generated. So we want a central component that does
> XML==>XSLFO==>PDF - for the interactive requests and for the daemon
> program.
> 
> In my mind it does not make sense for the daemon program to open a
> java.net.URLConnection to Cocoon. The PDF generator and the daemon are
> both backend components and could both run very sensibly under Phoenix
> and talk to each other using the well-defined Avalon contracts, instead
> of stateless HTTP. I hope that example convinces you that the world is
> not a one-way street, if not perhaps you have a better suggestion for
> this concrete example. But please don't tell me to move the daemon's
> functionality into the frontend :)

The daemon program doesn't have to open a java.net.URLConnection. The
Cocoon environment is abstracted and two implementations come with the
distribution : servlet and command line. Just define your own as an
Avalon service and you're done with what you need.

It's true that Cocoon Environment was designed with request/response
paradigm in mind and that it heavily mimics the servlet interface. But
is a request/response really different from a method call on an
interface ? The cocoon service could have the following simple method :

  public void produce(String resource, Parameters params, OutputStream
out)

"resource" is the name of the resource to produce, "params" are
additional values that tailor the way the resource is produced, and
"out" is where you want to get the result. No servlets here, no
URLConnection, but a different way to represent what the HttpEnvironment
in Cocoon represents using a request URI, request parameters and a
socket connection to the client browser.

And if that's not enough for you, Cocoon just an implementation of a
"Processor" (see org.apache.cocoon.Processor) that builds a Pipeline
according to a given Environment (http, commandline, whatever). That
could be the service you're looking for.

Also, if you find the sitemap "too proprietary", you can write your own
pipeline assembly language : the sitemap has recently been decorrelated
from the Cocoon class so that you can use your own implementation of
Processor : I'm currently writing a new interpreted implementation of
the sitemap that could be the foundation of future other pipeline
assembly languages.

About this particular "too proprietary" statement you say often, let me
say also that I really don't understand it. What do you mean by
"proprietary" ?

If this means "under control of someone", then yes, it's under control :
under control of the Cocoon community. But that community is open and
anyone is welcomed to contribute ideas, enhancements, etc. That's how I
became a Cocoon committer, and I'm proud to be part of that community.
Contribute ideas and/or code instead of criticisms and you will be
heard.

If this means "not a standard", then this also true : this is not a
standard from W3C, JDK, whatever. But does it need at all to be a
standard ? Is Avalon you seem to love so much (I do also) a standard ?
Not either. Most standards in the software industry emerge today from
research projects or developper communities. Cocoon is both. Take SAX
and javax.xml.transform : there are now a standards, but started as the
work of developper communities.

> Now, if the project "moving stuff to Avalon" is to enable exactly this
> kind of scenario, then we have no disagreement. You can call it IoC, I
> can call it componentware and we can all be happy :)

Moving stuff to Avalon means that some of the Cocoon components have a
broader use that Cocoon. IIRC, Avalon component stuff started just like
that : a nice framework that was built for Cocoon2, but proved to be of
very general interest. Later on, the Excalibur component manager
followed the exact same path. The components that we plan to move to
Avalon will allow to use components for XML parsing, XPath queries, XSL
transformation, etc, without having to import an org.apache.cocoon.*
class and thus give them a wider audience. That's all.

> Again: I don't want to call Cocoon from my programs. That is in fact
> exactly what I want to avoid. All I want is to ask Cocoon to be nice and
> not claim exclusive ownership of things like "XML==>XSLFO==>PDF". Cocoon
> can (and does) claim exclusive ownership of the Sitemap, but it can't
> (and doesn't) claim exclusive ownership of the URI space. In general:
> control your invention, but not the inventions of others.

Cocoon doesn't have any ownership of these : there is no XSL processor
in Cocoon, but it integrates cleanly with Xalan, Saxon, or XT any other
XML (not just XSL) transformer. It doesn't have a FO renderer but uses
smoothly FOP, RenderX or JFor.

What Cocoon does is provide means to assemble all these in pipelines to
produce resources described by an environment. That's all, but that's
done in a way that allows each concern not to overlap with others. If
you want to have a static and hard-coded XML->XSL->FOP pipeline, just
write down a few dozen lines of glue code and you're done. You don't
need Cocoon for that.

> Take care,
>
> Ulrich

Thanks :)

Sylvain.

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Ulrich Mayring <ul...@denic.de>]

Stefano Mazzocchi wrote:
> 
> Note: we already agreed on moving all the required components to avalon
> so that other blocks can use them.

In my mind the stuff could (and perhaps should) remain in the Cocoon
project, where it's most heavily used, developed and tested. If there is
a particular advantage in moving it to Avalon, fine. But just because
you package something as a bunch of blocks (for example) doesn't mean it
has to go to Avalon. I wasn't talking about actually merging code with
Avalon.

> Ok, show us what you mean with code, then.

I wrote a couple of taglibs for Cocoon1 and several people downloaded
and used them. It was possible to do that, because there was a
well-defined interface for third-party XSP taglibs. If we can't agree on
a common interface here, then it probably doesn't make much sense if I
release my code :)

> Well, come back when you have some real problem to solve and not a bunch
> a technologies to glue together "just because it might be cool to".

Sometimes I like to think ahead, is that against the rules on this list?

> ??? let's make a poll here: did you people ever had to throw something
> away because of Cocoon?

Usually the decision goes the other way: not to use Cocoon and keep what
one has.

> 2001: Uli finally gets it. Writes a Generators, asks for an avalon
> component and use it.
> 
> The end. :)
> 
> The problem here, buddy, is that you don't get what inversion of control
> really is and you still want to call Cocoon (as an avalon block, this
> time) and not allow it to call you (or your avalon components).

I do understand what IoC is, but I also understand what the real world
is - and it is not a one-way street. And even if it were a one-way
street, it is still arbitrary to say the direction is Cocoon ==> World
and not vice versa. I am not saying this direction is useless, but I am
defending the direction World ==> Cocoon, which you are cutting short.

Ok, perhaps the point of my little story wasn't clear, so I'll expand on
that. I'll give a very simple example and ask you to scale it up in your
mind:

Suppose we have the requirement to design a system that can generate
dynamic PDFs. Dynamic here means they contain some data from a database.
There is a backend component (an Avalon .sar application) that scans the
database and whenever it finds some new data, it generates a new PDF.
Then there is a frontend component (Cocoon) that presents a
browser-based GUI to people and whenever they click on some data, a new
PDF is generated. So we want a central component that does
XML==>XSLFO==>PDF - for the interactive requests and for the daemon
program.

In my mind it does not make sense for the daemon program to open a
java.net.URLConnection to Cocoon. The PDF generator and the daemon are
both backend components and could both run very sensibly under Phoenix
and talk to each other using the well-defined Avalon contracts, instead
of stateless HTTP. I hope that example convinces you that the world is
not a one-way street, if not perhaps you have a better suggestion for
this concrete example. But please don't tell me to move the daemon's
functionality into the frontend :)

Now, if the project "moving stuff to Avalon" is to enable exactly this
kind of scenario, then we have no disagreement. You can call it IoC, I
can call it componentware and we can all be happy :)

Again: I don't want to call Cocoon from my programs. That is in fact
exactly what I want to avoid. All I want is to ask Cocoon to be nice and
not claim exclusive ownership of things like "XML==>XSLFO==>PDF". Cocoon
can (and does) claim exclusive ownership of the Sitemap, but it can't
(and doesn't) claim exclusive ownership of the URI space. In general:
control your invention, but not the inventions of others.

Take care,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Stefano Mazzocchi <st...@apache.org>]

Uli Mayring wrote:

This discussion is really getting pointless. Detaching avalon to avoid
spamming them.

Note: we already agreed on moving all the required components to avalon
so that other blocks can use them.

> On Mon, 5 Nov 2001, Stefano Mazzocchi wrote:
> 
> > Let's take Cocoon 2.0. Let's remove the "connection overhead", then the
> > "sitemap overhead", than the "cocoon pipelining overhead".
> >
> > What the hell do you end up having?
> 
> Cocoon would remain what it is, it might be distributed as a .sar
> application instead of a .war application. The functionality would be 100%
> the same - with the exception that some people (like me ;-) could do
> *more* with Cocoon, e.g. use it in a world that is not made up of a
> request/response pattern. I am not talking about Cocoon's functionality,
> just its internal structure, so the product would remain the same.

Ok, let's talk about the cocoon behavioral inteface that you envision
then. Since you seem to be contraddicting yourself every other mail.

At least, there is no way to misinterpret java code.
 
> > You what to remove the Servlet API interface, than the sitemap, than the
> > pipeline. So, what you want to do: assemble the pipeline components by
> > hands and run them? should this be called Cocoon?
> 
> No matter what we call it, but it would be more than Cocoon does now :)

Ok, show us what you mean with code, then.
 
> > > > Cocoon is, like it or not, based on a request/response paradigm that is
> > > > modelled after HTTP.
> > >
> > > What is the philosophy behind that model?
> >
> > The philosophy is that this is what I needed when I started the project
> > and then found thousands of people that had the same need and joined the
> > ride (you as well).
> 
> Yeah, I didn't mean the Cocoon1 philosophy, that product has been
> abandoned. I thought maybe this request/response pattern was re-thought
> for Cocoon2 as were so many parts of Cocoon1.

No, it was not, nor I see a good reason to do it.
 
> > Cocoon is not bound to any delivery method. It's bound to the a very
> > general request/response mechanism and even has an pluggable enviornment
> > and object model that was abstracted over HTTP.
> 
> Ok.
> 
> > > Shouldn't there be a
> > > more generic API with HTTP-like request/response being just one of several
> > > wrappers?
> >
> > for example?
> 
> For example queue-based systems. Maybe some people would like to use a
> JMQ-like system. Or rules-based systems. Maybe I'm getting carried away
> here. Need more think :)

Well, come back when you have some real problem to solve and not a bunch
a technologies to glue together "just because it might be cool to".
 
> > > It is probably not very hard to write an Avalon block that does
> > > XML-->XSL(T|FO) - I think most of the code can actually be stolen from
> > > Cocoon and we just need some Avalon wrappers. So I can do that by myself
> > > if the Cocoon project thinks it's a bad idea.
> >
> > What I don't understand is what you want to achieve that some 20 lines
> > of glue code around JAXP 1.1 wouldn't already achieve.
> 
> For my program it does not make a difference which way I do it. I just
> thought that maybe there are several people out there and we all could
> agree on a common format. This common format might become a factor, if
> Cocoon used it as well. That's all.

Ok.
 
> > > Is there any "mission statement" or white paper that explains exactly what
> > > IoC is and why Cocoon uses it?
> >
> > what the heck is a "mission statement" on a open source project?
> 
> Well, some kind of a text. A white paper, a design document, whatever you
> like to call it.

gosh, I was being sarastic: there is no "mission" on an open development
project since development is decided evolutionarly by the people that
work on the project.

> > > Perhaps I misunderstood it, but to me it
> > > looks like some arbitrarily defined interfaces and everything below is a
> > > black box.
> >
> > If this is your vision, there is very little I can do about it.
> 
> Well, you could tell me why the interfaces are not arbitrary and why
> everything below is not a black box :)

Sure: IoC protects you from making mistakes for very complex systems (as
Cocoon is). APIs are small granular things, while components are heavyer
objects. Framework are the heaviest objects around, even if they are
just the skeleton.

Cocoon is a framework.

What you call a "black-box" is, in fact, a way to help you add
functionality to the system without you having to care about the
internal flow and how to do a bunch of stuff on the component.

Guess what: even avalon that you seem to like, it's a "black-box
framework" while the java API can be seen as a while-box framework.

So, either I don't understand what you mean, or you don't understand
what I mean.
 
> > You'd like to use some of the internal Cocoon functionality in a
> > procedural way (you call the API), while Cocoon is a declarative
> > framework (it calls your code to do stuff).
> >
> > Those are opposite directions and cannot work together.
> 
> IIRC we had some very heated discussions about that in Cocoon1 times as
> well. Constantly people would come and ask "how can I call Cocoon from my
> servlet/EJB/whatever". And the response always was: "Convert your
> servlet/EJB/whatever to an XSP taglib and let Cocoon call your
> functionality." Apparently we're running into the same old problem here:
> you can use Cocoon, but if you use it, you must commit to it. Throw your
> other stuff away.

??? let's make a poll here: did you people ever had to throw something
away because of Cocoon?

Look: an XSP taglib can be as small as a few lines of JNI glue code to
your super-huge expert system worth millions of lines of cobol code.
 
> I love Cocoon. There are some things that can be done extremely well with
> Cocoon. But in-between Cocoon1 and Cocoon2 I grew suspicious of that
> commitment. I still think the Sitemap is too proprietary a concept. I'm
> not saying that to criticize Cocoon, just to explain where I'm coming
> from in my thinking. Actually, I'm saying all that evil stuff in order to
> help the Cocoon project :)

I understand this and this is why I'm spending my time replying to you
while other believe it's better to ignore the thread as a whole.

> > But, please, understand that if you want to take Cocoon and cut it in
> > pieces just because you need part of it for your own stuff, well, do it,
> > but don't call it Cocoon because it would not be anymore.
> 
> Destruction is not negative, you must destroy to build. Quick, who said
> it? :)
> 
> Seriously, have a look at this fictitious history of a web application
> developer (the timeline is very arbitrary):
> 
> 1993: Wow, that WWW sure looks cool. I'll write some HTML pages right
> away. My boss won't understand, but one day I'll be the star of the
> company.
> 
> 1994: Hmm... need something to convince the boss. Let me put that cute
> page counter in. A small CGI/Perl script, no problem. Maybe I can hook up
> the coffee machine.
> 
> 1995: We sure have a lot of HTML pages and I can't get any work done,
> because I'm constantly updating them. Whoever said the Web is for our
> marketing department to publish their blurbs??? I need to write some kind
> of generator that makes the HTML pages for me. Especially the navigation
> bar, it's the same thing on every page anyway. Another Perl script, this
> one a bit larger.
> 
> 1996: Ok, the boss finally gets it. Now he wants all kinds of
> functionality on the web pages. More Perl scripts. What do they mean with
> "relaunch"? Oh my God, they're bringing in a designer, how am I going to
> teach that guy Perl??
> 
> 1997: A web shop?? Are you crazy??? This has got to stop. We need some
> common platform for our web functionality and it must integrate with our
> backend systems. Let's do Java on the backend and use servlets for the
> frontend. SSI is good for including the navigation bar.
> 
> 1998: That Java stuff sure is cool. But it sucks to have so many servlets
> and each of them needs to write out HTML. We've put much of our HTML pages
> into servlets. Where are my icons?? Chaos!
> 
> 1999: Man, this Cocoon is the total package. I'll get my HTML transformed
> into XML (which is way cool) and out of the servlets and back into the
> filesystem, where it belongs. Plus I can call real Java code from the XML
> pages, and what's more, I can wrap it in XML taglibs. Life is so good to
> me.
> 
> 2000: Ok... the Cocoon frontends are nice, but they do too much.. the XSP
> pages don't really look like content, they look like logic in an XML
> wrapper. I have to put much of that logic into the backend, where it
> belongs and can be maintained independently from the frontend. My
> colleagues don't know Cocoon, but they do know Java. And I have to finally
> find a sensible platform for all our backend programs.
> 
> 2001: Yeah, Avalon rocks, it can run all our backend programs as blocks.
> Wish they would release the goddamn framework. But our backend is in great
> shape, everyone can maintain it, we basically accept the Avalon wrappers
> around our classes and just code away. Now it's time to look at the
> frontend again. And what do you know? There's a whole new Cocoon out there
> and it is built on top of Avalon. I'm in paradise - I'll just grab that
> .sar application, throw it into the Phoenix apps directory and all our
> backend blocks can instantly talk to Cocoon. Seamless integration of
> frontend and backend - this is so good, I think I'm going to get drunk
> right away.
> 
> Well... some parts of this story are more fictitious than others! ;-)

2001: Uli finally gets it. Writes a Generators, asks for an avalon
component and use it.

The end. :)

The problem here, buddy, is that you don't get what inversion of control
really is and you still want to call Cocoon (as an avalon block, this
time) and not allow it to call you (or your avalon components).

Think about it.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Uli Mayring <ul...@denic.de>]

On Mon, 5 Nov 2001, Stefano Mazzocchi wrote:

> Let's take Cocoon 2.0. Let's remove the "connection overhead", then the
> "sitemap overhead", than the "cocoon pipelining overhead".
> 
> What the hell do you end up having?

Cocoon would remain what it is, it might be distributed as a .sar
application instead of a .war application. The functionality would be 100%
the same - with the exception that some people (like me ;-) could do
*more* with Cocoon, e.g. use it in a world that is not made up of a
request/response pattern. I am not talking about Cocoon's functionality,
just its internal structure, so the product would remain the same.

> You what to remove the Servlet API interface, than the sitemap, than the
> pipeline. So, what you want to do: assemble the pipeline components by
> hands and run them? should this be called Cocoon?

No matter what we call it, but it would be more than Cocoon does now :)

> > > Cocoon is, like it or not, based on a request/response paradigm that is
> > > modelled after HTTP.
> > 
> > What is the philosophy behind that model?
> 
> The philosophy is that this is what I needed when I started the project
> and then found thousands of people that had the same need and joined the
> ride (you as well).

Yeah, I didn't mean the Cocoon1 philosophy, that product has been
abandoned. I thought maybe this request/response pattern was re-thought
for Cocoon2 as were so many parts of Cocoon1.

> Cocoon is not bound to any delivery method. It's bound to the a very
> general request/response mechanism and even has an pluggable enviornment
> and object model that was abstracted over HTTP.

Ok.

> > Shouldn't there be a
> > more generic API with HTTP-like request/response being just one of several
> > wrappers?
> 
> for example?

For example queue-based systems. Maybe some people would like to use a
JMQ-like system. Or rules-based systems. Maybe I'm getting carried away
here. Need more think :)

> > It is probably not very hard to write an Avalon block that does
> > XML-->XSL(T|FO) - I think most of the code can actually be stolen from
> > Cocoon and we just need some Avalon wrappers. So I can do that by myself
> > if the Cocoon project thinks it's a bad idea.
> 
> What I don't understand is what you want to achieve that some 20 lines
> of glue code around JAXP 1.1 wouldn't already achieve.

For my program it does not make a difference which way I do it. I just
thought that maybe there are several people out there and we all could
agree on a common format. This common format might become a factor, if
Cocoon used it as well. That's all.

> > Is there any "mission statement" or white paper that explains exactly what
> > IoC is and why Cocoon uses it?
> 
> what the heck is a "mission statement" on a open source project?

Well, some kind of a text. A white paper, a design document, whatever you
like to call it.

> > Perhaps I misunderstood it, but to me it
> > looks like some arbitrarily defined interfaces and everything below is a
> > black box.
> 
> If this is your vision, there is very little I can do about it.

Well, you could tell me why the interfaces are not arbitrary and why
everything below is not a black box :)

> You'd like to use some of the internal Cocoon functionality in a
> procedural way (you call the API), while Cocoon is a declarative
> framework (it calls your code to do stuff).
> 
> Those are opposite directions and cannot work together.

IIRC we had some very heated discussions about that in Cocoon1 times as
well. Constantly people would come and ask "how can I call Cocoon from my
servlet/EJB/whatever". And the response always was: "Convert your
servlet/EJB/whatever to an XSP taglib and let Cocoon call your
functionality." Apparently we're running into the same old problem here:
you can use Cocoon, but if you use it, you must commit to it. Throw your
other stuff away.

I love Cocoon. There are some things that can be done extremely well with
Cocoon. But in-between Cocoon1 and Cocoon2 I grew suspicious of that 
commitment. I still think the Sitemap is too proprietary a concept. I'm
not saying that to criticize Cocoon, just to explain where I'm coming
from in my thinking. Actually, I'm saying all that evil stuff in order to
help the Cocoon project :)

> But, please, understand that if you want to take Cocoon and cut it in
> pieces just because you need part of it for your own stuff, well, do it,
> but don't call it Cocoon because it would not be anymore.

Destruction is not negative, you must destroy to build. Quick, who said
it? :)

Seriously, have a look at this fictitious history of a web application
developer (the timeline is very arbitrary):

1993: Wow, that WWW sure looks cool. I'll write some HTML pages right
away. My boss won't understand, but one day I'll be the star of the
company.

1994: Hmm... need something to convince the boss. Let me put that cute
page counter in. A small CGI/Perl script, no problem. Maybe I can hook up
the coffee machine.

1995: We sure have a lot of HTML pages and I can't get any work done,
because I'm constantly updating them. Whoever said the Web is for our
marketing department to publish their blurbs??? I need to write some kind
of generator that makes the HTML pages for me. Especially the navigation
bar, it's the same thing on every page anyway. Another Perl script, this
one a bit larger.

1996: Ok, the boss finally gets it. Now he wants all kinds of
functionality on the web pages. More Perl scripts. What do they mean with
"relaunch"? Oh my God, they're bringing in a designer, how am I going to
teach that guy Perl??

1997: A web shop?? Are you crazy??? This has got to stop. We need some
common platform for our web functionality and it must integrate with our
backend systems. Let's do Java on the backend and use servlets for the
frontend. SSI is good for including the navigation bar.

1998: That Java stuff sure is cool. But it sucks to have so many servlets
and each of them needs to write out HTML. We've put much of our HTML pages
into servlets. Where are my icons?? Chaos!

1999: Man, this Cocoon is the total package. I'll get my HTML transformed
into XML (which is way cool) and out of the servlets and back into the
filesystem, where it belongs. Plus I can call real Java code from the XML
pages, and what's more, I can wrap it in XML taglibs. Life is so good to
me.

2000: Ok... the Cocoon frontends are nice, but they do too much.. the XSP
pages don't really look like content, they look like logic in an XML
wrapper. I have to put much of that logic into the backend, where it
belongs and can be maintained independently from the frontend. My
colleagues don't know Cocoon, but they do know Java. And I have to finally
find a sensible platform for all our backend programs.

2001: Yeah, Avalon rocks, it can run all our backend programs as blocks.
Wish they would release the goddamn framework. But our backend is in great
shape, everyone can maintain it, we basically accept the Avalon wrappers
around our classes and just code away. Now it's time to look at the
frontend again. And what do you know? There's a whole new Cocoon out there
and it is built on top of Avalon. I'm in paradise - I'll just grab that
.sar application, throw it into the Phoenix apps directory and all our
backend blocks can instantly talk to Cocoon. Seamless integration of
frontend and backend - this is so good, I think I'm going to get drunk
right away.

Well... some parts of this story are more fictitious than others! ;-)

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Uli Mayring <ul...@denic.de>]

On Mon, 5 Nov 2001, Stefano Mazzocchi wrote:

> Let's take Cocoon 2.0. Let's remove the "connection overhead", then the
> "sitemap overhead", than the "cocoon pipelining overhead".
> 
> What the hell do you end up having?

Cocoon would remain what it is, it might be distributed as a .sar
application instead of a .war application. The functionality would be 100%
the same - with the exception that some people (like me ;-) could do
*more* with Cocoon, e.g. use it in a world that is not made up of a
request/response pattern. I am not talking about Cocoon's functionality,
just its internal structure, so the product would remain the same.

> You what to remove the Servlet API interface, than the sitemap, than the
> pipeline. So, what you want to do: assemble the pipeline components by
> hands and run them? should this be called Cocoon?

No matter what we call it, but it would be more than Cocoon does now :)

> > > Cocoon is, like it or not, based on a request/response paradigm that is
> > > modelled after HTTP.
> > 
> > What is the philosophy behind that model?
> 
> The philosophy is that this is what I needed when I started the project
> and then found thousands of people that had the same need and joined the
> ride (you as well).

Yeah, I didn't mean the Cocoon1 philosophy, that product has been
abandoned. I thought maybe this request/response pattern was re-thought
for Cocoon2 as were so many parts of Cocoon1.

> Cocoon is not bound to any delivery method. It's bound to the a very
> general request/response mechanism and even has an pluggable enviornment
> and object model that was abstracted over HTTP.

Ok.

> > Shouldn't there be a
> > more generic API with HTTP-like request/response being just one of several
> > wrappers?
> 
> for example?

For example queue-based systems. Maybe some people would like to use a
JMQ-like system. Or rules-based systems. Maybe I'm getting carried away
here. Need more think :)

> > It is probably not very hard to write an Avalon block that does
> > XML-->XSL(T|FO) - I think most of the code can actually be stolen from
> > Cocoon and we just need some Avalon wrappers. So I can do that by myself
> > if the Cocoon project thinks it's a bad idea.
> 
> What I don't understand is what you want to achieve that some 20 lines
> of glue code around JAXP 1.1 wouldn't already achieve.

For my program it does not make a difference which way I do it. I just
thought that maybe there are several people out there and we all could
agree on a common format. This common format might become a factor, if
Cocoon used it as well. That's all.

> > Is there any "mission statement" or white paper that explains exactly what
> > IoC is and why Cocoon uses it?
> 
> what the heck is a "mission statement" on a open source project?

Well, some kind of a text. A white paper, a design document, whatever you
like to call it.

> > Perhaps I misunderstood it, but to me it
> > looks like some arbitrarily defined interfaces and everything below is a
> > black box.
> 
> If this is your vision, there is very little I can do about it.

Well, you could tell me why the interfaces are not arbitrary and why
everything below is not a black box :)

> You'd like to use some of the internal Cocoon functionality in a
> procedural way (you call the API), while Cocoon is a declarative
> framework (it calls your code to do stuff).
> 
> Those are opposite directions and cannot work together.

IIRC we had some very heated discussions about that in Cocoon1 times as
well. Constantly people would come and ask "how can I call Cocoon from my
servlet/EJB/whatever". And the response always was: "Convert your
servlet/EJB/whatever to an XSP taglib and let Cocoon call your
functionality." Apparently we're running into the same old problem here:
you can use Cocoon, but if you use it, you must commit to it. Throw your
other stuff away.

I love Cocoon. There are some things that can be done extremely well with
Cocoon. But in-between Cocoon1 and Cocoon2 I grew suspicious of that 
commitment. I still think the Sitemap is too proprietary a concept. I'm
not saying that to criticize Cocoon, just to explain where I'm coming
from in my thinking. Actually, I'm saying all that evil stuff in order to
help the Cocoon project :)

> But, please, understand that if you want to take Cocoon and cut it in
> pieces just because you need part of it for your own stuff, well, do it,
> but don't call it Cocoon because it would not be anymore.

Destruction is not negative, you must destroy to build. Quick, who said
it? :)

Seriously, have a look at this fictitious history of a web application
developer (the timeline is very arbitrary):

1993: Wow, that WWW sure looks cool. I'll write some HTML pages right
away. My boss won't understand, but one day I'll be the star of the
company.

1994: Hmm... need something to convince the boss. Let me put that cute
page counter in. A small CGI/Perl script, no problem. Maybe I can hook up
the coffee machine.

1995: We sure have a lot of HTML pages and I can't get any work done,
because I'm constantly updating them. Whoever said the Web is for our
marketing department to publish their blurbs??? I need to write some kind
of generator that makes the HTML pages for me. Especially the navigation
bar, it's the same thing on every page anyway. Another Perl script, this
one a bit larger.

1996: Ok, the boss finally gets it. Now he wants all kinds of
functionality on the web pages. More Perl scripts. What do they mean with
"relaunch"? Oh my God, they're bringing in a designer, how am I going to
teach that guy Perl??

1997: A web shop?? Are you crazy??? This has got to stop. We need some
common platform for our web functionality and it must integrate with our
backend systems. Let's do Java on the backend and use servlets for the
frontend. SSI is good for including the navigation bar.

1998: That Java stuff sure is cool. But it sucks to have so many servlets
and each of them needs to write out HTML. We've put much of our HTML pages
into servlets. Where are my icons?? Chaos!

1999: Man, this Cocoon is the total package. I'll get my HTML transformed
into XML (which is way cool) and out of the servlets and back into the
filesystem, where it belongs. Plus I can call real Java code from the XML
pages, and what's more, I can wrap it in XML taglibs. Life is so good to
me.

2000: Ok... the Cocoon frontends are nice, but they do too much.. the XSP
pages don't really look like content, they look like logic in an XML
wrapper. I have to put much of that logic into the backend, where it
belongs and can be maintained independently from the frontend. My
colleagues don't know Cocoon, but they do know Java. And I have to finally
find a sensible platform for all our backend programs.

2001: Yeah, Avalon rocks, it can run all our backend programs as blocks.
Wish they would release the goddamn framework. But our backend is in great
shape, everyone can maintain it, we basically accept the Avalon wrappers
around our classes and just code away. Now it's time to look at the
frontend again. And what do you know? There's a whole new Cocoon out there
and it is built on top of Avalon. I'm in paradise - I'll just grab that
.sar application, throw it into the Phoenix apps directory and all our
backend blocks can instantly talk to Cocoon. Seamless integration of
frontend and backend - this is so good, I think I'm going to get drunk
right away.

Well... some parts of this story are more fictitious than others! ;-)

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Stefano Mazzocchi <st...@apache.org>]

Uli Mayring wrote:

> Not only the connection overhead, but also the Sitemap overhead, the
> Cocoon pipelining overhead etc. - it's not only a question of speed, but
> also one of usability.

Hmmm, ok, let's factor this out.

Let's take Cocoon 2.0. Let's remove the "connection overhead", then the
"sitemap overhead", than the "cocoon pipelining overhead".

What the hell do you end up having?

We *are* already moving a bunch of components over to avalon-land, those
components that could be useful for many other stuff and not only
cocoon's.

You what to remove the Servlet API interface, than the sitemap, than the
pipeline. So, what you want to do: assemble the pipeline components by
hands and run them? should this be called Cocoon?
 
> > Now, this said, please reread the above sentence: the key part is
> > "obtain cocoon services".
> >
> > Cocoon is, like it or not, based on a request/response paradigm that is
> > modelled after HTTP.
> 
> What is the philosophy behind that model?

The philosophy is that this is what I needed when I started the project
and then found thousands of people that had the same need and joined the
ride (you as well).

> Why tie Cocoon to a specific
> delivery method, even though only philosophically?

Cocoon is not bound to any delivery method. It's bound to the a very
general request/response mechanism and even has an pluggable enviornment
and object model that was abstracted over HTTP.

> Shouldn't there be a
> more generic API with HTTP-like request/response being just one of several
> wrappers?

for example?

> > So, my vision is that if you want "XML --> XSL(T|FO)" processing block,
> > you are going to create a behavioral interface that doesn't ask for a
> > particular Cocoon resource, but pushes the various streams into the
> > service and wants to obtain a result.
> 
> Yes, I am very open as to the exact API, but I think it should be simpler
> than having to install a whole Cocoon pipeline and push my request over
> HTTP.

Read my lips: if you want to remove the connection overhead from Cocoon
and write an avalon block around it, I'm fine with that, as long as the
main architecture is not compromised by that.

> It is probably not very hard to write an Avalon block that does
> XML-->XSL(T|FO) - I think most of the code can actually be stolen from
> Cocoon and we just need some Avalon wrappers. So I can do that by myself
> if the Cocoon project thinks it's a bad idea.

What I don't understand is what you want to achieve that some 20 lines
of glue code around JAXP 1.1 wouldn't already achieve.

> > I simply do not and for the reason above: IoC means that you ask for a
> > resource to Cocoon and it knows what to do.
> >
> > This is a design pattern that must not be altered in any way, under any
> > circumstance or Cocoon will be nothing different from
> > Xerces+Xalan+FOP+Batik.
> 
> You call it a design pattern, but 10 years ago such a system was called a
> monolithic black-box.

Wow. What a sentence :)

> Of course every system is a monolithic black-box at
> some point, if you go deep enough. But then every system is also IoC and
> it is arbitrary where you define the legal entry-points to be.

I agree with this statement.
 
> I think "Xerces+Xalan+FOP+Batik" is not Cocoon. These are seperate
> projects and every Apache project can use them as they see fit. But I
> think it would be good, if the various projects could agree on interfaces.

Oh, I think nobody in the java world disagree with you on this.

> But this interface cannot be Cocoon, because it assumes too much. For me
> Cocoon is the Sitemap, XSP, generators, serializers etc. - of those I
> would only like to steal XSP, because code generation may be useful in
> other places as well.

As I said, we are happy to factor out all components that can be useful
someplace else, including code generation.
 
> > I hope you guys understand my strong feelings about IoC.
> 
> Is there any "mission statement" or white paper that explains exactly what
> IoC is and why Cocoon uses it?

what the heck is a "mission statement" on a open source project?

> Perhaps I misunderstood it, but to me it
> looks like some arbitrarily defined interfaces and everything below is a
> black box.

If this is your vision, there is very little I can do about it.

You'd like to use some of the internal Cocoon functionality in a
procedural way (you call the API), while Cocoon is a declarative
framework (it calls your code to do stuff).

Those are opposite directions and cannot work together.
 
> > If not so, please, make yourself heard because it's vital that we all
> > agree on something so basic.
> 
> If I remember correctly, in the ca. 2 years I've been involved with Cocoon
> and recently Avalon I haven't managed to persuade anyone of anything.

This doesn't mean anything.

> Actually, much of what I said one year ago wouldn't persuade me today,
> either.

:)

> So, chances are I'm in the minority again with my opinion :)

Ulrich,

I don't have anything against your proposal if this requires to move
some Cocoon functionality over to Avalon. Both projects already agreed
that this is a good thing to do.

But, please, understand that if you want to take Cocoon and cut it in
pieces just because you need part of it for your own stuff, well, do it,
but don't call it Cocoon because it would not be anymore.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Stefano Mazzocchi <st...@apache.org>]

Uli Mayring wrote:

> Not only the connection overhead, but also the Sitemap overhead, the
> Cocoon pipelining overhead etc. - it's not only a question of speed, but
> also one of usability.

Hmmm, ok, let's factor this out.

Let's take Cocoon 2.0. Let's remove the "connection overhead", then the
"sitemap overhead", than the "cocoon pipelining overhead".

What the hell do you end up having?

We *are* already moving a bunch of components over to avalon-land, those
components that could be useful for many other stuff and not only
cocoon's.

You what to remove the Servlet API interface, than the sitemap, than the
pipeline. So, what you want to do: assemble the pipeline components by
hands and run them? should this be called Cocoon?
 
> > Now, this said, please reread the above sentence: the key part is
> > "obtain cocoon services".
> >
> > Cocoon is, like it or not, based on a request/response paradigm that is
> > modelled after HTTP.
> 
> What is the philosophy behind that model?

The philosophy is that this is what I needed when I started the project
and then found thousands of people that had the same need and joined the
ride (you as well).

> Why tie Cocoon to a specific
> delivery method, even though only philosophically?

Cocoon is not bound to any delivery method. It's bound to the a very
general request/response mechanism and even has an pluggable enviornment
and object model that was abstracted over HTTP.

> Shouldn't there be a
> more generic API with HTTP-like request/response being just one of several
> wrappers?

for example?

> > So, my vision is that if you want "XML --> XSL(T|FO)" processing block,
> > you are going to create a behavioral interface that doesn't ask for a
> > particular Cocoon resource, but pushes the various streams into the
> > service and wants to obtain a result.
> 
> Yes, I am very open as to the exact API, but I think it should be simpler
> than having to install a whole Cocoon pipeline and push my request over
> HTTP.

Read my lips: if you want to remove the connection overhead from Cocoon
and write an avalon block around it, I'm fine with that, as long as the
main architecture is not compromised by that.

> It is probably not very hard to write an Avalon block that does
> XML-->XSL(T|FO) - I think most of the code can actually be stolen from
> Cocoon and we just need some Avalon wrappers. So I can do that by myself
> if the Cocoon project thinks it's a bad idea.

What I don't understand is what you want to achieve that some 20 lines
of glue code around JAXP 1.1 wouldn't already achieve.

> > I simply do not and for the reason above: IoC means that you ask for a
> > resource to Cocoon and it knows what to do.
> >
> > This is a design pattern that must not be altered in any way, under any
> > circumstance or Cocoon will be nothing different from
> > Xerces+Xalan+FOP+Batik.
> 
> You call it a design pattern, but 10 years ago such a system was called a
> monolithic black-box.

Wow. What a sentence :)

> Of course every system is a monolithic black-box at
> some point, if you go deep enough. But then every system is also IoC and
> it is arbitrary where you define the legal entry-points to be.

I agree with this statement.
 
> I think "Xerces+Xalan+FOP+Batik" is not Cocoon. These are seperate
> projects and every Apache project can use them as they see fit. But I
> think it would be good, if the various projects could agree on interfaces.

Oh, I think nobody in the java world disagree with you on this.

> But this interface cannot be Cocoon, because it assumes too much. For me
> Cocoon is the Sitemap, XSP, generators, serializers etc. - of those I
> would only like to steal XSP, because code generation may be useful in
> other places as well.

As I said, we are happy to factor out all components that can be useful
someplace else, including code generation.
 
> > I hope you guys understand my strong feelings about IoC.
> 
> Is there any "mission statement" or white paper that explains exactly what
> IoC is and why Cocoon uses it?

what the heck is a "mission statement" on a open source project?

> Perhaps I misunderstood it, but to me it
> looks like some arbitrarily defined interfaces and everything below is a
> black box.

If this is your vision, there is very little I can do about it.

You'd like to use some of the internal Cocoon functionality in a
procedural way (you call the API), while Cocoon is a declarative
framework (it calls your code to do stuff).

Those are opposite directions and cannot work together.
 
> > If not so, please, make yourself heard because it's vital that we all
> > agree on something so basic.
> 
> If I remember correctly, in the ca. 2 years I've been involved with Cocoon
> and recently Avalon I haven't managed to persuade anyone of anything.

This doesn't mean anything.

> Actually, much of what I said one year ago wouldn't persuade me today,
> either.

:)

> So, chances are I'm in the minority again with my opinion :)

Ulrich,

I don't have anything against your proposal if this requires to move
some Cocoon functionality over to Avalon. Both projects already agreed
that this is a good thing to do.

But, please, understand that if you want to take Cocoon and cut it in
pieces just because you need part of it for your own stuff, well, do it,
but don't call it Cocoon because it would not be anymore.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Uli Mayring <ul...@denic.de>]

On Sat, 3 Nov 2001, Stefano Mazzocchi wrote:

> [sorry for crossposting, but this interests both communities, I think]

I believe so, too, so I maintained the crossposting.

> One question: you want to remove the connection overhead in order to
> obtain Cocoon services and I agree that this is a "good thing"(tm).

Not only the connection overhead, but also the Sitemap overhead, the
Cocoon pipelining overhead etc. - it's not only a question of speed, but 
also one of usability.

> Originally, Pier and I designed Cocoon2 to be an avalon block but
> decided to move away from that since the APIs weren't solid enough.

Fair enough.

> Now, this said, please reread the above sentence: the key part is
> "obtain cocoon services".
> 
> Cocoon is, like it or not, based on a request/response paradigm that is
> modelled after HTTP.

What is the philosophy behind that model? Why tie Cocoon to a specific
delivery method, even though only philosophically? Shouldn't there be a
more generic API with HTTP-like request/response being just one of several
wrappers?

> So, my vision is that if you want "XML --> XSL(T|FO)" processing block,
> you are going to create a behavioral interface that doesn't ask for a
> particular Cocoon resource, but pushes the various streams into the
> service and wants to obtain a result.

Yes, I am very open as to the exact API, but I think it should be simpler
than having to install a whole Cocoon pipeline and push my request over
HTTP. It is probably not very hard to write an Avalon block that does
XML-->XSL(T|FO) - I think most of the code can actually be stolen from
Cocoon and we just need some Avalon wrappers. So I can do that by myself
if the Cocoon project thinks it's a bad idea.

> I simply do not and for the reason above: IoC means that you ask for a
> resource to Cocoon and it knows what to do.
>
> This is a design pattern that must not be altered in any way, under any
> circumstance or Cocoon will be nothing different from
> Xerces+Xalan+FOP+Batik.

You call it a design pattern, but 10 years ago such a system was called a
monolithic black-box. Of course every system is a monolithic black-box at
some point, if you go deep enough. But then every system is also IoC and
it is arbitrary where you define the legal entry-points to be.

I think "Xerces+Xalan+FOP+Batik" is not Cocoon. These are seperate
projects and every Apache project can use them as they see fit. But I
think it would be good, if the various projects could agree on interfaces. 
But this interface cannot be Cocoon, because it assumes too much. For me
Cocoon is the Sitemap, XSP, generators, serializers etc. - of those I
would only like to steal XSP, because code generation may be useful in
other places as well.

> I hope you guys understand my strong feelings about IoC.

Is there any "mission statement" or white paper that explains exactly what
IoC is and why Cocoon uses it? Perhaps I misunderstood it, but to me it
looks like some arbitrarily defined interfaces and everything below is a
black box.

> If not so, please, make yourself heard because it's vital that we all
> agree on something so basic.

If I remember correctly, in the ca. 2 years I've been involved with Cocoon
and recently Avalon I haven't managed to persuade anyone of anything.
Actually, much of what I said one year ago wouldn't persuade me today,
either. So, chances are I'm in the minority again with my opinion :)

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Uli Mayring <ul...@denic.de>]

On Sat, 3 Nov 2001, Stefano Mazzocchi wrote:

> [sorry for crossposting, but this interests both communities, I think]

I believe so, too, so I maintained the crossposting.

> One question: you want to remove the connection overhead in order to
> obtain Cocoon services and I agree that this is a "good thing"(tm).

Not only the connection overhead, but also the Sitemap overhead, the
Cocoon pipelining overhead etc. - it's not only a question of speed, but 
also one of usability.

> Originally, Pier and I designed Cocoon2 to be an avalon block but
> decided to move away from that since the APIs weren't solid enough.

Fair enough.

> Now, this said, please reread the above sentence: the key part is
> "obtain cocoon services".
> 
> Cocoon is, like it or not, based on a request/response paradigm that is
> modelled after HTTP.

What is the philosophy behind that model? Why tie Cocoon to a specific
delivery method, even though only philosophically? Shouldn't there be a
more generic API with HTTP-like request/response being just one of several
wrappers?

> So, my vision is that if you want "XML --> XSL(T|FO)" processing block,
> you are going to create a behavioral interface that doesn't ask for a
> particular Cocoon resource, but pushes the various streams into the
> service and wants to obtain a result.

Yes, I am very open as to the exact API, but I think it should be simpler
than having to install a whole Cocoon pipeline and push my request over
HTTP. It is probably not very hard to write an Avalon block that does
XML-->XSL(T|FO) - I think most of the code can actually be stolen from
Cocoon and we just need some Avalon wrappers. So I can do that by myself
if the Cocoon project thinks it's a bad idea.

> I simply do not and for the reason above: IoC means that you ask for a
> resource to Cocoon and it knows what to do.
>
> This is a design pattern that must not be altered in any way, under any
> circumstance or Cocoon will be nothing different from
> Xerces+Xalan+FOP+Batik.

You call it a design pattern, but 10 years ago such a system was called a
monolithic black-box. Of course every system is a monolithic black-box at
some point, if you go deep enough. But then every system is also IoC and
it is arbitrary where you define the legal entry-points to be.

I think "Xerces+Xalan+FOP+Batik" is not Cocoon. These are seperate
projects and every Apache project can use them as they see fit. But I
think it would be good, if the various projects could agree on interfaces. 
But this interface cannot be Cocoon, because it assumes too much. For me
Cocoon is the Sitemap, XSP, generators, serializers etc. - of those I
would only like to steal XSP, because code generation may be useful in
other places as well.

> I hope you guys understand my strong feelings about IoC.

Is there any "mission statement" or white paper that explains exactly what
IoC is and why Cocoon uses it? Perhaps I misunderstood it, but to me it
looks like some arbitrarily defined interfaces and everything below is a
black box.

> If not so, please, make yourself heard because it's vital that we all
> agree on something so basic.

If I remember correctly, in the ca. 2 years I've been involved with Cocoon
and recently Avalon I haven't managed to persuade anyone of anything.
Actually, much of what I said one year ago wouldn't persuade me today,
either. So, chances are I'm in the minority again with my opinion :)

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Stefano Mazzocchi <st...@apache.org>]

Ulrich Mayring wrote:
> 
> Paul Hammant wrote:
> >
> > Err, are we not talking baout mounting Cocoon inside Jo inside Phoenix?
> 
> [Cc: to cocoon-dev list]
> 
> Normally the webserver has to parse the request and then, after
> determining that the request is for the servlet engine, make a TCP/IP
> connection to it and pass the request on. The connection is a costly
> operation, even if on the same host. Then, the servlet engine needs to
> parse the request again in order to determine which servlet is
> responsible for it. In Jo's case the webserver can talk directly to the
> servlet engine, as they are one application. The servlet engine itself
> never makes a TCP/IP connection, it just starts a servlet in the same
> JVM. Now I can think of several possibilities:
> 
> 1) Instead of starting a servlet, make Jo call various Cocoon-blocks
> (which implement Callable or somesuch interface)
> 2) Have Jo call a dispatcher servlet, that can then call the various
> Cocoon-blocks and also use other Avalon-Blocks.
> 3) Install Cocoon as a .war application under Jo.
> 
> The third option is the easiest to implement, but you can only use
> Cocoon as a monolithic application and you cannot access it without a
> costly HTTP connection, even if you are in the same JVM.
> 
> The first option requires changes in Jo and I don't think the Jo
> developer wants to introduce proprietary Phoenix connectors.
> 
> So the second option seems to be best. It has the advantage that you
> only need to go over Jo and the Dispatcher servlet, when requests come
> in via HTTP from outside users. If you have a .sar application under
> Phoenix, then it can use the Cocoon-blocks directly.
> 
> For example, we have a lot of asynchronous requests, which come in via
> email. They are stored in a MessageQueue and processed by various .sar
> applications. The result of the transaction is sent out via email again
> - it would be nice, if I could attach a dynamically generated PDF. So
> for that I'd like to have a "XML-->XSL(T|FO)" block, I probably don't
> care much about XSP, the Sitemap, generators and all the other bells and
> whistles Cocoon has. But the same block could also be used to serve
> dynamically generated PDFs to synchronous connections coming in over
> HTTP.

[sorry for crossposting, but this interests both communities, I think]

One question: you want to remove the connection overhead in order to
obtain Cocoon services and I agree that this is a "good thing"(tm).
Originally, Pier and I designed Cocoon2 to be an avalon block but
decided to move away from that since the APIs weren't solid enough.

Now, this said, please reread the above sentence: the key part is
"obtain cocoon services".

Cocoon is, like it or not, based on a request/response paradigm that is
modelled after HTTP.

Sure, the environment is abstract and I still believe that a Mailet
interface can be written around Cocoon to provide XML-based mail
handling capabilities of some sort, but we decided to focus on web
development.

So, my vision is that if you want "XML --> XSL(T|FO)" processing block,
you are going to create a behavioral interface that doesn't ask for a
particular Cocoon resource, but pushes the various streams into the
service and wants to obtain a result.

This is what we call "Subversion of Control"!

And it's evil since it twistes a bood IoC design in such a way that it
becomes a nightmare for users to understand and for developers to
manage.

So, my vote to the proposal "would you like to add block-like behavior
to Cocoon" is *heavily* dependent on what you want this block interface
to be.

If you want to model IoC behavior, then +1.

If you want some XML processing API, then -1.

There are people that believe that Cocoon can be turned into a service
and maintain its architectural efficiency and elegant design (i.e. the
Turbine people that say they support Cocoon just because they use it as
a XSLT tranformer!).

I simply do not and for the reason above: IoC means that you ask for a
resource to Cocoon and it knows what to do.

This is a design pattern that must not be altered in any way, under any
circumstance or Cocoon will be nothing different from
Xerces+Xalan+FOP+Batik.

I hope you guys understand my strong feelings about IoC.

If not so, please, make yourself heard because it's vital that we all
agree on something so basic.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Stefano Mazzocchi <st...@apache.org>]

Ulrich Mayring wrote:
> 
> Paul Hammant wrote:
> >
> > Err, are we not talking baout mounting Cocoon inside Jo inside Phoenix?
> 
> [Cc: to cocoon-dev list]
> 
> Normally the webserver has to parse the request and then, after
> determining that the request is for the servlet engine, make a TCP/IP
> connection to it and pass the request on. The connection is a costly
> operation, even if on the same host. Then, the servlet engine needs to
> parse the request again in order to determine which servlet is
> responsible for it. In Jo's case the webserver can talk directly to the
> servlet engine, as they are one application. The servlet engine itself
> never makes a TCP/IP connection, it just starts a servlet in the same
> JVM. Now I can think of several possibilities:
> 
> 1) Instead of starting a servlet, make Jo call various Cocoon-blocks
> (which implement Callable or somesuch interface)
> 2) Have Jo call a dispatcher servlet, that can then call the various
> Cocoon-blocks and also use other Avalon-Blocks.
> 3) Install Cocoon as a .war application under Jo.
> 
> The third option is the easiest to implement, but you can only use
> Cocoon as a monolithic application and you cannot access it without a
> costly HTTP connection, even if you are in the same JVM.
> 
> The first option requires changes in Jo and I don't think the Jo
> developer wants to introduce proprietary Phoenix connectors.
> 
> So the second option seems to be best. It has the advantage that you
> only need to go over Jo and the Dispatcher servlet, when requests come
> in via HTTP from outside users. If you have a .sar application under
> Phoenix, then it can use the Cocoon-blocks directly.
> 
> For example, we have a lot of asynchronous requests, which come in via
> email. They are stored in a MessageQueue and processed by various .sar
> applications. The result of the transaction is sent out via email again
> - it would be nice, if I could attach a dynamically generated PDF. So
> for that I'd like to have a "XML-->XSL(T|FO)" block, I probably don't
> care much about XSP, the Sitemap, generators and all the other bells and
> whistles Cocoon has. But the same block could also be used to serve
> dynamically generated PDFs to synchronous connections coming in over
> HTTP.

[sorry for crossposting, but this interests both communities, I think]

One question: you want to remove the connection overhead in order to
obtain Cocoon services and I agree that this is a "good thing"(tm).
Originally, Pier and I designed Cocoon2 to be an avalon block but
decided to move away from that since the APIs weren't solid enough.

Now, this said, please reread the above sentence: the key part is
"obtain cocoon services".

Cocoon is, like it or not, based on a request/response paradigm that is
modelled after HTTP.

Sure, the environment is abstract and I still believe that a Mailet
interface can be written around Cocoon to provide XML-based mail
handling capabilities of some sort, but we decided to focus on web
development.

So, my vision is that if you want "XML --> XSL(T|FO)" processing block,
you are going to create a behavioral interface that doesn't ask for a
particular Cocoon resource, but pushes the various streams into the
service and wants to obtain a result.

This is what we call "Subversion of Control"!

And it's evil since it twistes a bood IoC design in such a way that it
becomes a nightmare for users to understand and for developers to
manage.

So, my vote to the proposal "would you like to add block-like behavior
to Cocoon" is *heavily* dependent on what you want this block interface
to be.

If you want to model IoC behavior, then +1.

If you want some XML processing API, then -1.

There are people that believe that Cocoon can be turned into a service
and maintain its architectural efficiency and elegant design (i.e. the
Turbine people that say they support Cocoon just because they use it as
a XSLT tranformer!).

I simply do not and for the reason above: IoC means that you ask for a
resource to Cocoon and it knows what to do.

This is a design pattern that must not be altered in any way, under any
circumstance or Cocoon will be nothing different from
Xerces+Xalan+FOP+Batik.

I hope you guys understand my strong feelings about IoC.

If not so, please, make yourself heard because it's vital that we all
agree on something so basic.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Ulrich Mayring <ul...@denic.de>]

Paul Hammant wrote:
> 
> Err, are we not talking baout mounting Cocoon inside Jo inside Phoenix?

[Cc: to cocoon-dev list]

Normally the webserver has to parse the request and then, after
determining that the request is for the servlet engine, make a TCP/IP
connection to it and pass the request on. The connection is a costly
operation, even if on the same host. Then, the servlet engine needs to
parse the request again in order to determine which servlet is
responsible for it. In Jo's case the webserver can talk directly to the
servlet engine, as they are one application. The servlet engine itself
never makes a TCP/IP connection, it just starts a servlet in the same
JVM. Now I can think of several possibilities:

1) Instead of starting a servlet, make Jo call various Cocoon-blocks
(which implement Callable or somesuch interface)
2) Have Jo call a dispatcher servlet, that can then call the various
Cocoon-blocks and also use other Avalon-Blocks.
3) Install Cocoon as a .war application under Jo.

The third option is the easiest to implement, but you can only use
Cocoon as a monolithic application and you cannot access it without a
costly HTTP connection, even if you are in the same JVM.

The first option requires changes in Jo and I don't think the Jo
developer wants to introduce proprietary Phoenix connectors.

So the second option seems to be best. It has the advantage that you
only need to go over Jo and the Dispatcher servlet, when requests come
in via HTTP from outside users. If you have a .sar application under
Phoenix, then it can use the Cocoon-blocks directly.

For example, we have a lot of asynchronous requests, which come in via
email. They are stored in a MessageQueue and processed by various .sar
applications. The result of the transaction is sent out via email again
- it would be nice, if I could attach a dynamically generated PDF. So
for that I'd like to have a "XML-->XSL(T|FO)" block, I probably don't
care much about XSP, the Sitemap, generators and all the other bells and
whistles Cocoon has. But the same block could also be used to serve
dynamically generated PDFs to synchronous connections coming in over
HTTP.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Ulrich Mayring <ul...@denic.de>]

Paul Hammant wrote:
> 
> Err, are we not talking baout mounting Cocoon inside Jo inside Phoenix?

[Cc: to cocoon-dev list]

Normally the webserver has to parse the request and then, after
determining that the request is for the servlet engine, make a TCP/IP
connection to it and pass the request on. The connection is a costly
operation, even if on the same host. Then, the servlet engine needs to
parse the request again in order to determine which servlet is
responsible for it. In Jo's case the webserver can talk directly to the
servlet engine, as they are one application. The servlet engine itself
never makes a TCP/IP connection, it just starts a servlet in the same
JVM. Now I can think of several possibilities:

1) Instead of starting a servlet, make Jo call various Cocoon-blocks
(which implement Callable or somesuch interface)
2) Have Jo call a dispatcher servlet, that can then call the various
Cocoon-blocks and also use other Avalon-Blocks.
3) Install Cocoon as a .war application under Jo.

The third option is the easiest to implement, but you can only use
Cocoon as a monolithic application and you cannot access it without a
costly HTTP connection, even if you are in the same JVM.

The first option requires changes in Jo and I don't think the Jo
developer wants to introduce proprietary Phoenix connectors.

So the second option seems to be best. It has the advantage that you
only need to go over Jo and the Dispatcher servlet, when requests come
in via HTTP from outside users. If you have a .sar application under
Phoenix, then it can use the Cocoon-blocks directly.

For example, we have a lot of asynchronous requests, which come in via
email. They are stored in a MessageQueue and processed by various .sar
applications. The result of the transaction is sent out via email again
- it would be nice, if I could attach a dynamically generated PDF. So
for that I'd like to have a "XML-->XSL(T|FO)" block, I probably don't
care much about XSP, the Sitemap, generators and all the other bells and
whistles Cocoon has. But the same block could also be used to serve
dynamically generated PDFs to synchronous connections coming in over
HTTP.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Jo! & WAR file apps

[Paul Hammant <Pa...@yahoo.com>]

Ulrich,

>>My obsevation.... Very well put request.  Id modify it to say:
>>
>>    "XML/XSP-->XSL(FO|T)"
>>
>
>Quite frankly, I am the biggest fan of XSP in the world (well, at least
>in this building :-)
>
>But I think not everyone is interested in it, so it should be seperate.
>Therefore I'd like to have one Block "XML/XSP-->XML" and one block
>"XML-->XSL(t|FO)".
>
Indeed.

>>Incidenatlly there would be a TCP/IP request, but (never fully answered)
>>how far does it leave the virtual machine in host-OS before it re-enters
>>the same VM for handling.
>>
>
>Where is there a TCP/IP request?
>
Err, are we not talking baout mounting Cocoon inside Jo inside Phoenix? 
 If yes, then API's for Cocoon are not directly accessible by other 
pheonix blocks.  This HTTP connections must still be made and the JVM 
implementaiton will faff around until it realises that the Socket is in 
VM rather than out of VM.  I could be wrong.

- Paul H


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Ulrich Mayring <ul...@denic.de>]

Paul Hammant wrote:
> 
> My obsevation.... Very well put request.  Id modify it to say:
> 
>     "XML/XSP-->XSL(FO|T)"

Quite frankly, I am the biggest fan of XSP in the world (well, at least
in this building :-)

But I think not everyone is interested in it, so it should be seperate.
Therefore I'd like to have one Block "XML/XSP-->XML" and one block
"XML-->XSL(t|FO)".

> >I could even run a HTTP/Servlet server
> >under Phoenix (e.g. Jo!) and have it use Cocoon's blocks for doing XML
> >stuff - no costly TCP connections to some servlet engine anymore.
> >
> Spooky.  Great minds think alike.  Err, promoting my mind perhaps ;-)
> 
> Incidenatlly there would be a TCP/IP request, but (never fully answered)
> how far does it leave the virtual machine in host-OS before it re-enters
> the same VM for handling.

Where is there a TCP/IP request?

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Paul Hammant <Pa...@yahoo.com>]

Ulrich,

>Here's a paragraph I just posted to cocoon-dev:
>
>95% of what I need is a block that does XML-->XSL(FO|T). I have many
>server-side apps, who would love to use this block. Why should they make
>a costly HTTP connection to some server that runs Cocoon and commit to
>the interfaces Cocoon prescribes? Wouldn't it be much cooler if I used
>the "XML-->XSL(FO|T)" block from Cocoon and keep everything within the
>framework and on the same JVM? 
>
My obsevation.... Very well put request.  Id modify it to say:

    "XML/XSP-->XSL(FO|T)"

>I could even run a HTTP/Servlet server
>under Phoenix (e.g. Jo!) and have it use Cocoon's blocks for doing XML
>stuff - no costly TCP connections to some servlet engine anymore.
>
Spooky.  Great minds think alike.  Err, promoting my mind perhaps ;-)

Incidenatlly there would be a TCP/IP request, but (never fully answered) 
how far does it leave the virtual machine in host-OS before it re-enters 
the same VM for handling.

Regards,

- Paul H




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Jo! & WAR file apps

[Ulrich Mayring <ul...@denic.de>]

Paul Hammant wrote:
> 
> Some of us were thinking that we could write some blocks for Cocoon to
> provide a generic Cocoon rendering component, but Jo! hosting the
> existing thing might be a useful way of having that functionality before
> a full block-ization.

Here's a paragraph I just posted to cocoon-dev:

95% of what I need is a block that does XML-->XSL(FO|T). I have many
server-side apps, who would love to use this block. Why should they make
a costly HTTP connection to some server that runs Cocoon and commit to
the interfaces Cocoon prescribes? Wouldn't it be much cooler if I used
the "XML-->XSL(FO|T)" block from Cocoon and keep everything within the
framework and on the same JVM? I could even run a HTTP/Servlet server
under Phoenix (e.g. Jo!) and have it use Cocoon's blocks for doing XML
stuff - no costly TCP connections to some servlet engine anymore.

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

AW: Jo! & WAR file apps

[Hendrik Schreiber <hs...@tagtraum.com>]

I have to admit, that I never tried it before, but cocoon 1.82 runs smoothly
:-)

-hendrik

> Hendrik,
>
> Does Jo! run Cocoon as a WAR app?
>
> It could be quite a cool way of getting Cocoon inside the Phoenix VM.
>  Actually, it might require some mods as it uses Excalibur, Framework &
> Logkit (sister projects to Phoenix) that are already in the classloader
> tree for Phoenix hosted apps.
>
> Some of us were thinking that we could write some blocks for Cocoon to
> provide a generic Cocoon rendering component, but Jo! hosting the
> existing thing might be a useful way of having that functionality before
> a full block-ization.
>
> Regards,
>
> - Paul H


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>