You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/02/26 21:34:30 UTC
Re: [RT] Cocoon and web applications
Stefano Mazzocchi wrote:
>
> First of all, sorry for the major crosspost but I believe that it would
> be extremely beneficial for everybody (heck, we are all parts of Apache
> communities after all!) to discuss ways to integrate, avoid overlap and
> reduce duplication of effort.
agree.
> The only thing that needs to be addressed is web application support,
> which is likely to overlap with existing solutions in the Apache world.
Cocoon does have the beginnings of this support, but it is not documented
well, or (possibly) not fully thought out.
> In the last few weeks, I evaluated almost all existing web technologies
> (ranging from Perl to PHP, ASP to JSP, Turbine to Struct) and I believe
> that the design concepts Cocoon is based on are *almost* orthogonal to
> the design concepts that web-app frameworks are based on.
Ok. I can buy that. Since Web Applications are what I do, I agree to
this point. I prefer the clean separation between form handling and
form display.
> Why so? Well, Cocoon is totally agnostic on how content is generated.
> Cocoon provides an abstraction following the IoC pattern (IoC =
> Inversion of Control), just like the Servlet API. Turbine does the same
> with screens. Struct does the same with JSP as views.
>
> A question can be posed: where does Cocoon stand in the model1/model2
> concept? nowhere! It's just like a servlet engine: it's up to you to
> write the generator!
Another possibility is to use Turbine to aggregate separate serialized
Cocoon streams....
> Cocoon provides a huge amount of machinery to
> adapt/transform/change/serialize/mount/map/match in order to eliminate
> the need for you, generator writer, about these things.
Having worked on it in depth, I can tell you that the machinery is
well-oiled with one exception: Cocoon 2 XSP generation is curiously
slow. I am still looking into it to figure out why, but everything
else is blazingly fast.
> This said, it is obvious that frameworks that reside at "generation
> stage" cannot call the container without breaking inversion of control.
> It's much like the old getServlet() method that was deprecated from the
> Servlet API.
I agree.
> Ok, you say, but why is this different from the Servlet API 2.3
> Filtering support? Why isn't Cocoon part of Tomcat directly?
Well filters are great for invisible form handling (theorhetically).
> Let's find out where the overlap is:
>
> 1) turbine is both a framework for web applications and a collection of
> services. This doesn't overlap with Cocoon directly, rather with Avalon,
> which is intended to be a framework for componentized serving
> applications, thus is able to perform the same service functionalities
> that Turbine does, with a few more capabilities (like component
> versioning, dynamic componentization and the like).
>
> It would be extremely cool to factor out turbine services into avalon
> components since:
>
> a) it would provide more 'meat' for the avalon component pool
> b) remove duplication (Avalon contains a few services that overlap with
> Turbine functionality, clearly a nonsense since they belong to the very
> same community of developers!)
> c) increase productivity and visibility of both projects by unifying
> the noosphere.
> d) increase functionality (ever thought of mail-applications? turbine
> as a Mailet? you should since JAMES is built on Avalon and provides
> almost all messaging needs including POP3/IMAP4 support!)
I would keep them as part of Turbine, but simply letting them take
advantage of Cocoon Components and Configurations will help give real
feedback on how to make Avalon more usable, and provide the facilities
to Cocoon--as long as the Roles are well defined.
> Is there a reason to maintain Turbine separated from Avalon? I honestly
> don't know, so I'm asking you. On the "well, we don't know what this
> means" side, I'm sure there will be tons of people willing to help from
> both the Avalon and Cocoon project for such a refactoring to take place.
Yes. Avalon is a generic framework, Turbine is a specific framework. There
is nothing that says that Turbine can't be built on Avalon, nor is there
anything that says that pieces of Turbine could be included in Avalon.
It depends on what the facility is.
> 2) turbine as a framework doesn't overlap with Cocoon since Cocoon
> doesn't care on how you end up generating your content. All the concepts
> such as model2, model2+1, MVC, pushMVC, pullMVC, HMVC, etc.. all concern
> the generation stage.
>
> The only overlap between Cocoon and Turbine is XSP, which is our
> solution to custom generator creation.
>
> XSP 1.0 is a model 1 solution tuned for XML: I fully agree with Jon when
> he states that XSP is nothing different from JSP in many situations
> where lots of logic must be present.
XSP is really nice, but there are some aspects I would like to see
improve. Since this isn't the forum for that, I will leave the details
out--I need to formulate what I *really* want vs. stream of consciousness
rambling anyways.
> In fact, evidence in the Cocoon user community clearly shows that XSP
> are great for publishing (that is HTTP GET actions only!), but rather
> painful for web applications (where POST and GET actions mix). The
> reason? XSP 1.0 were not designed with MVC in mind, but to allow easy
> generation of dynamic pages to be published.
Here, Here! One thing I liked about ColdFusion (general mayhem ensues)
was that it was easy to separate Pure content and Pure logic sheets
with a simple relocation between them. However, due to some bad experiences
with ColdFusion and the differences in the way some Web Servers handle
(or mishandle) relocation, it was not a real solution for me.
My introduction to Cocoon, and I was hooked. I had a template displaying
how to reformulate the existing webapp into a Cocoon webapp shortly followed.
It quickly became apparent to me that in the Cocoon 1 framework, there
was no way to separate these concerns. This is frustrating because SoC
(Separation of Concerns) is one of the founding patterns used in Cocoon
and Avalon.
With the Action framework introduced in Cocoon 2, I have the best of both
worlds--although it could be made easier to use.
> In the past, Cocoon design was criticized for some XSP design holes, I
> would like to enphasize that this is equivalent of criticizing the
> Servlet API design for some JSP design faults. Even more: unlike the
> Servlet API/JSP, great care was taken in both making Cocoon completely
> generation agnostic (the XSP component is itself a generator!) as well
> as configuration semantics (unlike the Servlet API deployment
> descriptors).
>
> XSP have been proven extremely valid for publishing needs, it doesn't
> fit for web-apps, at least not in its current shape.
>
> What to do?
>
> Well, there are several alternatives:
>
> 1) add MVC strategies in XSP
This has promise, although I would have to give some time to research
the Turbine MVC patterns. There is alot that could be learned here.
> 2) turn Turbine into a generator and use directly Turbine stragegies
Again, I have to research what Turbine strategies will afford me, and
how they would be integrated
> 3) factor out Turbine strategies and make Cocoon components out of this.
This is relatively easy to do, though it has the most impact on Turbine.
Again, I don't know a whole lot about Turbine.
> 4) ???
Actions. Actions are unique to the Cocoon 2 framework in that they allow
for two distinct advantages: They allow you to talk directly to the
sitemap to control flow (based on administrator settings), and they allow
you to perform invisible form handling without using clumsy relocation
semantics.
They are currently very specific to Cocoon, but seeing as they are
Cocoon Components (and Avalon Components by extension), they provide
most of the functionality that is missing in the Cocoon Webapp sphere.
What would be possible is an Turbine StrategyWrapper in the form of
an Action. It would allow Cocoon to seamlessly use already developed
Turbine Strategies, as well as even the burden of development between
the two projects.
> I honestly don't know which out is the best for everybody: refactoring
> Turbine into Cocoon components and Avalon components might tear the
> project's identity apart and I don't this this is useful. There must be
> a project focused on the development of web-app specific guidelines and
> paradigms, neither Cocoon nor Avalon can do this as effectively.
+10000. However, that project can't be ignorant of either Avalon or
Cocoon--just as the others should not be ignorant of Turbine or even
Struts. I must admit that I am guilty of this, and should look at how
the projects can work together better. It is important to look at the
same problem from different viewpoints.
Avalon provides a framework and a view from the nuts and bolts side of
things: more of a structural view.
Cocoon provides a publishing framework and a view from URL contract
management (sitemap) and publishing.
Turbine as I understand it provides a view of WebApp organization
and building. I haven't found ANY documentation on this other than
API docs--at least that I can browse on the web.
> On the other hand, once Cocoon2 and Avalon API stabilize, making Turbine
> a Cocoon-based and Avalon-aware web-app sub-framework makes perfect
> sense to me: it gives the 'turbo boost' for web-apps that neither Cocoon
> nor Avalon alone can provide.
The APIs are fairly close to stable... Cocoon 2 will most likely add
some components, but other than that, the overall API has been pretty
solid for a few weeks.
> Ok, you might ask: this requires users to install yet another thing down
> below and what for?
>
> Well, there are a few things you get for free: caching and content
> aggregation, for example, advanced publishing capabilities become
> available transparently and your web-app can almost instantly be turned
> into a WAP-app by simply changing the stylesheets that transform the
> content.
If the end result is reduced time to market, then I am all for it.
> Ah, I forgot: another critique that was moved against Cocoon was the
> fact that XSLT is a difficult language and many don't like to be forced
> to use it and like their own solutions better.
XSLT is a pain in the butt. That aside, there are ways you can convert
a regular HTML mockup into a "skin" for aggregated markup.
> Well, just like we did for generation, even transformation is totally
> language-agnostic: it is entirely possible to drive a transformation
> process either directly (I mean: you write the java code that performs
> the transformation) or interpreting a transformation language of some
> sort (in that case, you have to write the interpreter). It is entirely
> possible to use Anakia's velocity-based procedural transformation
> language instead of declarative XSLT which some find less readable.
There will be serious advantages for SAX based alternatives than something
that requires a discrete transformation step. In other words, If you have
to cache all the SAX events before transformation, then you are creating
a performance issue--especially with large documents.
> Again, even if Cocoon ships with an XSLT-based transformer, the overlapp
> architecture was designed to avoid lock-in even for open standards and
> allow you to personalize the component pipeline generation to the
> granularity you want.
I have found that using hand crafted Transformers will out perform XSP
right now. This is unfortunate, but won't be long lived.
> Another critique was the concept MVC is powerful enough to avoid the
> need for transformation. That is: the controller can choose different
> views depending on runtime parameters.
In some ways absolutely. However, Cocoon will allow you to use ephemeral
Models. By this I mean SQL ResultSets, [Enterprise] JavaBeans, and other
proprietary models. When filtering is done at the Generation stage,
we have a very good bet on not wasting resources.
That is way XSP *uses* those models. If there is a way to use Turbine
Models in the Generation stage, we could have yet another integration
point.
> This is a very powerful concept indeed: it is utterly inefficient to
> generate a complex view of all the data contained in the model only to
> 'filter them out' at transformation stage. Here, the MVC model is
> clearly a winner.
This is overkill in anyones book. That is why XSP and custom generators
use existing models of Data, and only generate the portion needed at the
time.
> But, IMO, it is limiting to assume that since presentation can be
> decided at generation stage, it is optimal to do so.
Mixing presentation concerns and data models is IMO a bad thing. That
is why I would create a model of say an Advertisement that can be
represented in XML. I have the ability to transform my view (presentation/
transformation) into what I want and send it to the user (Serialization).
> It is totally possible to concieve a system where both view choice and
> transformation reduce overall maintenance costs. For example: views are
> choosen as 'layouts' and trasformations as 'skins'. Why? because they
> are two different graphical concerns:
>
> 1) where to place information / how to design the UI
I do this in one Transformation layer in Cocoon
> 2) how to present it
I do this in another Transformation layer in Cocoon.
> the use of different views allow you to have different layouts and
> different presentations, but if you have m layouts and n styles, you end
> up requiring n*m views while with transformations you would only need m
> views and n styles.
Already possible with Cocoon, but definitely could be optimized a bit.
> It also takes into consideration the fact that normally UI designers and
> graphic designers are different people with different skills: MVC forces
> them to work together only because both happen to impact on the
> 'presentation' of the information, even if with different aspects.
I definitely agree here. I worked on a Workflow system where the layout
was designed by Developers (with no sense of style or placement). My first
task was to retrofit the existing app with the Graphic designer's idea of
how the WebApp should look. After I was done, the app had style, but wasn't
very usable. I took my team of two, and we went through the feedback from
our customer. We identified some common structures of how to layout an
Inbox oriented Workflow that really worked for our customer. Again with
the retrofitting.
This retrofitting required altering over 200 templates, and it was HTML
mixed with the logical markup. Now you can see why I am heavily biased
toward Cocoon. It fills a serious need we have in the way we work at my
company. The graphic artist is usually contracted too late, and then the
rework ensues. With Cocoon as my publishing engine, I can change the look
of my entire webapp in one file--this is invaluable. I can also change
the overall layout with a second file.
I typically stick with traditional data models, using Cocoon as my View
layer--and now with Actions, my Controller as well.
Now, I am very willing to entertain how Turbine in the mix could assist
me as well.
> 1) Cocoon and Turbine don't overlap but the assumption that Cocoon can
> be called by Turbine as a screen is misleading and ruining the design
> concepts that Cocoon was based on. This is, to me, the reason why nobody
> was able to integrate Turbine and Cocoon elegantly up to date (see
> Jetspeed).
Integration is a difficult issue on many levels, but I would need better
understanding of the specific problem domain in order to come up with
good solutions.
> 2) I explained why an XML web applications can use both Cocoon and
> Turbine functionality only if Turbine is contained by Cocoon and not the
> other way around.
I think this is the proper approach. Imagine if you will a Turbine
Generator and a Jetspeed Aggregator all stylized by Cocoon. I think
that would be Really cool--because now I am working on a "portal" of
sorts.
Right now, it is more painful to do what I need, but I can't take the
risk that the site won't be restyled later.
> 4) I explained how many of the critiques that were moved against Cocoon
> were in fact against technologies that Cocoon was using to implement
> some of its components. No critique, so far, has mined Cocoon's core
> design concepts.
Where have you heard these critiques. Everything I have read has been
pretty much pro-Cocoon. I mean Cocoon really excites the imagination
of what can be done. When you marry it with other less glamerous projects
the result is a net boon for all projects involved. It brings more
users to the table for all of the technologies involved.
> 5) I explained how the use of both Cocoon and Turbine functionalities
> can be useful to reduce costs for web-app generation and provide great
> synergy between the two communities that can exchange information and
> design guidelines to improve both sides of the fence.
I like the prospect of this. Is there any other methods besides Turbine
Generators and Actions?
AW: [C2]: Problems with Actions and Parameters
Posted by Carsten Ziegeler <cz...@sundn.de>.
> Berin Loritsch wrote:
>
> Ok. I got it fixed, and applied it to the sitemap in the distro.
> It even makes the action-set reusable in many places. This is
> awesome stuff.
>
Great, it works again. Thanks Berin
Carsten
> >
> > Carsten Ziegeler wrote:
> > >
> > > Hi,
> > >
> > > when I use action and parameters in this way:
> > >
> > > <map:match pattern="forms/employee">
> > > <map:act set="employee">
> > > <parameter name="hallo" value="value"/>
> > >
> > > <map:generate type="serverpages" src
> ="docs/samples/forms/employee.xsp"/>
> > > <map:transform src="stylesheets/dynamic-page2html.xsl"/>
> > > <map:serialize/>
> > > </map:act>
> > > </map:match>
> >
> > Unless you are using objectMap variables, this is not necessary anyways.
> >
> > > the generated java code is not compilable:
> > >
> > > param = new Parameters ();
> > > param.setParameter ("hallo", substitute(listOfMaps, "value"));
> > >
> > > if ((map = action_set_employee (cocoon_action, listOfMaps,
> > > environment, objectModel,
> > > substitute(listOfMaps, null),
> param)) != null) {
> > > getLogger().debug("Action action_set_employee");
> > > listOfMaps.add (map);
> > >
> > > .setParameter ("hallo", substitute(listOfMaps, "value"));
> >
> > That is a problem. This is probably a side affect of the change I made
> to key the
> > param value off of an xsl:param. I can change the code so that if the
> parameter
> > is not set, then it won't output the call anyway.
> >
> > > The parameter is processed twice! If the map:generate etc. is used
> outside the map:act the generated code is ok:
> > > <map:act set="employee">
> > > <parameter name="hallo" value="value"/>
> > > </map:act>
> > > <map:generate type="serverpages" src
> ="docs/samples/forms/employee.xsp"/>
> > > <map:transform src="stylesheets/dynamic-page2html.xsl"/>
> > > <map:serialize/>
> > >
> > > I search through the sitemap.xsl for the reason but I think it will
> take me some days to find the problem.
> >
> > Is it being called instead of applied? Let me apply my change, and it
> will get rid of _any_ instance where
> > the parameter is not set.
> >
> > ---------------------------------------------------------------------
> > 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: [C2]: Problems with Actions and Parameters
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
Ok. I got it fixed, and applied it to the sitemap in the distro.
It even makes the action-set reusable in many places. This is
awesome stuff.
>
> Carsten Ziegeler wrote:
> >
> > Hi,
> >
> > when I use action and parameters in this way:
> >
> > <map:match pattern="forms/employee">
> > <map:act set="employee">
> > <parameter name="hallo" value="value"/>
> >
> > <map:generate type="serverpages" src="docs/samples/forms/employee.xsp"/>
> > <map:transform src="stylesheets/dynamic-page2html.xsl"/>
> > <map:serialize/>
> > </map:act>
> > </map:match>
>
> Unless you are using objectMap variables, this is not necessary anyways.
>
> > the generated java code is not compilable:
> >
> > param = new Parameters ();
> > param.setParameter ("hallo", substitute(listOfMaps, "value"));
> >
> > if ((map = action_set_employee (cocoon_action, listOfMaps,
> > environment, objectModel,
> > substitute(listOfMaps, null), param)) != null) {
> > getLogger().debug("Action action_set_employee");
> > listOfMaps.add (map);
> >
> > .setParameter ("hallo", substitute(listOfMaps, "value"));
>
> That is a problem. This is probably a side affect of the change I made to key the
> param value off of an xsl:param. I can change the code so that if the parameter
> is not set, then it won't output the call anyway.
>
> > The parameter is processed twice! If the map:generate etc. is used outside the map:act the generated code is ok:
> > <map:act set="employee">
> > <parameter name="hallo" value="value"/>
> > </map:act>
> > <map:generate type="serverpages" src="docs/samples/forms/employee.xsp"/>
> > <map:transform src="stylesheets/dynamic-page2html.xsl"/>
> > <map:serialize/>
> >
> > I search through the sitemap.xsl for the reason but I think it will take me some days to find the problem.
>
> Is it being called instead of applied? Let me apply my change, and it will get rid of _any_ instance where
> the parameter is not set.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [C2]: Problems with Actions and Parameters
Posted by Berin Loritsch <bl...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi,
>
> when I use action and parameters in this way:
>
> <map:match pattern="forms/employee">
> <map:act set="employee">
> <parameter name="hallo" value="value"/>
>
> <map:generate type="serverpages" src="docs/samples/forms/employee.xsp"/>
> <map:transform src="stylesheets/dynamic-page2html.xsl"/>
> <map:serialize/>
> </map:act>
> </map:match>
Unless you are using objectMap variables, this is not necessary anyways.
> the generated java code is not compilable:
>
> param = new Parameters ();
> param.setParameter ("hallo", substitute(listOfMaps, "value"));
>
> if ((map = action_set_employee (cocoon_action, listOfMaps,
> environment, objectModel,
> substitute(listOfMaps, null), param)) != null) {
> getLogger().debug("Action action_set_employee");
> listOfMaps.add (map);
>
> .setParameter ("hallo", substitute(listOfMaps, "value"));
That is a problem. This is probably a side affect of the change I made to key the
param value off of an xsl:param. I can change the code so that if the parameter
is not set, then it won't output the call anyway.
> The parameter is processed twice! If the map:generate etc. is used outside the map:act the generated code is ok:
> <map:act set="employee">
> <parameter name="hallo" value="value"/>
> </map:act>
> <map:generate type="serverpages" src="docs/samples/forms/employee.xsp"/>
> <map:transform src="stylesheets/dynamic-page2html.xsl"/>
> <map:serialize/>
>
> I search through the sitemap.xsl for the reason but I think it will take me some days to find the problem.
Is it being called instead of applied? Let me apply my change, and it will get rid of _any_ instance where
the parameter is not set.
[C2]: Problems with Actions and Parameters
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi,
when I use action and parameters in this way:
<map:match pattern="forms/employee">
<map:act set="employee">
<parameter name="hallo" value="value"/>
<map:generate type="serverpages" src="docs/samples/forms/employee.xsp"/>
<map:transform src="stylesheets/dynamic-page2html.xsl"/>
<map:serialize/>
</map:act>
</map:match>
the generated java code is not compilable:
param = new Parameters ();
param.setParameter ("hallo", substitute(listOfMaps, "value"));
if ((map = action_set_employee (cocoon_action, listOfMaps,
environment, objectModel,
substitute(listOfMaps, null), param)) != null) {
getLogger().debug("Action action_set_employee");
listOfMaps.add (map);
.setParameter ("hallo", substitute(listOfMaps, "value"));
The parameter is processed twice! If the map:generate etc. is used outside the map:act the generated code is ok:
<map:act set="employee">
<parameter name="hallo" value="value"/>
</map:act>
<map:generate type="serverpages" src="docs/samples/forms/employee.xsp"/>
<map:transform src="stylesheets/dynamic-page2html.xsl"/>
<map:serialize/>
I search through the sitemap.xsl for the reason but I think it will take me some days to find the problem.
Any hints or ideas?
Carsten
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
AW: [C2]: BUG in current version
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hey great !
With the latest checkin, upgrading to the latest cvs Xalan and Xerces-1.3.0 the problem seems to have disappeared.
I will proove this further.
Thanks, dims.
Carsten
> -----Ursprungliche Nachricht-----
> Von: Carsten Ziegeler [mailto:cziegeler@sundn.de]
> Gesendet: Mittwoch, 28. Februar 2001 14:09
> An: cocoon-dev@xml.apache.org
> Betreff: [C2]: BUG in current version
>
>
>
> Hi,
>
> after some research with the current cvs version of C2 I found a real bug:
>
> If the TraxTransformer is not used inside a pipeline, a NPE is thrown
> inside the setDocumentLocator method of the
> org.apache.xalan.transformer.TransformerIdentityImpl class (line 823).
> (This is at least true if the html, text or xml serializer is used).
>
> You can easily reproduce this, by removing e.g. the <map:transform src
> ="stylesheets/simple-samples2html.xsl"/> from the welcome pipeline.
>
> This bug might be introduced with the removing of the dependecies to the
> org.apache.xml.serialize package?
>
> Any hints how to fix this ?
>
>
> Regards
> Carsten Ziegeler
>
> Open Source Group sunShine - Lighting up e:Business
> ================================================================
> Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
> www.sundn.de mailto:cziegeler@sundn.de
> ================================================================
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
[C2]: BUG in current version
Posted by Carsten Ziegeler <cz...@sundn.de>.
Hi,
after some research with the current cvs version of C2 I found a real bug:
If the TraxTransformer is not used inside a pipeline, a NPE is thrown inside the setDocumentLocator method of the org.apache.xalan.transformer.TransformerIdentityImpl class (line 823). (This is at least true if the html, text or xml serializer is used).
You can easily reproduce this, by removing e.g. the <map:transform src="stylesheets/simple-samples2html.xsl"/> from the welcome pipeline.
This bug might be introduced with the removing of the dependecies to the org.apache.xml.serialize package?
Any hints how to fix this ?
Regards
Carsten Ziegeler
Open Source Group sunShine - Lighting up e:Business
================================================================
Carsten Ziegeler, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
www.sundn.de mailto:cziegeler@sundn.de
================================================================
Re: [RT] Cocoon and web applications
Posted by Peter Donald <do...@apache.org>.
Hi,
I missed the start of this thread but I am going to throw in my two-pence ;)
As a Avalon dev I would have to say that I wouldn't recomend any one from
another project that is as highly evolving as turbine to integrate Avalon
at this stage (unless of course it was someone who was willing to keep up
with Avalon). Avalon is slowly converging to a stable point but we aren't
there yet and consequently there is no guarentees ;)
BTW when I say Avalon in this thread I am talking about the "framework"
part of Avalon.
At 09:07 26/2/01 -0800, Federico Barbieri wrote:
>> > Turbine is a specific framework. There
>> > is nothing that says that Turbine can't be built on Avalon, nor is there
>> > anything that says that pieces of Turbine could be included in Avalon.
>>
>> Yes there is. The fact that it would end up breaking a lot of people's code
>> and the fact that the configuration is entirely different between Turbine
>> and Avalon. Those are two MAJOR issues that no one here likes to even think
>> about. People just like to say that it can be done...but in reality, it
>> can't unless you want to also upset a lot of people.
Backwards compatability is definetly desirable but as Fede saids - if you
don't want XML configs due to incompatability then don't use it ;) Or
better yet slowly migrate ;)
>My best reward whould be to see cocoon action pattern formalized and
>placed here.
I would object to it ;)
Don't take this wrong but I don't think Cocoon has the best Action
proposal. It didn't (last time I checked) deal with a lot of things I would
want to see in an action framework. It doesn't differentiate between all
different action routing models or difference between explicit/implicit and
push vs pull actions. I am not saying turbine is perfect either as it also
doesn't deal with implicit/pull actions.
Personally I see turbine/struts/cocoon as good/great for what they do but
not perfect. You may want to have a look at a few other projects to see how
they do things. IIRC there is a project Stones or Rocks from enhydra that
implements brilliant action chain building - and there is qubes that has a
nice quilting of actions.
Even if such a perfect model was found/built it still probably belongs in
turbine unless there was a use for it in other server environments.
>> Solve those problems and I would be more than happy to have Turbine use
>> Avalon where it makes sense (I have been saying that for years now).
>> However, the fact of the matter is that I don't see it happening unless
>> someone steps up to make it happen. Of course I wouldn't -1 it, but I sure
>> am not going to do it. What I have works just fine now and Avalon isn't my
>> itch. I don't need blocks, I don't need stuff componentized into a
bazillion
>> pieces. I just need a web app framework.
A volunteer would be great but unless they were following and at least
vocal if not active on Avalon then it could be hell for them. Personally I
would prefer to wait till there is a stable Avalon and then if no one else
steps up I will help turbine use Avalon if thats what the turbine community
wants.
>> > This has promise, although I would have to give some time to research
>> > the Turbine MVC patterns. There is alot that could be learned here.
>>
>> Nice to hear you say that given that the Action framework you just talked
>> about in Cocoon 2 is essentially something that was invented at least 4
>> years ago (even before Turbine existed) by my friend Leon Atkinson and was
>> done first in PHP!
uhhh ... hello ? He did NOT invent the Action pattern. It has been around
for ages in GUI space and before that it came from simulation field. It was
originally an extention to event simulation IIRC and that has been around
for how long ? ;)
>>I find it humorous that this same Action framework is
>> also in Struts as well. More re-invention of the wheel because no one
>> bothers to look at Turbine first or people claim that Turbine isn't J2EE so
>> they don't want to use it. Duh. How lame.
One thing I would love to see (but have never mentioned it before because I
am not prepared to do the work ;]) is to see turbine segregated a bit more
- in a similar way to what Avalon has just gone through.
I would love to be able to use the page/action layer or the persistence
layer or maybe texen or maybe X or Y etc. At this stage it is just too much
effort. I suspect many people are just like me - incredibly lazy ;) and
thus will prefer to reinvent the wheel rather than keep up with turbine.
Alternatively they will fork turbine and just work of the fork.
I don't pretend to understand turbine as well as I used to but I suspect
there is various products that could be extracted out into separate
products. Do this and I am sure that you will get more developers adopt it.
I was told not so long ago it is better to tie many cotton lines than one
rope when integrating things together. ie Offer them a little and hope to
get them "addicted" to turbine and keep providing and they will keep coming
back and probably convert to your thinking ;) However say that it is the
turbine way or the highway and they will never pick it up at the begining ;)
>This is been said so many times... this happend becouse it's way easier
>and faster to reinvent the weel than dig into turbine. No matter that
>turbine is well designed and documented.
>I know this is true right now but I don't like it. The best solution I
>can think about is to spend some more effort to get turbine and cocoon
>closer where it's possible so that developers from both sides will find
>easier to dig in the other project.
Well said !
That said I do think that in the future that it would be very beneficial to
integrate Avalon and Turbine. I would hope that most of web/servlet
specific components were pushed into Turbine and kept out of Avalon though.
Of course this has to wait till Avalon stabilizes more so back I go to
hacking ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [RT] Cocoon and web applications
Posted by Peter Donald <do...@apache.org>.
Hi,
I missed the start of this thread but I am going to throw in my two-pence ;)
As a Avalon dev I would have to say that I wouldn't recomend any one from
another project that is as highly evolving as turbine to integrate Avalon
at this stage (unless of course it was someone who was willing to keep up
with Avalon). Avalon is slowly converging to a stable point but we aren't
there yet and consequently there is no guarentees ;)
BTW when I say Avalon in this thread I am talking about the "framework"
part of Avalon.
At 09:07 26/2/01 -0800, Federico Barbieri wrote:
>> > Turbine is a specific framework. There
>> > is nothing that says that Turbine can't be built on Avalon, nor is there
>> > anything that says that pieces of Turbine could be included in Avalon.
>>
>> Yes there is. The fact that it would end up breaking a lot of people's code
>> and the fact that the configuration is entirely different between Turbine
>> and Avalon. Those are two MAJOR issues that no one here likes to even think
>> about. People just like to say that it can be done...but in reality, it
>> can't unless you want to also upset a lot of people.
Backwards compatability is definetly desirable but as Fede saids - if you
don't want XML configs due to incompatability then don't use it ;) Or
better yet slowly migrate ;)
>My best reward whould be to see cocoon action pattern formalized and
>placed here.
I would object to it ;)
Don't take this wrong but I don't think Cocoon has the best Action
proposal. It didn't (last time I checked) deal with a lot of things I would
want to see in an action framework. It doesn't differentiate between all
different action routing models or difference between explicit/implicit and
push vs pull actions. I am not saying turbine is perfect either as it also
doesn't deal with implicit/pull actions.
Personally I see turbine/struts/cocoon as good/great for what they do but
not perfect. You may want to have a look at a few other projects to see how
they do things. IIRC there is a project Stones or Rocks from enhydra that
implements brilliant action chain building - and there is qubes that has a
nice quilting of actions.
Even if such a perfect model was found/built it still probably belongs in
turbine unless there was a use for it in other server environments.
>> Solve those problems and I would be more than happy to have Turbine use
>> Avalon where it makes sense (I have been saying that for years now).
>> However, the fact of the matter is that I don't see it happening unless
>> someone steps up to make it happen. Of course I wouldn't -1 it, but I sure
>> am not going to do it. What I have works just fine now and Avalon isn't my
>> itch. I don't need blocks, I don't need stuff componentized into a
bazillion
>> pieces. I just need a web app framework.
A volunteer would be great but unless they were following and at least
vocal if not active on Avalon then it could be hell for them. Personally I
would prefer to wait till there is a stable Avalon and then if no one else
steps up I will help turbine use Avalon if thats what the turbine community
wants.
>> > This has promise, although I would have to give some time to research
>> > the Turbine MVC patterns. There is alot that could be learned here.
>>
>> Nice to hear you say that given that the Action framework you just talked
>> about in Cocoon 2 is essentially something that was invented at least 4
>> years ago (even before Turbine existed) by my friend Leon Atkinson and was
>> done first in PHP!
uhhh ... hello ? He did NOT invent the Action pattern. It has been around
for ages in GUI space and before that it came from simulation field. It was
originally an extention to event simulation IIRC and that has been around
for how long ? ;)
>>I find it humorous that this same Action framework is
>> also in Struts as well. More re-invention of the wheel because no one
>> bothers to look at Turbine first or people claim that Turbine isn't J2EE so
>> they don't want to use it. Duh. How lame.
One thing I would love to see (but have never mentioned it before because I
am not prepared to do the work ;]) is to see turbine segregated a bit more
- in a similar way to what Avalon has just gone through.
I would love to be able to use the page/action layer or the persistence
layer or maybe texen or maybe X or Y etc. At this stage it is just too much
effort. I suspect many people are just like me - incredibly lazy ;) and
thus will prefer to reinvent the wheel rather than keep up with turbine.
Alternatively they will fork turbine and just work of the fork.
I don't pretend to understand turbine as well as I used to but I suspect
there is various products that could be extracted out into separate
products. Do this and I am sure that you will get more developers adopt it.
I was told not so long ago it is better to tie many cotton lines than one
rope when integrating things together. ie Offer them a little and hope to
get them "addicted" to turbine and keep providing and they will keep coming
back and probably convert to your thinking ;) However say that it is the
turbine way or the highway and they will never pick it up at the begining ;)
>This is been said so many times... this happend becouse it's way easier
>and faster to reinvent the weel than dig into turbine. No matter that
>turbine is well designed and documented.
>I know this is true right now but I don't like it. The best solution I
>can think about is to spend some more effort to get turbine and cocoon
>closer where it's possible so that developers from both sides will find
>easier to dig in the other project.
Well said !
That said I do think that in the future that it would be very beneficial to
integrate Avalon and Turbine. I would hope that most of web/servlet
specific components were pushed into Turbine and kept out of Avalon though.
Of course this has to wait till Avalon stabilizes more so back I go to
hacking ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: [RT] Cocoon and web applications
Posted by Federico Barbieri <sc...@betaversion.org>.
Jon Stevens wrote:
>
> Ok, I apologize in advance if this sounds harsh in any way. It isn't meant
> to sound harsh. So, take everything I say with a grain of salt.
>
> thanks,
>
> -jon
>
> on 2/26/01 12:34 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>
> > Turbine is a specific framework. There
> > is nothing that says that Turbine can't be built on Avalon, nor is there
> > anything that says that pieces of Turbine could be included in Avalon.
>
> Yes there is. The fact that it would end up breaking a lot of people's code
> and the fact that the configuration is entirely different between Turbine
> and Avalon. Those are two MAJOR issues that no one here likes to even think
> about. People just like to say that it can be done...but in reality, it
> can't unless you want to also upset a lot of people.
>
Avalon patterns are designed to be decoupled that is you implement what
you want and you can forget the rest. This is not evident from the
implementation but it's true. Catalina is running on top of avalon right
now and keeps using its configuration system. No problema.
I've spent most of my time to make sure block implementors are provided
with nice (IMHO) tools and patterns but are still free to do things
their own way if they wish.
So the problem is not in terms of "it's painful to rearchitect
configuration" becouse you don't have too... the issue is what you gain.
Today I would say nothing... tomorrow... well it may be a dream but I
think it can gain a lot. Why?
Take an example... Let's say both cocoon and turbine are blocks...
avalon doesn't make any difference, blocks are all alike. Then you may
have turbine using cocoon as output (renderer) AND cocoon using turbine
at the same time. Each of the two may have different advandages and
disavantages but both are possible and easy to implement in such
enviroment.
In other words moving to a common ground helps those who may wish to
have more integration.
I'm not asking you to move turbine to be a block right now... it doesn't
make sense at least today. I whould be more than happy to hear turbine's
devs take a look at jakarta-avalon/proposal that is the core of avalon
specs and state your opinion.
You keep saying "take a look at turbine" so for me to say "you look at
avalon" looks like stupid... here's the difference. Jakarta avalon is
made up ONLY by interfaces and design patterns. There's nothing (almost)
belonging to the kernel implementation. The entire cvs is used by
cocoon, james, phoenix and cornerstone, each single calss. The cvs split
has this (among others) purpose... construct a round table where cocoon,
james, phoenix are all EQUAL users. The feeling that avalon devs drive
the evoluton and all the others have to follow their daily caprices MUST
be over.
My best reward whould be to see cocoon action pattern formalized and
placed here.
Any developer that thinks he can gain from this common ground is
welcomed, I personally think it make sense for turbine too, if you don't
think so... well we can still be friends. :-)
> Add to the fact that up until just recently (thanks to Sam's efforts),
> Avalon has been a terrible moving target.
I like to think I have my contribution in this... :-)
> Solve those problems and I would be more than happy to have Turbine use
> Avalon where it makes sense (I have been saying that for years now).
> However, the fact of the matter is that I don't see it happening unless
> someone steps up to make it happen. Of course I wouldn't -1 it, but I sure
> am not going to do it. What I have works just fine now and Avalon isn't my
> itch. I don't need blocks, I don't need stuff componentized into a bazillion
> pieces. I just need a web app framework.
>
You're right... there is the need for volunteers first. Thou it could
help try to make things easier for anyone with good intention...
> > This has promise, although I would have to give some time to research
> > the Turbine MVC patterns. There is alot that could be learned here.
>
> Nice to hear you say that given that the Action framework you just talked
> about in Cocoon 2 is essentially something that was invented at least 4
> years ago (even before Turbine existed) by my friend Leon Atkinson and was
> done first in PHP! I find it humorous that this same Action framework is
> also in Struts as well. More re-invention of the wheel because no one
> bothers to look at Turbine first or people claim that Turbine isn't J2EE so
> they don't want to use it. Duh. How lame.
>
This is been said so many times... this happend becouse it's way easier
and faster to reinvent the weel than dig into turbine. No matter that
turbine is well designed and documented.
I know this is true right now but I don't like it. The best solution I
can think about is to spend some more effort to get turbine and cocoon
closer where it's possible so that developers from both sides will find
easier to dig in the other project.
> Seeing projects like Cocoon trying to do a bazillion different things and
> only being able to do an ok (not excellent, but not horribly bad) job of
> each of those things (for example, Cocoon is great at output into a bunch of
> different formats, but sucks for webapps). You can't build one tool that
> solves every problem. For example, that is why there is "cp" and "mv" on
> Unix...they each do one thing really well.
I don't want to build a tool that can do everything, I'd like to see
tools that can be easily integrated. My VCR and my TV do very different
things but the both use the same plug.
Fede
Re: [RT] Cocoon and web applications
Posted by Federico Barbieri <sc...@betaversion.org>.
Jon Stevens wrote:
>
> Ok, I apologize in advance if this sounds harsh in any way. It isn't meant
> to sound harsh. So, take everything I say with a grain of salt.
>
> thanks,
>
> -jon
>
> on 2/26/01 12:34 PM, "Berin Loritsch" <bl...@apache.org> wrote:
>
> > Turbine is a specific framework. There
> > is nothing that says that Turbine can't be built on Avalon, nor is there
> > anything that says that pieces of Turbine could be included in Avalon.
>
> Yes there is. The fact that it would end up breaking a lot of people's code
> and the fact that the configuration is entirely different between Turbine
> and Avalon. Those are two MAJOR issues that no one here likes to even think
> about. People just like to say that it can be done...but in reality, it
> can't unless you want to also upset a lot of people.
>
Avalon patterns are designed to be decoupled that is you implement what
you want and you can forget the rest. This is not evident from the
implementation but it's true. Catalina is running on top of avalon right
now and keeps using its configuration system. No problema.
I've spent most of my time to make sure block implementors are provided
with nice (IMHO) tools and patterns but are still free to do things
their own way if they wish.
So the problem is not in terms of "it's painful to rearchitect
configuration" becouse you don't have too... the issue is what you gain.
Today I would say nothing... tomorrow... well it may be a dream but I
think it can gain a lot. Why?
Take an example... Let's say both cocoon and turbine are blocks...
avalon doesn't make any difference, blocks are all alike. Then you may
have turbine using cocoon as output (renderer) AND cocoon using turbine
at the same time. Each of the two may have different advandages and
disavantages but both are possible and easy to implement in such
enviroment.
In other words moving to a common ground helps those who may wish to
have more integration.
I'm not asking you to move turbine to be a block right now... it doesn't
make sense at least today. I whould be more than happy to hear turbine's
devs take a look at jakarta-avalon/proposal that is the core of avalon
specs and state your opinion.
You keep saying "take a look at turbine" so for me to say "you look at
avalon" looks like stupid... here's the difference. Jakarta avalon is
made up ONLY by interfaces and design patterns. There's nothing (almost)
belonging to the kernel implementation. The entire cvs is used by
cocoon, james, phoenix and cornerstone, each single calss. The cvs split
has this (among others) purpose... construct a round table where cocoon,
james, phoenix are all EQUAL users. The feeling that avalon devs drive
the evoluton and all the others have to follow their daily caprices MUST
be over.
My best reward whould be to see cocoon action pattern formalized and
placed here.
Any developer that thinks he can gain from this common ground is
welcomed, I personally think it make sense for turbine too, if you don't
think so... well we can still be friends. :-)
> Add to the fact that up until just recently (thanks to Sam's efforts),
> Avalon has been a terrible moving target.
I like to think I have my contribution in this... :-)
> Solve those problems and I would be more than happy to have Turbine use
> Avalon where it makes sense (I have been saying that for years now).
> However, the fact of the matter is that I don't see it happening unless
> someone steps up to make it happen. Of course I wouldn't -1 it, but I sure
> am not going to do it. What I have works just fine now and Avalon isn't my
> itch. I don't need blocks, I don't need stuff componentized into a bazillion
> pieces. I just need a web app framework.
>
You're right... there is the need for volunteers first. Thou it could
help try to make things easier for anyone with good intention...
> > This has promise, although I would have to give some time to research
> > the Turbine MVC patterns. There is alot that could be learned here.
>
> Nice to hear you say that given that the Action framework you just talked
> about in Cocoon 2 is essentially something that was invented at least 4
> years ago (even before Turbine existed) by my friend Leon Atkinson and was
> done first in PHP! I find it humorous that this same Action framework is
> also in Struts as well. More re-invention of the wheel because no one
> bothers to look at Turbine first or people claim that Turbine isn't J2EE so
> they don't want to use it. Duh. How lame.
>
This is been said so many times... this happend becouse it's way easier
and faster to reinvent the weel than dig into turbine. No matter that
turbine is well designed and documented.
I know this is true right now but I don't like it. The best solution I
can think about is to spend some more effort to get turbine and cocoon
closer where it's possible so that developers from both sides will find
easier to dig in the other project.
> Seeing projects like Cocoon trying to do a bazillion different things and
> only being able to do an ok (not excellent, but not horribly bad) job of
> each of those things (for example, Cocoon is great at output into a bunch of
> different formats, but sucks for webapps). You can't build one tool that
> solves every problem. For example, that is why there is "cp" and "mv" on
> Unix...they each do one thing really well.
I don't want to build a tool that can do everything, I'd like to see
tools that can be easily integrated. My VCR and my TV do very different
things but the both use the same plug.
Fede
Re: [RT] Cocoon and web applications
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/27/01 8:42 AM, "Donald Ball" <ba...@webslingerZ.com> wrote:
> before i got to reading the rest of this thread, i wanted to take the
> opportunity to apologize to jon. he did say some pretty inflammatory
> stuff, and i do disagree with him, but the tone of my response was clearly
> unwarranted.
>
> - donald
Sorry, I didn't even see your response. I guess that is life with cross
posting too many different lists.
Anyway, even if I did say inflammatory stuff, I did try to make a disclaimer
at the top of the email in order to put some sort of quench on the flames.
My intent is not to flame, my intent is to show some light into how *I* see
other people doing things.
This is a discussion. That is all. Nothing more. Nothing less.
-jon
Re: [RT] Cocoon and web applications
Posted by Jon Stevens <jo...@latchkey.com>.
on 2/27/01 8:42 AM, "Donald Ball" <ba...@webslingerZ.com> wrote:
> before i got to reading the rest of this thread, i wanted to take the
> opportunity to apologize to jon. he did say some pretty inflammatory
> stuff, and i do disagree with him, but the tone of my response was clearly
> unwarranted.
>
> - donald
Sorry, I didn't even see your response. I guess that is life with cross
posting too many different lists.
Anyway, even if I did say inflammatory stuff, I did try to make a disclaimer
at the top of the email in order to put some sort of quench on the flames.
My intent is not to flame, my intent is to show some light into how *I* see
other people doing things.
This is a discussion. That is all. Nothing more. Nothing less.
-jon
Re: [RT] Cocoon and web applications
Posted by Donald Ball <ba...@webslingerZ.com>.
before i got to reading the rest of this thread, i wanted to take the
opportunity to apologize to jon. he did say some pretty inflammatory
stuff, and i do disagree with him, but the tone of my response was clearly
unwarranted.
- donald
Re: [RT] Cocoon and web applications
Posted by Donald Ball <ba...@webslingerZ.com>.
before i got to reading the rest of this thread, i wanted to take the
opportunity to apologize to jon. he did say some pretty inflammatory
stuff, and i do disagree with him, but the tone of my response was clearly
unwarranted.
- donald
Re: [RT] Cocoon and web applications
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 26 Feb 2001, Jon Stevens wrote:
> > This has promise, although I would have to give some time to research
> > the Turbine MVC patterns. There is alot that could be learned here.
>
> Nice to hear you say that given that the Action framework you just talked
> about in Cocoon 2 is essentially something that was invented at least 4
> years ago (even before Turbine existed) by my friend Leon Atkinson and was
> done first in PHP! I find it humorous that this same Action framework is
> also in Struts as well. More re-invention of the wheel because no one
> bothers to look at Turbine first or people claim that Turbine isn't J2EE so
> they don't want to use it. Duh. How lame.
or maybe people aren't psyched about using turbine since it's such a
moving target.
> I have been asking for years now that the Cocoon people take a look at
> Turbine, yet no one has bothered to do so. When people went gung-ho into
> XSLT and Cocoon, I sat back and watched and waited. Now people figured out
> that XSLT sucks even though I said XSLT sucked early on. What a joke.
jon, you're coming off as a condescending know-it-all here, and that
really pisses me off, grains of salt notwithstanding. several cocoon
developers have looked into turbine, and didn't see much to attract them.
the one bit that has been integrated, the connection pool stuff, has ended
up being a real PITA due to weird configuration complexities and api
changes.
as far as XSLT goes - i thought it rocked the party, and i still think it
rocks the party.
- donald
Re: [RT] Cocoon and web applications
Posted by Jon Stevens <jo...@latchkey.com>.
Ok, I apologize in advance if this sounds harsh in any way. It isn't meant
to sound harsh. So, take everything I say with a grain of salt.
thanks,
-jon
on 2/26/01 12:34 PM, "Berin Loritsch" <bl...@apache.org> wrote:
> Turbine is a specific framework. There
> is nothing that says that Turbine can't be built on Avalon, nor is there
> anything that says that pieces of Turbine could be included in Avalon.
Yes there is. The fact that it would end up breaking a lot of people's code
and the fact that the configuration is entirely different between Turbine
and Avalon. Those are two MAJOR issues that no one here likes to even think
about. People just like to say that it can be done...but in reality, it
can't unless you want to also upset a lot of people.
Add to the fact that up until just recently (thanks to Sam's efforts),
Avalon has been a terrible moving target. Given that Turbine is enough of a
moving target itself (yes, it is often as bad as Avalon or worse),
compounding that with a dependency on another moving target would be
suicide. Note: Turbine has no official release. Therefore, the fact that it
is a moving target is ok due to the fact that it should only be used with
non-released-code disclaimers.
Solve those problems and I would be more than happy to have Turbine use
Avalon where it makes sense (I have been saying that for years now).
However, the fact of the matter is that I don't see it happening unless
someone steps up to make it happen. Of course I wouldn't -1 it, but I sure
am not going to do it. What I have works just fine now and Avalon isn't my
itch. I don't need blocks, I don't need stuff componentized into a bazillion
pieces. I just need a web app framework.
> This has promise, although I would have to give some time to research
> the Turbine MVC patterns. There is alot that could be learned here.
Nice to hear you say that given that the Action framework you just talked
about in Cocoon 2 is essentially something that was invented at least 4
years ago (even before Turbine existed) by my friend Leon Atkinson and was
done first in PHP! I find it humorous that this same Action framework is
also in Struts as well. More re-invention of the wheel because no one
bothers to look at Turbine first or people claim that Turbine isn't J2EE so
they don't want to use it. Duh. How lame.
> XSLT is a pain in the butt.
I can't agree more. It is more than just a pain in the butt, it SUCKS for
webapps. So far, the only cool XSLT application I have seen is Gump,
however, making modifications to the XSLT source code in Gump would give me
a headache.
> Where have you heard these critiques. Everything I have read has been
> pretty much pro-Cocoon. I mean Cocoon really excites the imagination
> of what can be done. When you marry it with other less glamerous projects
> the result is a net boon for all projects involved. It brings more
> users to the table for all of the technologies involved.
"Less glamorous [sic] projects"????????? Excuse me, I hope that you are not
referring to Turbine with that statement.
Combining all of our efforts together really is not a boon IMHO. The Turbine
project has been chugging along for over three years now and we have not
seen nearly the amount of political crap that other projects have been
seeing. No offense, but I don't want to bring that political crap into
Turbine at all and if someone did, I would personally flame them right off
the list. I would rather see us in Turbine land develop things more slowly
than have people messing up the Turbine project with political crap.
I have been asking for years now that the Cocoon people take a look at
Turbine, yet no one has bothered to do so. When people went gung-ho into
XSLT and Cocoon, I sat back and watched and waited. Now people figured out
that XSLT sucks even though I said XSLT sucked early on. What a joke.
Spend some time with Turbine and see how we do things before making ANY
further comments. Download the TDK and play with it. Try building a little
application. Please don't let me hear you saying that Turbine could be this
or that (even though you haven't even looked at it!)...it already is what it
is and that is good enough for quite a lot of people. Not everything has to
be J2EE or W3C or Jakarta-Combined-Library in order for it to be cool and do
the job extremely well (and often much better than the "standards" based way
of doing things).
Speaking of doing the job:
Turbine does ONE THING VERY NICELY. It allows you to build web applications
without having to constantly re-invent the wheel with commonly developed
code. Velocity does ONE THING VERY NICELY. It provides a nice template based
View/Controller part of the Model. Do you see a pattern there? No, I'm not
talking about a OO pattern (which is what Avalon and Cocoon tend to stick
with)...I'm talking about an overall design pattern.
Seeing projects like Cocoon trying to do a bazillion different things and
only being able to do an ok (not excellent, but not horribly bad) job of
each of those things (for example, Cocoon is great at output into a bunch of
different formats, but sucks for webapps). You can't build one tool that
solves every problem. For example, that is why there is "cp" and "mv" on
Unix...they each do one thing really well.
My vote is that if you really want to see Cocoon working with Turbine...or
you want to see Cocoon become a web application framework, then you should
figure out how to build that on top of Turbine instead of the other way
around. Turbine is not nearly as complex as Cocoon and it shouldn't be that
difficult given that Turbine already integrates a bazillion other tools.
p.s. There is no turbine-dev list or a java-apache-framework list and cross
posting across a bazillion lists is inconsiderate given that people won't
see the rest of the discussion.
thanks,
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/>