I've checked in most of the changes for these features. Maverick now uses getResourceAsStream() instead of getRealPath(), and <param name="" value=""/> elements within <controller> elements are now populated on the controller bean.
I have one question before I add timestamp checking on XSL files: Is creading and checking the date of a URLConnection for every request going to cause performance issues? The mechanism by which URL/URLConnection interacts with the container is not clear to me. Thanks, Jeff Schnitzer [EMAIL PROTECTED] > -----Original Message----- > From: Guy Evans [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 22, 2002 1:42 AM > To: [EMAIL PROTECTED] > Cc: Steve Sowerby > Subject: [Mav-user] Some changes to maverick 1.0 > > 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 _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user
