[Xforge-users] Re: Monitoring/Cacheing

[Ulrich M. <ul...@de...>]

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.

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>

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.

Right now static (non-namespace prefixed tags) are simply converted into 
SAX events (parent.startElement(...) etc.).

Perhaps we could design a generic component, which is responsible for 
all tags that have no namespace prefix (i.e. static tags). It could 
generate the SAX events like now, but have additional features:

1) It could implement Monitorizable and the getMonitor() method would 
return "this".
2) It could implement Monitor and the lastModified() method would return 
an internal timestamp.
3) The timestamp would be set on the first invocation and updated to 
now, whenever the current SAX events are different from the SAX events 
generated by the last invocation.

Now, is this totally stupid or what? :)

Ulrich

-- 
Ulrich Mayring
DENIC eG, Systementwicklung