[Cocoon Wiki] Updated: CocoonFormsJSF

[do...@cocoon.apache.org]

   Date: 2004-10-01T15:55:25
   Editor: VadimGritsenko <vg...@apache.org>
   Wiki: Cocoon Wiki
   Page: CocoonFormsJSF
   URL: http://wiki.apache.org/cocoon/CocoonFormsJSF

   Update on SoC, Rendering, Styling

Change Log:

------------------------------------------------------------------------------
@@ -1,46 +1,60 @@
-'''Note:''' please post your comments at dev@cocoon.apache.org if you think that
+'''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)
 
 A comparison between [wiki:Forms Cocoon Forms] (formerly known as ''Woody'') and 
 [http://java.sun.com/j2ee/javaserverfaces/ JavaServer Faces].
 
-== Mixing of concerns ==
+== Separation of Concerns ==
  * JSF heavily mixes concerns, as all is defined in a single page: page 
- 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 Cocoon Forms template. No mixing at all, 
- and the webdesigner doesn't have to worry about what technology is used 
- to animate the page.''
+ 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 Cocoon Forms template. No mixing at all, 
+   and the webdesigner doesn't have to worry about what technology is used 
+   to animate the page. ''-- Unknown Hero''
+   * It's possible to "un-mix" concerns in JSF, by implementing !ViewHandler
+   and your own form definition language, and move all component definitions,
+   validations in there.
  * 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.
+ (!CocoonForms uses Action or Flowscript as controller) - most other forms
+ frameworks (Tapestry, JSF, Struts) are both in one.
 
-== Styling ==
- * JSF separates widget definition from its representation through what is 
- 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 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
- (JSP is only the common denominator):
- {{{... there is nothing in JavaServer Faces that forces you to use JSP or that
- limits you to outputting a character stream from a renderer. An implementation
- 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.}}}
+== Rendering, Styling ==
+ * JSF separates widget definition from theirs representation through what is 
+ called a "!RenderKit". But render kits must be implemented in Java, one class
+ per component, and output final page markup (default implementation: HTML)
+ into subclass of Writer (javax.faces.context.!ResponseWriter)
+ using a-bit-SAX-like methods, or simply... write()! Back to the pre-JSP days!
+ And the definition of render kits is about 1/3rd of the JSF specification.
+ Cocoon Forms' rendering is performed by !FormsTransformer, which generates
+ markup-independent XML SAX events for consumptions down the pipeline.
+   * Thankfully, default JSF !RenderKit implementation, BASIC_HTML, does not use write()
+   much, which made it possible to replace JSF's default view layer, JSPs, with Cocoon
+   pipeline generated view (See
+   [http://svn.apache.org/repos/asf/cocoon/branches/BRANCH_2_1_X/src/blocks/faces/ Faces]
+   block in SVN). Faces block does not solve multichanneling problem though - you still have to
+   write XML render kit (and XSLs) to achive this.
+
+ * JSF BASIC_HTML render kit output can be styled only to the extent of specifying style
+ and class attributes in the resulting HTML elements. For more extensive changes in the
+ output, render kit have to be re-implemented, or new render kit should be written.
+ Cocoon Forms' styling is performed by few XSLs, and can be heavily modified to your
+ needs without changing any Java code.
+
+ * JSF can render into multiple markup languages. To achive this, though, you will
+ have to implement render kits for each target markup language, which amounts to
+ dozens of classes. Plugging a new styling or another target into the
+ Cocoon Forms' (e.g. WAP) is very easy - just write couple of XSLs.
 
 == 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. 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. 
+ map to !JavaBeans and XML documents, but isn't limited to this.
+
  * Furthermore some generic "binders", such as the !JavaScriptBinding, allow 
  to implement any kind of complex bindings: for example, we use it to bind a 
  repeater to different "parallel" collections in an XML document.