cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Collen <colle...@umn.edu>
Subject Cocoon vs. Verge, Round 1
Date Tue, 13 Jan 2004 22:04:08 GMT
I was reading Steven's blog [1] and he mentions Verge [2], Yet Another 
Form Framework, and how it compares to Woody.

I've pasted the alleged feature matrix, and injected my own comments 
from what I know about Woody so far (My comments are indented and 
parenthesized).

There's a little bit of comparing apples to oranges, but I think this is 
a pretty good comparison of what we have.

I'd appreciate if anyone who's a little more familliar with Woody/CForms 
could also inject their changes/additions to the featurelist.

Regards,
Tony

[1] http://blogs.cocoondev.org/stevenn/archives/001666.html
[2] http://www.inversoft.com/products.html

----

-------------------------
Cocoon vs. Verge, Round 1
-------------------------

Model features

* No inheritance or interface required
     (Check)
* True JavaBeans can be used
     (Check)
* JavaBean event handling at any depth using standard Java event 
listener pattern
     (Unsure)
* Multiple form beans on any form
     (Unsure)
* New model systems can be built and added to Verge. These model systems 
can also use the same tag library provided with Verge
     (Unsure)
* Nested properties
     (Unsure)
* Complex data structures (for example, Maps that contain Lists that 
contain Arrays)
     (Sure)
* Validation system
     (Check)
* Auto-validation configured in the XML configuration files
     (Check)
* Custom auto-validators
     (Check)
* Auto type conversion of the String values from the HTTP request to the 
correct Java or custom type
     (Check)
* Custom type converters
     (Check)
* Custom invalid type conversion handling using validator classes
     (Not sure about handling, definitely custom error messages)
* I18N error messages that store the error message as well as the Locale
     (Check)
* Auto-build of complex object models using IoC principles
     (Unsure, but I think it's up to the developer to make sure their 
backend code uses IoC)
* Initial values and relationships for objects using IoC principles
     (Unsure, See Above)

Controller features

* Auto-forward on failed validation configured in the XML configuration file
     (Unsure, AFAIK Woody just redirects to the same form over until 
it's valid.)
* JavaScript action support allowing JavaScript functions to submit form 
actions
     (Unsure)
* JavaScript library provided
     (Unsure)
* Controller chaining, looping and branching done via the XML 
configuration file
     (Unsure)
* Scope control for all controllers allowing controllers to be request, 
session or application scoped
     (Unsure)
* New controller systems can be added to Verge so that legacy systems 
can be used without any code changes
     (Unsure)
* Actions based on buttons, not form. This allows each button on a form 
to submit a different action without extra code or configuration
     (Unsure)
* Actions can target classes or methods
     (Unsure)
* Standard action handling)
     (??? What does "Standard" mean anyway
* Complex URL generation for production environments
     (Check, use the sitemap :))
* No inheritance or interface required
     (Check, it's just JavaScript)
* Centralized application flow configuration
     (In sitemap)
* Long transaction wait pages with no coding
     (I've done this before using flowscript, requires minimal coding.)

View features

* Full W3C compliance that allows the use of every supported HTML 
attribute in the HTML 4.01 specification
     (Check, depends on the developer though)
* Full checkbox and radio tag support with no code (no more reset or 
clear methods, the framework handles all this)
     (Unsure)
* Full JavaScript library
     (Library of what?)
* Single tag library for all model systems. This means that a form can 
be converted from one MVC system to another. For example, from the 
Form-Based MVC to the ActionFlow MVC
     (Unsure)
* Dynamically built views
     (Check.)
* Non-JSP views can be used
     (Check! :))
* HTTPS and complex URL generation support using the URL generator
     (HTTPS through the container ??.)



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


Mime
View raw message