You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs@cocoon.apache.org by do...@cocoon.apache.org on 2004/08/03 23:37:35 UTC
[Cocoon Wiki] Updated: CocoonFormsJSF
Date: 2004-08-03T14:37:35
Editor: JoergHeinicke <jo...@gmx.de>
Wiki: Cocoon Wiki
Page: CocoonFormsJSF
URL: http://wiki.apache.org/cocoon/CocoonFormsJSF
Woody > CForms
Change Log:
------------------------------------------------------------------------------
@@ -1,5 +1,3 @@
-by SylvainWallez, BrunoDumon, ReinhardPoetz
-
'''Note:''' please post your comments at dev@cocoon.apache.org if you think that
information on this page is out of date or wrong (both technologies are in the flux)
@@ -8,27 +6,26 @@
== Mixing of concerns ==
* JSF heavily mixes concerns, as all is defined in a single page: page
- layout, field definition and validation, event handlers, etc. Woody,
- OTOH, cleanly separates them. This can be considered as an additional
+ layout, field definition and validation, event handlers, etc. Cocoon Forms,
+ in contrary, cleanly separates them. This can be considered as an additional
complexity, but it shows its power when a web designer and a programmer
have to work together on a project (this happens quite often!).
''I also have a prototype 20-lines XSL on my HD that allows to use a
- "pure", untouched HTML page as a woody form template. No mixing at all,
+ "pure", untouched HTML page as a Cocoon Forms template. No mixing at all,
and the webdesigner doesn't have to worry about what technology is used
to animate the page.''
* The !CocoonForms framework is NOT the controller because being the a
controller is not the concern of a forms framework
(!CocoonForms uses flowscript as controller) - most other forms frameworks
- (tapestry, JSF, struts) are both in one.
+ (Tapestry, JSF, Struts) are both in one.
== Styling ==
* JSF separates widget definition from its representation through what is
- called a "!RenderKit". But renderkits must be defined in Java and produce
+ called a "!RenderKit". But render kits must be defined in Java and produce
HTML using... println()!! Back to the pre-JSP days! Also, the definition
- of renderkits is about 1/3rd of the JSF specification. Woody styling is
- performed by two XSLs which are about 300 lines each, and the form
- framework has absolutely no relation with it. Plugging a new styling or
- another target (e.g. WAP) is very easy.[[BR]]
+ of render kits is about 1/3rd of the JSF specification. Cocoon Forms' styling is
+ performed by few XSLs, and the form framework has absolutely no relation with them.
+ Plugging a new styling or another target (e.g. WAP) is very easy.[[BR]]
[[BR]]
[http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106965495504920&w=2 comment]
by Eric Bruchez that JSF does not require JSP but can support any rendering technology
@@ -38,11 +35,10 @@
that claims compliance must support JSP in order to provide a common denominator,
but it can support other rendering technologies. You can certainly write a JSF
"tag library" for an XML-based template language that outputs SAX.}}}
-
== Binding ==
* JSF only allows to bind the form to a !JavaBean, and I'm not sure about
- how it handles complex bindings such as tables, etc. Woody, although the
+ how it handles complex bindings such as tables, etc. Cocoon Forms, although the
binding is not totally mature, offers a very flexible binding that can
map to !JavaBeans and XML documents, but isn't limited to this.
* Furthermore some generic "binders", such as the !JavaScriptBinding, allow
@@ -55,7 +51,7 @@
IIRC JSF only does data conversion as part of the binding.
== What we learned from JSF ==
-But JSF also has good things that we have "copied" into Woody:
+ But JSF also has good things that we have "copied" into Cocoon Forms:
* a server-side form model (no need for a !FormBean like in Struts)
* some clearly defined processing phases (binding, reading from request,
validation, etc) and
@@ -65,14 +61,14 @@
----
== More readings ==
- * [:Woody]
+ * [wiki:Forms Cocoon Forms]
* [http://www.theserverside.com/resources/article.jsp?l=BestBothWorlds Integrating JSP/JSF and XML/XSLT - The best of both worlds] by Eric Bruchez and Omar Tazi
* [http://www.jcp.org/en/jsr/detail?id=127 JSR127 - the JSF Spec]
* [http://www.jsfcentral.com/ JSF community page]
* [http://howardlewisship.com/blog/2004/06/more-on-tapestry-and-jsf.html More on Tapestry and JSF] Interesting reading about Tapestry and JSF, by Howard Lewis Ship (founder of Tapestry)
* [http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html Improving JSF] by Hans Bergsten (O'Reilly book author: [http://www.oreilly.com/catalog/jsvrfaces/ JavaServer Faces])
-== JSF and !CocoonForms - different comments ==
+== JSF and CocoonForms - different comments ==
* [http://www.silent-penguin.com/archives/001406.html JSF impressions] by Matthew
== Cocoon Mailing lists ==