|
From: Ulrich M. <ul...@de...> - 2003-02-13 14:55:12
|
Alberto Garoffolo wrote: > Hi, > > IMHO cacheing/monitoring implemented in XSLComponent > overlaps with the native X:Forge monitoring system. Yes, unfortunately. > X:Forge monitoring system philosophy is: Components > doesn' t have to care about changes, when they are invoked > they just produce xml and, if they are monitorizable, > return a monitor which checks if the resources used in the > *current request* change. If monitored resources for a > specific request aren' t changed, associated components > will not be called at all. Ok. > In the new XSLComponent version, there is also the possibilty > to monitor the whole xml file used by x:forge. In my opinion > this should be done by the generator/producer/"who loads the file" > in a cocoon/servlet like system. > > Transformer cache in XSLComponent, doesn' t consider that a > single Component instance can be used to apply different stylesheets: > > <bug> [...] > </bug> > The third trasformation will apply test2.xsl instead of test.xsl. Hmm... I haven't tried it, but I think you're right that there's a bug. > As u can see to make it work correctly, more code has to be > written in the xslcomponent, weighting down it a lot. Consider > also that if we follow this philosophy, each component will reinvent > the wheel each time needs to cache something. I absolutely agree with you. It's just that I have no better solution :( > The advantage of the X:Forge monitoring system philosphy is > to make component logic easier and cleaner. > > The disadvantage is to re-run a component also if changed > another component used in that request. To avoid this we > should watch at the problem in a more general way; for > example (1) thinking about cacheing each component sax result. > For example: > > <test> > <comp1:dosomething> > <xf:param name="param1"> > <comp2:dosomething/> > </xf:param> > </comp1:dosomething> > > <comp3:dosomething> > <xf:param name="param1"> > <comp4:dosomething/> > </xf:param> > </comp1:dosomething> > </test> > > If comp2 changes, we must invalidate all it' s ancestors results, > but we can reuse the ouput of comp3. > This is just an idea ... > > But probably u need even something more: You want to cache > one of the params passed to the component (in this case the > Transfomation object created parsing the xsl) .... This is more > difficult ... > Hhhhmmm .... Do u really need it ( considered (1) ) ? :) Stylesheet creation is an expensive operation and in many real-world scenarios you must be able to do it. Consider a Cocoon-like system, where you have many users accessing a page at the same time. If you have to recreate the transformer each time, it takes 2 seconds longer to wait for the user on every request. On the other hand the system has to pick up changes to the stylesheet and the XML files being transformed, because in a production scenario you can't constantly restart your application. I'm absolutely in favor of solving this problem outside of the XSL component, but currently have no idea how to change the monitoring system, so that it supports such things. If you want we can do some brainstorming: Maybe we need a FileComponent, which we can pass as parameter to the XSLComponent. The FileComponent could return a FileMonitor in its getMonitor() method, the XSLComponent could return a ComponentMonitor for the passed FileComponent. The ComponentMonitor's getLastModified() method would return this.component.getMonitor().getLastModified(). Ulrich -- Ulrich Mayring DENIC eG, Systementwicklung |
