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.
I agree with this. But modifying one of the Environment interfaces can lead to important compatibility issues, so I would say that for now, we can add the required methods on HttpContext to solve the problem right now, and consider changing the environment interfaces.
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'.
Mmmh... this argument is not relevant for me: JSF is designed by a JSR team, and although I don't know how are things going in this team, JSR teams often are driven by political fights between the different participating companies.
Comparing JSF and CForms in deep there are some fundamentals missed in CForms:
- Clean separation of state management
Uh? Can you elaborate on this? CForms has a very clear separation between form state (the widgets), application state (flowscript) and page rendering. I don't see such a thing in JSF where form definition and page template are mixed.
- Separation from underlying technologie (not servlet dependent)
CForms doesn't rely in any way on servlets. It uses Cocoon's Request object which abstracts the actual environmnent.
- Separation of navigation handling, validation, and application binding
Uh (again)? How navigation is handled is not a concern of the Form, but that of the FlowScript, and application binding is defined in a separate binding file, contrarily to JSF where the page template contains both the widget definition and the binding to the application model.
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...
I don't buy that: CForms defines interfaces and components that provide entry points for any additional feature that could be required.
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...
Aha : "such a complex technology"! Yep, CForms has a simpler architecture, yet is very powerful. Bloated specs require IDEs, while slim and clean ones only require productivity tools. And such tools will come (yep, got some prototype running on my laptop).
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.
Yep, that's one of the first things that made my hair raise on my head when reading the JSF spec: to write a renderkit, we're back to the old pre-jsp out.println("<html>") days...
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.
Exactly. And this also means that JSF makes it practically impossible to write a multi-channel application relying on the same form definition : each renderkit will define its own markup, and as page template and definition are mixed within a JSP, this means one different Form for each channel.
With CForms, you have:
- a single form definition
- possibly a single template, if written in a markup that abstracts the different channels
- several XSLT renderings, selected depending on the target channel or browser.
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.
So you want to implement a RenderKit in Cocoon? Good idea. Now have you really looked at how Cocoon and FlowScript can handle complex state management. It's so easy that you can be nearly as creative as with a fat client. With some of my latest webapps, I saw people used to "traditional" webapp development (read Struts) that couldn't believe what they saw on screen, and got crazy when they saw this was just a few CForms and a dozen lines of flowscript.
Yes, Cocoon/CForms/FlowScript makes JSF really an old-fashioned obsolete thing before it's even born. But I'm biased of course ;-)
Thats the main goal of PatchWork.XFaces.
...And: Competition stimulates the Business
Sure, but the question is: will people continue using JSF once Cocoon will have infected their app? In this regard, PatchWork.XFaces is a very good marketing tool for CForms and Cocoon in general. So keep up the good work ;-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
