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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dynamic mixins
On Tue, 06 Nov 2012 22:41:17 -0200, Paul Stanton p...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dynamic mixins
On 7/11/2012 11:49 AM, Thiago H de Paula Figueiredo wrote: On Tue, 06 Nov 2012 22:41:17 -0200, Paul Stanton p...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dynamic mixins
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 p...@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 p...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Dynamic mixins
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dynamic mixins
Hi,
thinking of the #1 mantra in tapestry static structure, dynamic behavior, I
guess you need to look for another approach.
Try adding the mixin to your component, not to the component inside of the
component. Maybe you need to change your implementation a bit (passing some
parameters) but it should work without an additional if clause.
Cheers
Christian
Am 09.03.2012 um 17:00 schrieb Brian Long:
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Dynamic mixins
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
