()
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 d
On 7/11/2012 11:49 AM, Thiago H de Paula Figueiredo wrote:
On Tue, 06 Nov 2012 22:41:17 -0200, Paul Stanton
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
On Tue, 06 Nov 2012 22:41:17 -0200, Paul Stanton
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
.. 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
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 (e
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
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
