tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mind Bridge <mindbridge...@yahoo.com>
Subject The For component algorithm and parameter names
Date Sat, 03 Sep 2005 09:03:55 GMT

Several recent messsages on -user list, as well as a relatively long 
list of such responses in the past, have indicated that people write 
code that is greatly dependent on the _physical equivalence_ of the 
relevant object, rather than the equivalence of its value. In other 
words, == is used (directly or indirectly) instead of equals(), etc. 
Since Java does not provide implicit types that guarantee content, 
rather than reference equivalence, this whole mechanism is explicit.

How does this affect Tapestry?

Objects are often "squeezed" in the render cycle, and are then 
"unsqueezed" in the next rewind cycle. The process usually involves 
serialization/deserialization as well. The result is a different 
physical object with a different reference, even though it has 
equivalent contents.

Algorithms that rely on the physical equivalence of objects break down 
as a result -- questions of the sort "Why are my object modifications 
not remembered?" appear (Note that the code leading to those questions 
would not work in a cluster as well, but that is another question I guess).

Since equals() is apparently an advanced material that the ordinary 
coder does not employ, it seems to me that we need to provide the 
physical objects themselves in the rewind cycle to eliminate those 

The way to do that in a loop component like 'For' is to not use the 
'unsqueeze' process during 'rewind' at all. Instead, 'squeeze' the 
objects in source again, and see what object is 'squeezed' to an 
equivalent string. The object with a matching representation would be 
the same physical object. Problems of the type described above would not 

Note that 'For' already does something like this with the 
'keyExpression' parameter -- if that parameter is provided, OGNL is used 
to extract a unique squeezable key  from the object. During rewind that 
extraction is performed again, and the values with matching keys are used.

Here is what I am thinking of doing:

- Add a new parameter to For named 'match' (suggestions for better names 
are very welcome).
That parameter would default to 'true' and would indicate that For would 
search for an equivalent object in 'source' or 'fullSource'. The 
rewinded objects would have the same string representation as the one 
generated during the previous 'render'. Essentially we do not perform 
'unsqueeze', but search for matching 'squeeze' instead. 'unsqueeze' 
would only be used if all else fails.

If 'match' is false, the current and possibly more eficient behaviour 
(unsqueezing) would be used instead.

I see this as a stealth parameter similar to 'volatile' -- it may result 
in lower performance in some cases, but that is a small price to pay for 
the big win in convenience. The parameter would be practically invisible 
in the general case, and you would only need to use it if you know what 
you are doing.


To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

View raw message