You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Mind Bridge <mi...@yahoo.com> on 2005/01/09 19:05:35 UTC

Parameters

Hi,

Just to say: I think the removal of parameter directions and consolidating
them into 'auto' will greatly simplify working with the framework.


Unfortunately, there is one side-effect that absolutely must be taken care
of while doing so. It is the creation of methods (accessors/modifiers) in
the enhanced class, even though such methods exist in the base class,
particularly when direction 'custom' was used before.

Here is an example of what I mean: Table has a method named getTableModel()
that returns the table model used to build the table. This method is also
specified in the ITableModelSource interface that Table implements.

In addition, Table has a 'tableModel' parameter with which the client of the
component may manually provide the model to be used. Note that the two are
different -- the client may supply other parameters instead and the model
will be built automatically. The result is that the enhanced class also has
a getTableModel() method that now completely overrides the getTableModel()
method in the base class. Since it behaves differently (it returns the model
possibly passed by the client, rather than the one really used), the Table
component stops working in some cases.

This is not limited only to Table. Tree is affected similarly, I believe,
and there is a similar overriding of methods in a few other components such
as the Inspector (InspectorButton, specifically).



Suggestion: In general, I believe it should NOT be possible for the enhanced
class to override a method alrealy defined in the base class -- that will be
an excellent source of extremely hard to find bugs. The enhancer should
refuse to do so, and throw an exceptions should that be asked of it. That
will eliminate any possibility for a confusion.


There are a few other solutions that resolve the issue with a maximum of
backward compatibility (e.g. use the method in the base class only if it is
marked as final, disallow duplication otherwise), but those do allow
confusion to occur and it certainly would at some point. In the mean time I
guess that I will just change the 'tableModel' parameter in Table to be
named 'model', and that will resolve the issue for the time being.

Thoughts?



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.9 - Release Date: 1/6/2005


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