cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Lowe <>
Subject Re: [RF] Chainsaws and Seeds
Date Sun, 11 Dec 2005 15:03:56 GMT
I've been wanting to add my 2 pence since stefano's "is cocoon
redundant" thread. I also admit i'm not a cocoon developer.

Nice charts.. They assume that the same folk that are there at the
start of the start line are the same folk that are end or even perhaps
middle. Despite having a lot of respect for stefano's achievements and
the contribution that cocoon has made, I think the graphs are wrong,
or at least fail to account for iterations of staff turnover.

In the case of a strong SOC approach vs embedding stuff in htmls
(including taglibs), I think whoever that the graphs work as a
concept. As long and no crack addicts wrote the orginal xsl's etc, any
new folk or contractors can fall into line see whats going on and
hence cost of ownership could indeed be reduced.

Seeing that everyone seems to agree that cocoon's strength are the
pipelines, consider the following

<c:import var="xmlds" uri="mydatasource.xml"
<c:import var="htmlRenderer" uri="/WEB-INF/xsl/html/foo.xsl" />
<x:transform xsl="${htmlRenderer}" xml="${xmlds}" />

or even a i18n example

<myxml><fmt:message key="mykey" /></myxml>

This is a over simplification and I know that cocoon does a lot more,
but I think that leveraging standard kit (when it works) would make
life so much easier. JSTL wasn't around when cocoon set out to solve
these problems, I even sincerely believe that cocoon's influence
helped the development of techologies like jstl, so my point isn't
about which is better or worse.

Up until now I've been using jsps for the view controllers with
clearly named file..


<jsp:useBean id="errors" class="java.util.HashMap" scope="request" />
<c:when test="${empty}">
    <fmt:message key="" var="msg" />
    <c:set target="${errors}" property="email" value="${msg}">
<c:when test="${myvalidations:email(email)}">
     <c:set target..  . etc
<c:when test="${!empty errors}">
   <jsp:forward page="mypage.jsp" />

in mypage.jsp iterate over error map or even a specialised java class
like ValidationError, and generate relevant xml.

Of course there's no reason why scripting or even continuations
couldn't be added, view controller logic in jstl wont be everyone's
cup to tea. But good ide and container support make it a reasonable

Again overly simple and maybe folk don't like jstl controllers, want
continuations etc, so its not like jstl can do everything. It would
need extending to do all that. But if folk want to talk about cost of
ownership, ide support, contractor/staff turnover and such like, while
maintaining SOC.

Lego is good, SOC is good, room to choose ajax or vanilla html output,
all these things are good. And before the standard kit supported it in
a usable manner was cocoon's main advantage. I see these advances in
jstl as some of the fruits of the cocoon project, and ironically not
leveraged by it. Refining jstl into something more aligned with cocoon
would seem to have more advantages than costs, would provide a clear
means of integrating legacy cocoon apps and maintain SOC.

Hope I haven't bored or annoyed anyone, just had a big itch for a long time.


On 12/11/05, Niclas Hedhman <> wrote:
> On Saturday 10 December 2005 19:20, Stefano Mazzocchi wrote:
> > Niclas Hedhman wrote:
> > > The orthogonality of Cocoon has "died". Noone talks about views. Noone
> > > highlights the ability to serve same content to many user agents. Noone
> > > is interested in truly useful smaller components. Noone cares about the
> > > developer vs designer vs deployer roles.
> >
> > Hmmm, interesting, didn't see it this way. I wonder if it's because the
> > real life forces those role to hybridize over and over, if we didn't
> > make the right choice in separating them or because really nobody cares.
> >
> > If nobody really cares, then I wonder what in hell are we still thinking
> > in terms of SoC!
> I think that is purely a matter of "who" is in the studied group.
> When you started Cocoon, you had the vision to look beyond the developer, and
> saw that scalability is a problem and went out to create a solution. But,
> somehow Cocoon didn't manage to reach out to those where this was important,
> instead it became the geek tool, and that part of the vision eroded.
> > > I am predicting that the next round of waves will not be around
> > > delivering HTML or XML to web browsers, AJAX or not. It will center
> > > around dedicated clients. And not _any_ client - but the Mobile clients.
> >
> > I very strongly disagree. Mobiles are getting richer and richer, and the
> > HTML browser software is becoming more and more commoditized. It might
> > be easier for everybody to deliver XHTML with Ajax-retrieved CSS and
> > content than to do it the other way around.
> Ok, we disagree. Time will show what the future holds. You think the client
> side will converge over the next 5 years, I say it will diverge a lot, fueled
> by the inadequacy of HTML and ever higher demanding users, with new set of
> challenges.
> > But the important point is not that you can do it, it's all those
> > borderline cases where you *can'* and, therefore, your complexity starts
> > to increase dramatically.
> Agree.
> > > And this is a lot more interesting to Cocoon than one first realizes.
> > >  1. Cocoon is already equipped to serve mobile clients, both WML and
> > > binary formats. No change required.
> >
> > Sure, but that's really not that hard to achieve.
> Really? I take it you are not authoring too many mobile apps atm.
> The capabilities varies enormously from model to model. Look at the number of
> JSRs that each model support or not. And that is just the Java world. Then
> throw in a bunch of other platforms and the mess is complete.
> > >  2. The most important aspect is the ability to generate media for
> > > different device models. No change required.
> >
> > Pipelines are first class citizens in Cocoon land, but you are talking
> > to one use of it, one that makes you happy. I'm happy if that happens,
> > but there are others. The important part is to keep the pipeline
> > machinery as first class, yet make it easier to use even in other
> > usecases. See Sylvain's proposal for dynamic and scripted pipelines.
> Agree.
> > >  3. Americans have no clue about what is about to happen. Europeans are
> > > better prepared, and Cocoon is apparently a very European project.
> >
> > That's complete bullshit. It is true that multi-modal appeal appears
> > more in Europe than in the US,
> A bit of a flame-bait, agreed. But face it, there is no mobile communication
> culture in the USA to speak of. Will it change? Yes, I am sure, but not over
> night. Developers also derives from expectations, so where the end-user
> demand is high, a larger set of development efforts will start.
> If you don't believe me, you need to go to Japan or Korea.
> > As I said, cocoon is designed for situations where the number of people
> > involved, the number of technologies involved, the number of existing
> > legacy, the number of future complexity is so high that other
> > technologies don't work.
> >
> > Mobile portals? sure, one of them. Banking data interchange? yup. Pharma
> >   and Avionic 1000-pages long manual creation and management? you got
> > it. Intranets for fortune 500 companies? yup.
> >
> > These are all applications where Cocoon has shined. Do you see the pattern?
> I see the pattern that a very large crowd "out there" thinks Cocoon is not
> good at anything, perhaps with the exception of pure document publishing.
> Instead of being known as the framework of "Good enough for everything" it is
> more known as "Not good enough for anything." The inertia between those two
> are minute, and all the fancy stuff now being discussed won't change much of
> that.
> I have been with Cocoon a long time and "talking my head off" to get others to
> use it. In a couple of cases, I succeeded, but most of the time not. I have
> now given up, and don't recommend it for any typical JAWA setup. I don't
> recommend it where it makes the most sense (large complex organic systems),
> since I don't feel the vision is there anymore, and don't want to be blamed
> for bringing in a framework that fell apart due to community entropy.
> > Cocoon need less people that write email and don't write code, myself
> > included.
> :o) Ok, I'll go to the same corner and shut up as well.
> Sorry for the noise.
> Cheers
> Niclas

View raw message