Re: [Xforge-users] Re: Monitoring/Cacheing

[Alberto G. <alb...@ge...>]

----- Original Message ----- 
From: "Ulrich Mayring" <ul...@de...>
To: "xforge-users Mailinglist" <xfo...@li...>
Sent: Monday, February 17, 2003 6:51 PM
Subject: [Xforge-users] Re: Monitoring/Cacheing


> Ulrich Mayring wrote:
> 
> > Alberto Garoffolo wrote:
> > 
> >> 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.
> 
> You cannot always assume a hierarchical structure, look at this example:
> 
> <mycomponent1:setDatabase>
>    <xf:parameter name="dbname">PRODUCTION_DB</xf:parameter>
> </mycomponent1:setDatabase>
> 
> <mycomponent2:getContactFromDB>
>    <xf:parameter name="contactId">12345</xf:parameter>
> </mycomponent2:getContactFromDB>
> 
> Suppose someone changes "PRODUCTION_DB" to "DEV_DB". It is quite 
> possible that the contact with ID 12345 is a different person in DEV_DB 
> or may not even exist there.
> 
(1)

> So, we need to monitor arbitrary XML elements (which would also include 
> the <xf:parameter> element). But we cannot, for example, refer up the 
> tree or sideways, that would violate IOC.
> 
> Therefore, instead of defining monitors locally to components, they must 
> be defined centrally. Basically we need something like the Sitemap in 
> Cocoon. But since I don't like the Cocoon Sitemap concept (it basically 
> brought me to X:Forge) I won't do it ;-)
> 
> The answer IMHO is to design components correctly. The above example is 
> a braindead design and so is the XSLComponent. A better design would be 
> this:
> 
> 1) Make a TransformerComponent. It will always know, when it has changed 
> via a simple FileMonitor.
> 
> 2) Invent a way to pass objects instead of Strings with the 
> <xf:parameter> element. For example:
> 
> <xsl:apply>
> 
> <xf:parameter name="xml">
> <!-- will be passed as String -->
> <foo:bar/>
> </xf:parameter>
> 
> <xf:parameter name="xsl" type="object">
> <!-- will be passed as Object -->
> <transformer:get>
> <xf:parameter>
> test.xsl
> </xf:parameter>
> </transformer:get>
> </xf:parameter>
> 
> </xsl:apply>
> 
I thought the same thing :)
I totally agree with you! 

> 3) Now the XSLComponent can implement Unchangeable, because changes only 
> occur, when either the transformer component or the foo component 
> changes. This solves all problems except where the XML input is at least 
> partly static like here:
> 
> <xf:parameter name="xml">
> <list1>
> <foo:bar/>
> </list1>
> </xf:parameter>
> 
> Suppose <foo:bar/> is unchangeable, but someone changes "list1" to 
> "list2", so that after stylesheet application he gets a different layout.
> 
Here is, in my opinion, a misunderstanding (also related to (1)):
If someone changes the input xml (for example test.xml) , 
all the trasformation must be re-performed. We have no way to know
if and what is changed inside the xml. We can only ask to our components
if, with *unchanged input*, something external has changed.

[...]


Ciao,
---
Alberto.