> From: Guy Evans [mailto:[EMAIL PROTECTED]] > > Over the last few weeks we've made some small changes to Maverick 1.0. > I'd > thought I'd enumerate them here, hopefully either they are already > superceeded by Maverick 2.0 or if the changes we made are considered > useful > they can be rolled into a future Maverick 2.0 relelase? Anyway, the > changes > are :-
Sounds great, please send patches! :-) > * We couldn't use maverick within a .war file since it makes some calls to > getRealPath() on the webapp context. As I understand it if a web app is > run > directly from a .war file then getRealPath() can return null and > getResource() or getResourceAsStream() should be used instead. This > required small changes to ConfigLoader.java and PipelineTransforming.java. > Grepping through the 2.0 source code it appears that there are still calls > to getRealPath(). Good idea. Out of curiosity, what servlet container are you using that doesn't unpack war files? > * We were finding that a lot of our commands would use the same basic > controller class but with slightly different options (e.g. retrievals from > a > database.) Initially, this led to a proliferation of classes which > typically just passed some parameters to the base class constructor. To > help prevent the number of classes we modified the controller creation so > that within the maverick.xml <param name=" " value=" "/> could be > contained > within the <controller> element. These parameters were then used to "bean > populate" the controller in exactly the same way as if they had been > passed > as URL query parameters. Another good idea. Scott was discussing this some time ago but it never made it into production. Will add. > I suspect that the factory mechanism in v2.0 would provide another > solution > to this problem? While there is a ControllerFactory used internally, it isn't pluggable. It certainly could be, though. Currently the only factories which are configurable are ViewFactories, TransformFactories, and ShuntFactories. > * Just before an XSL transformation is used, we check the modification > time > of the underlying file. If the file has been modified since the template > was created the in-memory template is recomputed. This means we can > simply > change the XSLT file and maverick will automagically detect the changes. This doesn't work with getResourceAsStream(), does it... > If it would be useful we can send patches against the 1.0 release for the > above changes. Please do! Thanks! Jeff _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
