Jeff, Yep, it actually works! (However, depencies in imported/included stylesheets don't, so if in stylesheet A you include stylesheet B and then change stylesheet B the template for stylesheet A is not recalculated.)
Cheers Guy > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Schnitzer > Sent: 01 February 2002 11:18 > To: [EMAIL PROTECTED] > Subject: RE: [Mav-user] Some changes to maverick 1.0 > > > Well, I feel silly :-) > > Yes, I had overlooked the extra parameter to StreamSource... the new > code is checked in and works great. Thanks. Extra overhead for > getResource() is no big deal because it's all done just once at > configuration (re)load time. > > I saw a few posts to one of the tomcat lists which suggested that > URLConnection.getLastModified() is rarely ever implemented. Do you know > if this actually works? > > Thanks, > Jeff Schnitzer > [EMAIL PROTECTED] > > > -----Original Message----- > > From: Guy Evans [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, January 30, 2002 1:50 AM > > To: Jeff Schnitzer; [EMAIL PROTECTED] > > Subject: RE: [Mav-user] Some changes to maverick 1.0 > > > > Hi Jeff, > > > > I've had a quick look at the URLConnection stuff related to > > getResourceAsStream(). > > > > If you print out the getResource() URL it corresponds to something > like > > "jndi:/localhost/si/html/xslt/reports.xsl", and the actual > URLConnection > > is > > an instance of the class of > > org.apache.naming.resources.DirContextURLConnection. For mysetup that > is > > part of the tomcat installation. Looking through that code it looks > like > > everything maps to normal files at the end of the day; there are no > > additional TCP/IP connections. > > > > So there's going to be some overhead through the couple of additional > > objects that are created and the extra code it has to go through. I > would > > be surprised if it was significant but it may make sense to have this > a > > development debug option since it's unlikely to be needed in a > production > > environment. > > > > Cheers > > Guy > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff > Schnitzer > > > Sent: 28 January 2002 03:41 > > > To: [EMAIL PROTECTED] > > > Subject: RE: [Mav-user] Some changes to maverick 1.0 > > > > > > > > > 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 > > > > > > _______________________________________________ > 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
