Re: Integrating Cocoon (was: Access to Application ClassLoader from a Block?)

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

On Sun, 25 Nov 2001, Paul Hammant wrote:

> Not answering your question (Pete has), but when you've finished can you 
> publish the code back to us?  We plan, sooner or later, to make a block 
> that publishes Cocoon services internally and this sounds very 
> close.........

I was planning something like that for a long time, too. When I asked on
cocoon-dev about the way to go the relevant people said that I should 
take care to not violate IoC and to not deconstruct Cocoon in a way that
would make it unrecognizable as a project of its own.

The majority of people, who spoke out on this issue, thought that I should
not call a Cocoon component from my other components, but that I should 
have Cocoon call my other components. This is to preserve IoC, a
"Cocoon block" would violate it, as it can be called from outside.

That would mean that I should not bypass, for example, the Sitemap to
access "inner services" directly. There should be only one entry-point
into a Cocoon component and it should, if possible, be the same one as in
a standard download of Cocoon. If we accept this as a given, then the
follow-up argument "have Cocoon call your other components" sounds
inevitable to me.

When I say "Cocoon" in this context I do not mean the current Cocoon, but
the Cocoon that will remain after the on-going integration of several of
its components into Avalon. When that work is done, the whole issue might
present itself very differently.

The original poster apparently thinks of integrating the current Cocoon
into Avalon - something which may have no future in the light of the
on-going migration of components from Cocoon to Avalon.

I have meanwhile started along a different path. The whole IoC argument as
I tried to represent it above, didn't fit well with our currently existing
applications, which are all running under Phoenix. So I've written "my own
stripped-down version of Cocoon", something I called an "XML-Block". It
currently does XSL(T|FO) and can render to all the output formats fop
supports (it uses fop, xerces and xalan internally). This is of course
just a small part of what Cocoon does, but for me it's better to start 
small and work my way up, instead of the other way round.

That means I'm not using any of Cocoon's code, I think it would be too
difficult to keep it synched with the Cocoon project, unless there was a
broad agreement on philosophy, IoC or otherwise. The beauty of OpenSource
is that I can do my own thing and nobody has to agree with me and I have
to agree with nobody :-)

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: Integrating Cocoon (was: Access to Application ClassLoader from a Block?)

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

On Mon, 26 Nov 2001 01:32, Uli Mayring wrote:
> I was planning something like that for a long time, too. When I asked on
> cocoon-dev about the way to go the relevant people said that I should
> take care to not violate IoC and to not deconstruct Cocoon in a way that
> would make it unrecognizable as a project of its own.

I don't think that was it. I think the idea was don't change Cocoon into 
something it is currently not and still call it Cocoon. I don't think there 
would be too much hubub if you created a new product that fit with your goals 
but didn't call it cocoon. You could call it something like "Butterfly, grown 
out of Cocoon" or something if you really wanted ;)

> The majority of people, who spoke out on this issue, thought that I should
> not call a Cocoon component from my other components, but that I should
> have Cocoon call my other components. This is to preserve IoC, a
> "Cocoon block" would violate it, as it can be called from outside.

A Cocoon block would not necessarily break IOC. Essentially Cocoon is 
architectured with a single container which contains a master controller. The 
master controller being the Sitemap. If you wanted alternative control 
mechanisms then I suspect you could replace the sitemap object. I am not sure 
how feasible this is at this stage (oe even if it is possible) but that is 
one way you could write your own control portion of the app. The cocoon 
people may even be receptive to that ;)

-- 
Cheers,

Pete

--------------------------------------------------
 Logic: The art of being wrong with confidence...
--------------------------------------------------

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

Re: Integrating Cocoon (was: Access to Application ClassLoader froma Block?)

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

Damn, I unsubscribed before reading this. Ok, taking care of it off list
(please, keep me copied)

Uli Mayring wrote:
> 
> On Sun, 25 Nov 2001, Michael McKibben wrote:
> 
> > Maybe I am missing something fundamental, but I don't see how using Cocoon
> > as a service violates IoC?
> 
> Well, I'm not the right person to answer this :)

I was the one who told Uli to be careful not to mess up IoC.
 
> > Cocoon naturally provides the Processor interface
> > as a service. The current CocoonServlet initializes the Cocoon component and
> > then delegates HTTP requests to the Cocoon Processor. My goal is to move the
> > initialization step to a block. 

This feature has been requested by many and I agree it's a good goal,
but I'm afraid you'd have to expose a bunch of internal Cocoon classes
to the outside in order for some block to call this block.

> > Then I would write a Servlet that looks up
> > the Processor and delegates the HTTP request ala CocoonServlet. Why do this?
> > Well, now I can deploy multiple wars in my Servlet container all using a
> > shared Cocoon component. 

Yes, I see this, or you could attach it to a Mailet to have your email
messages validated (could be useful for some B2B-over-SMTP
applications).

> > I could even use Cocoon from a MessageDriven EJB.
> > This is the idea anyways. Hopefully it works in practice.
> 
> If I understand you correctly, you still have a single entry-point (HTTP)
> and therefore I believe you don't violate IoC.

It doesn't have to be HTTP, but yes, it's a single entry-point and
doesn't violate IoC.
 
> > I believe the advice given to you by cocoon-dev was to not call
> > sub-components of Cocoon (i.e. components defined in cocoon.xconf and the
> > sitemap.) Of course you have to call into the Cocoon Processor, otherwise,
> > how would you use it! Requests have to get passed into Cocoon somehow :)
> 
> My idea was to have better granularity at the service level, not just one
> big "Cocoon service", so every application that needs parts of Cocoon's
> functionality can simply get a hold of the specific blocks it needs.

Once Carsten moves Cocoon's general XML components into avalon, you can
easily obtain this.
 
> Going over HTTP means you need a webserver, a document repository at
> the webserver's location and a (potentially costly) HTTP connection every
> time you have a request, plus you need to go through the whole processing
> pipeline every time, even if you know from the start where you want to go.

This is not what I perceived he wants to do.

> Instead, since my applications run under Phoenix anyway, I could use the
> functionality directly, if it were available in Phoenix-friendly form,
> e.g. as a block.

> Anyway, one argument in the discussion was that for such simple tasks I
> should write a wrapper around Xalan or fop and not use Cocoon at all,
> because it is meant for more complex processing. So that is the route I'm
> going at the moment, even though I believe my system will become more
> complex with time, too. Also I need Cocoon for the frontend anyway, so
> there's some duplication of efforts. It would be better if I could use the
> same Cocoon engine in my backend apps and in the browser-based frontend.
> Well, you're never too old to learn, so perhaps one of these days I see
> the light :)

The Cocoon engine is already decoupled from the servlet code. There is
nothing Servlet-based inside Cocoon, the entire Environment was
abstracted to allow command line interface. Making Cocoon.class an
avalon block is piece of cake and it removes the need for setting up the
HTTP request, as you are asking.

This is what has been proposed in this thread.

And this doesn't violate IoC, even if it needs to expose a bunch of
Cocoon classes in the block interface so it might turn out to be a
complex service to call as a block, but it's indeed possible and useful
in some special cases.

Moreover, once the general Cocoon components are moved into Avalon, you
have the ability to do both: call Cocoon as a block without having to go
thru HTTP or use the XML functionalities Cocoon builds upon to power
your own avalon-aware logic.

Hope this 'finally' shades some light on this.

-- 
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: Integrating Cocoon (was: Access to Application ClassLoader from a Block?)

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

On Sun, 25 Nov 2001, Michael McKibben wrote:

> Maybe I am missing something fundamental, but I don't see how using Cocoon
> as a service violates IoC?

Well, I'm not the right person to answer this :)

> Cocoon naturally provides the Processor interface
> as a service. The current CocoonServlet initializes the Cocoon component and
> then delegates HTTP requests to the Cocoon Processor. My goal is to move the
> initialization step to a block. Then I would write a Servlet that looks up
> the Processor and delegates the HTTP request ala CocoonServlet. Why do this?
> Well, now I can deploy multiple wars in my Servlet container all using a
> shared Cocoon component. I could even use Cocoon from a MessageDriven EJB.
> This is the idea anyways. Hopefully it works in practice.

If I understand you correctly, you still have a single entry-point (HTTP) 
and therefore I believe you don't violate IoC.

> I believe the advice given to you by cocoon-dev was to not call
> sub-components of Cocoon (i.e. components defined in cocoon.xconf and the
> sitemap.) Of course you have to call into the Cocoon Processor, otherwise,
> how would you use it! Requests have to get passed into Cocoon somehow :)

My idea was to have better granularity at the service level, not just one
big "Cocoon service", so every application that needs parts of Cocoon's
functionality can simply get a hold of the specific blocks it needs.

Going over HTTP means you need a webserver, a document repository at
the webserver's location and a (potentially costly) HTTP connection every
time you have a request, plus you need to go through the whole processing 
pipeline every time, even if you know from the start where you want to go.
Instead, since my applications run under Phoenix anyway, I could use the
functionality directly, if it were available in Phoenix-friendly form,
e.g. as a block.

Anyway, one argument in the discussion was that for such simple tasks I
should write a wrapper around Xalan or fop and not use Cocoon at all,
because it is meant for more complex processing. So that is the route I'm
going at the moment, even though I believe my system will become more
complex with time, too. Also I need Cocoon for the frontend anyway, so
there's some duplication of efforts. It would be better if I could use the
same Cocoon engine in my backend apps and in the browser-based frontend.
Well, you're never too old to learn, so perhaps one of these days I see
the light :)

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung


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

RE: Integrating Cocoon (was: Access to Application ClassLoader from a Block?)

[Michael McKibben <mi...@hihat.net>]

Maybe I am missing something fundamental, but I don't see how using Cocoon
as a service violates IoC? Cocoon naturally provides the Processor interface
as a service. The current CocoonServlet initializes the Cocoon component and
then delegates HTTP requests to the Cocoon Processor. My goal is to move the
initialization step to a block. Then I would write a Servlet that looks up
the Processor and delegates the HTTP request ala CocoonServlet. Why do this?
Well, now I can deploy multiple wars in my Servlet container all using a
shared Cocoon component. I could even use Cocoon from a MessageDriven EJB.
This is the idea anyways. Hopefully it works in practice.

I believe the advice given to you by cocoon-dev was to not call
sub-components of Cocoon (i.e. components defined in cocoon.xconf and the
sitemap.) Of course you have to call into the Cocoon Processor, otherwise,
how would you use it! Requests have to get passed into Cocoon somehow :)

I would be glad to donate the Cocoon block and servlet back to this project.
I'm sure it won't be perfect, and having a community of developers review it
can only make it better. I expect to have something workable in the next few
days.

Regards,

--mike

-----Original Message-----
From: Uli Mayring [mailto:ulim@denic.de]
Sent: Sunday, November 25, 2001 7:32 AM
To: Avalon Developers List
Subject: Re: Integrating Cocoon (was: Access to Application ClassLoader
from a Block?)


On Sun, 25 Nov 2001, Paul Hammant wrote:

> Not answering your question (Pete has), but when you've finished can you
> publish the code back to us?  We plan, sooner or later, to make a block
> that publishes Cocoon services internally and this sounds very
> close.........

I was planning something like that for a long time, too. When I asked on
cocoon-dev about the way to go the relevant people said that I should
take care to not violate IoC and to not deconstruct Cocoon in a way that
would make it unrecognizable as a project of its own.

The majority of people, who spoke out on this issue, thought that I should
not call a Cocoon component from my other components, but that I should
have Cocoon call my other components. This is to preserve IoC, a
"Cocoon block" would violate it, as it can be called from outside.

That would mean that I should not bypass, for example, the Sitemap to
access "inner services" directly. There should be only one entry-point
into a Cocoon component and it should, if possible, be the same one as in
a standard download of Cocoon. If we accept this as a given, then the
follow-up argument "have Cocoon call your other components" sounds
inevitable to me.

When I say "Cocoon" in this context I do not mean the current Cocoon, but
the Cocoon that will remain after the on-going integration of several of
its components into Avalon. When that work is done, the whole issue might
present itself very differently.

The original poster apparently thinks of integrating the current Cocoon
into Avalon - something which may have no future in the light of the
on-going migration of components from Cocoon to Avalon.

I have meanwhile started along a different path. The whole IoC argument as
I tried to represent it above, didn't fit well with our currently existing
applications, which are all running under Phoenix. So I've written "my own
stripped-down version of Cocoon", something I called an "XML-Block". It
currently does XSL(T|FO) and can render to all the output formats fop
supports (it uses fop, xerces and xalan internally). This is of course
just a small part of what Cocoon does, but for me it's better to start
small and work my way up, instead of the other way round.

That means I'm not using any of Cocoon's code, I think it would be too
difficult to keep it synched with the Cocoon project, unless there was a
broad agreement on philosophy, IoC or otherwise. The beauty of OpenSource
is that I can do my own thing and nobody has to agree with me and I have
to agree with nobody :-)

cheers,

Ulrich

--
Ulrich Mayring
DENIC eG, Softwareentwicklung


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


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