cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Cocoon context "incomplete"
Date Wed, 05 May 2004 14:32:41 GMT
Joerg Heinicke wrote:

> As I'm not yet really involved in this JSF integration project, I
> forwarded your mail and here are the answers by Claas. I copied them out
> of his mail (untouched) as this mail contained my German text inside. 
> Find the answers below.
> 
> Joerg
> 
> On 03.05.2004 23:47, Sylvain Wallez wrote:
> 
>> Adding this method on HttpContext doesn't hurt in any way, since it 
>> doesn't change the interface shared with other Context implementations.
>>
>> So +1 for this.
>>
>> Now the question is to know if JSF can work outside of the servlet 
>> environment. If this is the case, you may also want to change the 
>> Context interface also. But this would require a vote because it's an 
>> incompatible change for people having written their own environments 
>> (not sure there aren't that much though).
> 
> 
> Yes JSF can do, and that is what I want. So enhancing the Context
> Interface would be the right way (and the only one makes sense).
> 
> I can work around this problem by falling back to the original
> ServletContext for missing methods, but thats not clean and confine the
> usefulness in non-servlet environments.
> I think, this does not depend on JSF integration. It will be a good idea
> for Cocoon having a most complete Context.
> 
>> BTW, why integrate JSF and Cocoon when we have CForms?
> 
> 
> Thats the question I'm awaited for....
> At first: JSF is a framwork and a spec supported by industry more than
> CForms. This does not state everything about the today's quality of the
> compared technologies. But JSF will evolve faster and will be more
> stable and more complete due to the larger 'community'.

ROTFL! This is exactly the opposite: a larger industrial community tends 
to have huge inertia (see how bad JSP are) and do several mistakes 
driven by back compatibility reasons (see Servlet Filters vs. cocoon 
pipelines).

> Comparing JSF and CForms in deep there are some fundamentals missed in
> CForms:
> - Clean separation of state management

that's because you can't take CForms and move it outside the context of 
the cocoon framework. JSF draws from the experience of Struts, but it 
was designed to run without it (JSR spec lead is the author of Struts). 
CForms doesn't draw on the experience of cocoon and tries to replace it.

> - Separation from underlying technologie (not servlet dependent)

same here

> - Separation of navigation handling, validation, and application binding
> For all this things the JSF spec defines interfaces and/or describes
> contracts so third parties can develop here own things with future
> proving of investment.
> At this time there is no much implemented better than CForms had. But it
> will be...

Oh sure. Industry is stupid enough to buy anything that has a 
JCP-organic logo on it. Proof in point, they bought JSP for years and 
now JSP2 is cloning Velocity. Wait to go!

> Second: Such a complex technology needs tool support, integration in an
> IDE and so on. With a larger market of the base technology this things
> will come...


> On the other hand:
> 
> In my opinion there is a a big disadvantage of JSF:
> They define Java classes as renderers.
> Building up a complete and reliable Renderkit supporting different
> browsers is one of the main points overall.

The Renderkit idea is simply flawed. These guys don't know what real 
multichanneling is. they think multichanneling is not one channel, it's 
two, or three. Cocoon power users know that multichanneling is about 
hundreds of channels.

Think about the maintenance cost of 150 renderkits written in java 
versus a hierarchy of xslt stylesheets.

> But: The web designer cracks (knowing all about the browser quirks) are
> in most cases not the java cracks. They can not build up a complex,
> reusable and maintainable renderkit written in java.

bingo, xslt is hard enough for them, but it's definately less expensive 
than java code in those situations.

> At all it will be the wrong way making complex things for a markup based
> client (like HTML, XUL, WML, ...) in Java. You will feel the dejavue
> looking on some JSP pages and the growing taglibs behind.

Exactly!

> So lets Cocoon render and let us use all the other things coming up with
> JSF like complex state holding, complex application binding, tools
> support and so on.
> 
> Thats the main goal of PatchWork.XFaces.

I think that using JSF for nothing related to the faces is, well, rather 
peculiar. I think you'll find out that CForms+sitemap+flow is *way* 
better than anything else you can throw at it.

Sure, you have to give up the JCP-organic brand. Live dangerously. It's 
a state of mind, actually, nothing technological. Not everybody can do that.

> ...And: Competition stimulates the Business

Competition? I, for one, never felt the competition of JSF, they spent 
years in a JCP ivory tower to standardize Struts while everybody knows 
that multichanneling is a completely different business.

In the long run, good solutions win, not good marketing engines.

-- 
Stefano.


Mime
View raw message