cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Cocoon context "incomplete"
Date Tue, 04 May 2004 09:13:49 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.


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 }


Mime
View raw message