Hi!
Being on vacation it is hard to follow the actual discussions, so, sorry
if I missed something along the lines.
While the fact that Leonardo flipped the object hierarchy can be treated
as genious idea (kudos!), I am not fully convinced that this is what we
want in the end.
Please, let me elaborate about another idea.
With JSF 1.2 in mind you might notice that you'll always see a
ValueExpressionImpl (for real EL) or a ValueExpressionLiteral for ...
what a wonder ... for literals.
Thus, a component in an JSF 1.2+ environment will never have the member
set to any value if not used programatically, no?
If we backport this strategy to JSF 1.1 (by using something like a
ValueBindingLiteral) we can get rid of any member on the component.
This will fix any state saving issue as then the base class can utilize
the HashMap where all the values are stored.
If we salt all this with one of Simon's ideas to not to use a HashMap
but a simple ArrayList it might be even more performant than the
solution we use today.
Notice, by today a JSF 1.2 component will always have to lookup a Map to
get the value. What is normally fast enough will become a performance
bottleneck if called multiple of hundred times. Admitted, this is not
very common with JSF components, but, well, it might happen.
Until there it should work with myfaces-core and tomahawk.
The only difference the generator has to deal with is that with
myfaces-core the component needs to be generated and for tomahawk a
simple baseclass with mainly some static int-s to describe the property
position within the array. Means, for myfaces-core we have to deal with
developing with templates while for tomahawk we can move on with
something more comfortable.
One than has to extend this baseclass and put in all the getter/setter
to access this array list. For the first time the generator might be
able to generate this class to, afterwards it needs to be maintained
manually which is not thath much work. And the dreaded reflection bug is
fixed too.
The result might be something like:
class AbstractTreeComponent extends UIComponent
{
final int FIN_VALUE=0;
final int FIN_COLLAPSED=1;
... something more I do not think about yet ....
}
public class TreeComponent extends AbstractTreeComponent
{
public boolean getCollapsed()
{
return ComponentUtils.getBoolean(this, FIN_COLLAPSED);
}
public void setCollapsed(boolean collapsed)
{
return ComponentUtils.setBoolean(this, FIN_COLLAPSED, collapsed);
}
}
What might not be very transparent at the first glance is, that the
state will shrink (!) that way. Currently you have to save the attribute
map AND all the members mostly "null", afterwards you just have to save
a merge of those both.
With the very minor manual overhead to generate the getter/setter you
gain a clean, well-known object hierarchy and many of the problems with
any of the other solutions are fixed. Notice: no one will ever forget to
implement the getter/setter as otherwise the data is not available
within the renderer.
Something critical I overlooked?
Ciao,
Mario
