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
