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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
