What maverick needs is something that helps you with Web development. Ie. Velocity macro libraries, Java tag libraries, and something that helps you with input parameter validation. I know that Ted has worked with FormProc implementation, but maybe FormProc is not what users are looking at. It's a good library, but something more tightly integrated with maverick would be nice.
The stock Velocity tools and macros and JSTL libraries work just fine with Maverick. As, I'm sure, will JavaServer Faces when it ships. A couple of years ago, a framework may have needed to roll their own JSP tags, but those days have passed. (At least for 2.3 containers.)
The FormProc integration is actually quite tight, especially if you can use a Map (or "Context") as the Model. You can define the parameters needed in the FormProc XML and just use a stock Maverick controller. FormProc takes care of ensuring that only the parameters you want are harvested, as well as transforming the parameters into the desired datatype. If validation fails, the CVS version can now return the original parameter map, so you can populate the controls again.
Though, FormProc is just one cog in the gear. :)
In my own current development, I'm using Velocity, FormProc, Maverick, Commons Chain, iBATIS DAO, and iBATIS SqlMap. Together, these are an absolutely dynamite combination. Happily, the current phase of our project is a application for managing a user database on Jetty or Tomcat. Since this application is generally useful, I'll be able to share the final result, and provide a tour of how it all fits together.
One of the things I like best about Maverick is that it is clearly focused on providing a standard front controller, a key problem that neither Java, .NET, nor PHP want to address (for some reason). Many projects start to sprawl, which seems to cause more problems than it solves. But, Maverick has retained a very clear focus.
A definite issue with the proliferation of XML-configured products, like five of the six I mentioned, is juggling the elements. But that's something that we can solve with IDE plugins, or a master "seedling" configuration that loaded the object graph a product expected from a master document.
-Ted.
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ [INVALID FOOTER]
