cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Learning more about JSF and CocoonForms (was: Re: Cocoon context "incomplete")
Date Tue, 04 May 2004 08:44:56 GMT

Any JSF gurus: Pls don't feel offended by my remarks - I only want to 
learn more about the pros and cons of both frameworks!

> 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


What is JSF doing _exactly_ better than CocoonForms in this respect?

> - Separation from underlying technologie (not servlet dependent)


Isn't this true for CocoonForms too?
(Anyway, I think it's a rather academic point, isn't it?)

> - Separation of navigation handling, validation, and a


CocoonForms does *not* include the controller. It uses Flowscript for this.

> aplication binding


CocoonForms has a bindings framework which is IMHO more flexible than JSF

> 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.


CocoonForms has many of those interfaces too ...

> At this time there is no much implemented better than CForms had. But it
> will be...


Let's see ... ;-)

>
> 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...


I already saw a very promising screenshot of an upcoming CocoonForms 
plugin for Eclipse ...

The problem is that you have to decide whether you want an abstract 
framework which makes it really difficult or impossible to develop 
WYSIWIG tools or if you want something like Tapestry where you have 
standard HTML which contains information about server-side components.

The current JSF implementation only contains an HTML render kit and so 
it is possible to write WYSIWIG tools. But if I understand your approach 
correctly you want to produce XML and then I'm not sure any more what 
will happen with tool support.

The remaining question to answer is, which alternative is in the *long* 
run (including maintaince cost) the better (cheaper) one.

> 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.


What happens if I want to change the renderer in the code snipped below? 
Do I have to "touch" it or not?

<h:inputText id="ccno" size="16"
  converter="creditCardConverter" required="true">
  <cs:format_validator
   formatPatterns="9999999999999999|9999 9999 9999 
9999|9999-9999-9999-9999"/>
</h:inputText>

>
> 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.


let me add some more points here:

- I think JSF heavily mixes concerns. You've to write all-in-one pages 
(definition, validation, convertors, binding, style). I think this is a 
big mess :-(

- Binding is a separate framework and is IMO more flexible.

- You can use pipelines to render Forms which is I guess the reason why 
you want to integrate JSF.

- In CocoonForms you have to declare your widgets and then you use them 
in your templates. If there is a global widget repository we finally 
have a highly reusable solution (e.g. you declare the widget 'customer 
number' only once and use it in all the forms where you need it).

- You usually don't need Java code to develop CocoonForms so you have 
very fast roundtrip-cylces during development.

> 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.


Please keep us informed about your progress!

> ...And: Competition stimulates the Business
>
> Claas

-- 
Reinhard


Mime
View raw message