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'. Comparing JSF and CForms in deep there are some fundamentals missed in CForms: - Clean separation of state management - Separation from underlying technologie (not servlet dependent) - 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...
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.
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. 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.
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.
...And: Competition stimulates the Business
Claas
-- ____________________________________________________________________ Dipl.-Inf. Claas Thiele EMail: cthiele<at>ct42.de Konradstr. 58 Web: http://ct42.de 04315 Leipzig Tel.: +49 (0)341 68 70 92 29 GERMANY Fax +49 (0)341 68 70 92 30
