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
wrote:
On 7/11/2012 11:49 AM, Thiago H de Paula Figueiredo wrote:
On Tue, 06 Nov
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
