cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Jo! & WAR file apps
Date Tue, 06 Nov 2001 12:06:45 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

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


Mime
View raw message