You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Paul Stanton <pa...@mapshed.com.au> on 2012/11/07 01:41:17 UTC
Re: Dynamic mixins
.. and then if you have a combination of potential mixins, you end up
with n * blocks, with n * fields.
Thanks for the solution Robert, and I can appreciate that this is
bumping the limitations of the framework but the situation is not ideal.
I'm looking at a case now which is going to end up very complicated.
thx, paul.
On 10/03/2012 3:11 AM, Robert Zeigler wrote:
> Hi Brian,
>
> This is a case of "static structure, dynamic behavior". Tapestry needs to know the mixin at page/component creation time, rather than at runtime.
> This "early binding", if you will, let's tapestry do a lot of optimizations and enables behavior that would be otherwise cost-prohibitive (eg: I can't think of a reasonable way to implement @BindParameter if runtime-mixin selection was allowed).
>
> Here's a potential workaround:
>
> <t:block id="fee">
> <t:label t:for="residentFeeInquiryWithFeeMixin"/>
> <t:select t:id="residentFeeInquiryWithFeeMixin" t:mixins="feefromresidentupdater" clientId="residentFeeInquiry" .../>
> </t:block>
>
> <t:block id="singlesource">
> <t:label t:for="residentFeeInquiryWithSSMixin"/>
> <t:select t:id="residentFeeInquiryWithSSMixin" t:mixins="singlesourceformfieldupdater" clientId="residentFeeInquiry" .../>
> </t:block>
>
> <t:delegate to="prop:mixinBlock"/>
>
> .java:
>
> @Inject
> private Block fee;
> private Block singlesource;
>
> public Block getMixinBlock() {
> if (getContainer() instanceof SendMoneyTransfer)
> return fee;
> return singlesource;
> }
>
> HTH,
>
> Robert
>
> On Mar 9, 2012, at 3/910:00 AM , Brian Long wrote:
>
>> Hi all,
>>
>> have a problem that seems easy to resolve but I'm making hard work of
>> it, was hoping someone here can help me out. I have a simple component
>> I want to use on different pages in my application, and there's a
>> mixin associated with the select component in this simple component,
>> but I want to use a different mixin depending on which type of page
>> the component is located.
>>
>> so I have in my component.tml
>>
>> <t:label t:for="residentFeeInquiry" id="resident-label"/>
>> <t:select t:id="residentFeeInquiry"
>> t:validate="required" t:value="residentFeeInquiry"
>> t:model="senderHasIdSelectModel" t:encoder="senderHasIdValueEncoder"
>> t:mixins="mixin"
>> t:blankOption="always"
>> t:blankLabel="message:PLEASE_SELECT" t:label="message:RESIDENT"
>> tabindex="${getResidentTabIndex()}"/>
>>
>> and in my component.java
>>
>> public String getMixin() {
>> if (getContainer() instanceof SendMoneyTransfer) {
>> return "feefromresidentupdater";
>> }
>> return "singlesourceformfieldupdater";
>> }
>>
>> getting "Unable to resolve 'mixin' to a mixin class name". Have tried
>> prop:mixin, ${mixin}, ${prop:mixin} etc. to no avail, would like to
>> avoid having multiple select components with different mixins and an
>> if else(s) if possible?
>>
>> Thanks for listening! Brian.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic mixins
Posted by Paul Stanton <pa...@mapshed.com.au>.
Thanks Thiago, I'm sure I'll get one of your ideas to work for me!
posting on the list for prosperity.
On 7/11/2012 1:02 PM, Thiago H de Paula Figueiredo wrote:
> On Tue, 06 Nov 2012 23:26:25 -0200, Paul Stanton <pa...@mapshed.com.au>
> wrote:
>
>> On 7/11/2012 11:49 AM, Thiago H de Paula Figueiredo wrote:
>>> On Tue, 06 Nov 2012 22:41:17 -0200, Paul Stanton
>>> <pa...@mapshed.com.au> wrote:
>>>
>>>> .. and then if you have a combination of potential mixins, you end
>>>> up with n * blocks, with n * fields.
>>>
>>> Why don't you have a single mixin implementation that has the logic
>>> to handle all the situations? Maybe delegating method calls to other
>>> mixins?
>>>
>> Hey Thiago, that sounds like a good idea! How can I delegate to other
>> mixins though?
>
> Just regular, ordinary Java method delegation. The über-mixin would
> instantiate the normal mixins directly. Your über-mixin's
> setupRender() method invoking your regular mixins setupRender()
> methods directly. I guess you'll probably need to define a common
> interface for them all.
>
> Summary: just think of the problem in another way: if you can't have
> dynamic mixins, have a mixin dynamic enough to handle what you need.
> In other words, move the dynamic part to where doing dynamic stuff is
> easier.
>
> You could also apply all mixins in all fields and having the mixins
> somehow check whether they should actually do stuff or not depending
> on the component it was applied. @InjectContainer is your friend here.
>
> Another possible solution could be writing one or more
> ComponentClassTransformWorker2 implementations, which would analyze
> each component instance and apply or not the mixin. For that, take a
> look at the source of MixinWorker for some inspiration. On the other
> hand, this is only run when the pages are assembled, so you cannot
> control when the mixins are applied or not during rendering.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic mixins
Posted by Paul Stanton <pa...@mapshed.com.au>.
On 7/11/2012 11:49 AM, Thiago H de Paula Figueiredo wrote:
> On Tue, 06 Nov 2012 22:41:17 -0200, Paul Stanton <pa...@mapshed.com.au>
> wrote:
>
>> .. and then if you have a combination of potential mixins, you end up
>> with n * blocks, with n * fields.
>
> Why don't you have a single mixin implementation that has the logic to
> handle all the situations? Maybe delegating method calls to other mixins?
>
Hey Thiago, that sounds like a good idea! How can I delegate to other
mixins though?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Dynamic mixins
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 06 Nov 2012 22:41:17 -0200, Paul Stanton <pa...@mapshed.com.au>
wrote:
> .. and then if you have a combination of potential mixins, you end up
> with n * blocks, with n * fields.
Why don't you have a single mixin implementation that has the logic to
handle all the situations? Maybe delegating method calls to other mixins?
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org