Just a quick update, now that the holidays are over and I've got a few minutes without a party to attend or traveling to do :-)
The 2.0 core is pretty much done (minus all the changes to be made as people actually start using it :-), as are two sample applications which demonstrate the new stuff. Major stuff left is documentation (wheee!) and the optional modules to handle domify and velocity (and maybe even freemarker) views. The existing CVS tree is quite usable. Progress slowed considerably after Sea-Tac airport security butchered my laptop (long story here), but it's now continuing, and it'll go faster if I can figure out how to pry Scott's skiis off his feet :-) The major enhancements in Maverick 2.0 (which is more or less a total rewrite): . Pluggable view types. . Pluggable transform types. . View mode switching (more about this below). . The option of having Singleton controllers. . Pluggable bean population (and validation, etc) logic. . Log4J logging. Going through these one at a time: I'll assume the value of pluggable view types is obvious, but pluggable transforms are kinda cool too: the Maverick core includes both XSLT and "JSP" transforms. A JSP transformation takes the output of the previous step of the pipeline and stores it as a String in the request attributes, available to the subsequent step. This idea offers an XSLTish way of separating out the "layout" or wrapper html from individual page content. The optional velocity module (to be worked on RSN) will have a similar transform ability, as well as DVSL transforms. The view mode switching is a generalized way of addressing internationalization in the framework. The basic idea is that you can define modes for each view, and the framework will automatically choose the right mode based on request characteristics (such as the Accept-Language header): <command name="welcome"> <view path="en/welcome.jsp"/> <view mode="fr" path="fr/welcome.jsp"/> </command> In this case, if the request's Accept-Language header is "fr" (or "fr-madeup"), the second view will be rendered. The mode switching behavior is controlled by pluggable modules called "Shunts", and the core includes a LanguageShuntFactory which behaves pretty intelligently regarding the Accept-Language header (the example above uses the LanguageShuntFactory, of course). Similar Shunts (yet to be written) could define browser-specific behavior (e.g. IE vs Netscape vs FooBarBrowser), or content type specific behavior (HTML vs WML), or some combination of all of the above. The Shunt and ShuntFactory interfaces are very simple, so you could easily implement custom Java logic for your applications. Near as I can tell, no other MVC framework anything resembling this kind of functionality. The Singleton controller option is pretty simple and should make it very easy to define very Strutslike controllers, if that is your particular kink. It's probably even possible to create an Action fa�ade so that normal Struts actions would compile as-is. Since all the bean population logic has been pushed down into the Controller implementation classes (a base class relying on the Apache commons-beanutils.jar are included), anyone is free to implement any scheme they choose. The core framework doesn't care. The value of log4j logging should be obvious :-) It has certainly made development a lot easier. There are two sample applications that come with the core: friendbook-jsp and shunting-jsp. They both use JSP as a view technology, since the velocity and domify examples with be included with their respective optional modules. The first is a simple conversion of the friendbook sample app, using JSP transforms to add the header, navigation bar, etc. It shows the new configuration file format. The second demonstrates using LanguageShuntFactory to internationalize an application. Change your browser's preferred language to fr and see what happens. BTW, friendbook-jsp makes use of the ea3 version of the JSP "standard" tag library in the jakarta taglibs project. [long string of expletives deleted] Anyone interested in poking around should grab the current source tree from CVS. The documentation, at the moment, consists of the two sample applications and the javadoc comments. I added a "javadoc" target to the ant buildfile and have been actively enhancing the javadocs of the public classes and interfaces. Formal documentation (much more than the minimalist stuff there now) will be worked on RSN. If anyone thinks it worthwhile, I can make an early-access build sans documentation and release it. Oh! One last thing: Domify (the core package) is now it's own Sourceforge project, with a separate jar and everything :-) If you want to domify things, take a look at http://domify.sourceforge.net. After the 2.0 release of Maverick is done, we have a lot of enhancements in mind for Domify... Jeff Schnitzer [EMAIL PROTECTED] _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
