cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Derek Hohls" <DHo...@csir.co.za>
Subject Re: Rép. : Forms in Cocoon
Date Mon, 13 Dec 2004 11:07:06 GMT
My 2c re disadvantage of use of Cforms in DB projects:

* "Ease of implementation" - this is relative; the disadvantage
of learning someone's approach is quickly balanced by the extra
support you get for it; large-scale "handmade" applications are
notoriously quirky and difficult to debug.  An established OS 
project like Cocoon brings a lot of help with it.

* "Development of forms is longer" - this can easily be sped 
up through eg. use of custom code for generation of diff. steps
(BTW, those steps are there for a very good reason - "sep. of
concerns"! - removing them may well speed up the process
initially but at the cost of extra maintenance later...

* The extra steps do *not*  (in my experience, anyway) add
noticeably long extra rendering time (esp. once caching kicks in).  
I would  argue that if you are going to follow an XML-XSL-HTML 
path anyway, then the extra "overhead" of CForms is minimal.

The main disadvantage of use of CForms would be that it might
get dropped or radically reengineered in a future Cocoon (but
that's the risk of living at the leading edge!!)

>>> wreinhardt@novell.com 2004/12/13 12:44:32 PM >>>
Hi,
Forms were a long discussion on our project. Questions were should we use the Cocoon framework
(Cforms, Flowscript, JXTemplate) or should we use a simplest process like: define forms in
XML and use XSL*€*s to transform and display the form.
In our project we need to:
-	Read and write data*€*s to database;
-	We don*€*t have a lot of validations on client side;
-	The workflow is made by the user;

The advantages of Cocoon framework are:
-	It*€*s documented;
-	It cover a wide range of problems;
-	It will probably continue to evolve;
-	XSL*€*s are provided we just  need some adaptations  

The disadvantage of Cocoon framework (from our point of view)
-	It*€*s not so easy to implement (vs to solution XML->XSL->HTML)
-	The provided XSL doesn*€*t work with XSLTC (performance)
-	The development of  form is longer (more steps)
-	The transformation process to get the final HTML form is longer (performance)

Conclusion in our case we choose to create our own XSL*€*s and works with the following process:
-	Forms are defined in XML (with our own tags);
-	We create XSL*€* to transform into HTML;

I hope this help.

Willy



>>> javascript@tin.it 12/12/04 19:35 >>>
I'm working on a page with form that update a database (Xindice).

The job is simple, but i'm working a lot because the forms, the 
database, and the flow are various. I'm trying a lot this database and 
that other, this esql solution and the native database, tha cform and 
soon and soon...

Can anything send me any suggestions?  What is the better way? What is 
the better solution in form's management?

Thanks

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org 
For additional commands, e-mail: users-help@cocoon.apache.org 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org 
For additional commands, e-mail: users-help@cocoon.apache.org 



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message