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.
smime.p7s
Description: S/MIME Cryptographic Signature
