Rebinding/advising/intercepting component parameters in a mixin

[Jochen Berger <fo...@googlemail.com>]

Hi there,

I'm trying to write some mixins for the Grid component, e.g. one to make
it filterable using the respective PropertyEditors for the Grids
BeanModel's properties.
Therefore, I created an interface that extends GridDataSource and has an
additional method
 void applyFilters(Map<String, String> currentFilters);
What I try to do now is to be able to "override" the grid's source
parameter with an instance of that FilterableGridDataSource interface.
I'm aware of the @BindParameter annotation but it does not do exactly
what I want, as I want the "changes" to be applied only "down" the
rendering path, i.e. I want to write to the field without the new value
being published "backward" to where the original value was coming from.
In fact, I'd also be happy if it was pushed to a no-op setter if the
parameter was read-only, but that's details.
I've already tried several solutions (including an approach using a
ComponentClassTransformWorker and a stack that got filled during the
various render phases and the like but that caused issues and
interferences with other Workers and seemed overly complicated anyway.
So I thought I'd ask if any of you guys can come up with a slightly less
complicated and more elegant approach.
I think it'd be best, if I could just use the TypeCoercer for that issue
(I can provide a coercionTuple to just "make it work") but I can't get
it to be used in the right place. If I understand it correctly, the
contribution would have to be used by the
ParameterConduit.readFromBinding() method but that will coerce to the
parameter's type in the component, which is GridDataSource, which is
obviously quite useless for my case. ;-)
I hope, there is an easier way than to hack my own ParameterWorker into
the Transformer chain. ;-)

Cheers,
Jochen


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

Re: Rebinding/advising/intercepting component parameters in a mixin

[Jochen Berger <fo...@googlemail.com>]

Thiago,

Am Dienstag, den 29.03.2011, 12:15 -0300 schrieb Thiago H. de Paula
Figueiredo:
> I guess you need to create another binding prefix implementation that  
> works like prop but read-only and use it instead. You can file a JIRA  
> about this.

Thanks for your answer and your idea. But I'm afraid that is not exactly
what I had in mind. I do want to write to the field from within the
mixin (at least if I cannot get my Coercion to be used by the
ParameterWorker.
Maybe I'll eventually have to exchange it.
Besides, I do not want to mandate the usage of a special binding prefix
when using the mixin. I want it to be usable with prop: as well as with
list: or dbtable: or whatever someone might have imagined. ;-)

Jochen




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

Re: Rebinding/advising/intercepting component parameters in a mixin

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

On Tue, 29 Mar 2011 09:42:51 -0300, Jochen Berger  
<fo...@googlemail.com> wrote:

> Hi there,

Hi!

> I'm aware of the @BindParameter annotation but it does not do exactly
> what I want, as I want the "changes" to be applied only "down" the
> rendering path, i.e. I want to write to the field without the new value
> being published "backward" to where the original value was coming from.

I guess you need to create another binding prefix implementation that  
works like prop but read-only and use it instead. You can file a JIRA  
about this.

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

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