That might be true, we 'solved' the issue by simply using the afterRender in
the child class. According to the documentation
under:http://tapestry.apache.org/component-rendering.html the following is
written:
Parents before Child
Ordering is always parent-first. Methods defined in the parent clas
> wouldn't it be generally better if the @Import obeys the parent child order
Possibly, but I believe it's quite an edge case you have there.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands
It's not only our own components, we're using GoT5 and wanna extend some
components, as they use @Import on the class i can't use placeholder
methods. For some of our own components it's worth considering. Generally
we've the paradigm to only use @Import except the JS needs to be loaded due
to some
Or have the parent class invoke a "placeholder" method that is
overridden in the subclass to add further scripts after the base class
has added its scripts. Part of the design of Tapestry is that it does
not force you to use specific base classes, so you are free to design
your own that fit your n
This sounds familiar... I think that the solution was to use different render
phases to control the ordering of imports. Instead of putting @Import
statements at the class level, put them on render phase methods (eg
setupRender and beginRender) to control the ordering.
--
View this message in cont
I would imagine, similar to specifying the order of CSS, the scripts
that get added in the later render methods get added later.
e.g. scripts added in setupRender() will appear before scripts added
in afterRender()
On 12 July 2012 21:40, mem wrote:
> Hello,
>
> i've two Tapestry components whe
