cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: Cocoon context "incomplete"
Date Tue, 04 May 2004 07:52:14 GMT
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'.
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

Mime
View raw message