Hi,

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 :-

* 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().

* 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.

I suspect that the factory mechanism in v2.0 would provide another solution
to this problem?

* 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.

If it would be useful we can send patches against the 1.0 release for the
above changes.

Cheers
Guy


_______________________________________________
Mav-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/mav-user

Reply via email to