Ok, I added my vote to the bug report.
The suggestions you, Eric and Jeff suggested are good workarounds, and easy to
implement. In fact, I'll probably use one of those to get working in the
meantime.
But this is one of those areas where one naively uses Tapestry functionality
only to be tripped up by quirky unpredicted behaviour that runs counter to
expectations. The more I use Tapestry the more of these quirks I find, and it
is these which really slow down development time because one spends ages
debugging application problems, only to find it was caused by unexpected
framework behaviour. This is not to complain or to imply any disillusionment
(because I'm in no hurry to switch to JSF or Shale), but rather that we
should aim for a clean predictable framework free of these sorts of quirks.
regards,
Scott
On Thu 5 January 2006 01:00, Leonardo Quijano Vincenzi wrote:
> Actually I received that advice several times. Although I know it's the
> one of the best workarounds for this problem, it's still bloated.
> I actually implemented my own listener logic that gets called from the
> top page's pageBeginRender() method, making my components implement an
> interface and calling their listeners in a cycle:
>
> public void pageBeginRender(PageBeginRenderEvent e) {
> for(Component c : getComponents().values()) {
> if(c instanceof MyInitializationInterface) {
> ((MyInitializationInterface) c).onInit(...);
> }
> }
> }
>
> You still have to repeat this on all of your components, but at least
> it's cleaner than the lazy init pattern. It makes me wonder why Tapestry
> didn't implement this in the first plane. It could be actually faster.
>
> (The lazy init pattern main problem is that you get lots of getXX()
> functions with unclear side effects - a big code smell IMO).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
