Re: Pico-enabled Controllers?

Aapo Laakkonen wrote:
> 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]