I don't know, perhaps you were just quicker to catch on to the design pattern than I was.
I think the problem is with consistency. Mostly because IPage extends IComponent. If the IComponent interface methods were enough to encapsulate this logic then why do the Render<Foo> interfaces exist at all? I guess the pooling semantics could be said to be the reason, but the documentation and lots of other advice floating around mostly generally says " if you need to do something like initialization just add it to your pageBeginRender method". So what happens when you need to do the same exact thing to your component? Ie consistency. I'd rather learn one way of doing things and be able to treat components/pages the same way, thus re-using knowledge. Damned if I can remember the exact scenerio that really gave me problems. I think it was embedding forms in a component. Where the object being passed into the component with a containing form (via ognl bindings) was initially being hiber-managed by the page. jesse On 3/23/06, Ryan Holmes <[EMAIL PROTECTED]> wrote: > > I always assumed that the page<Foo>Render() methods are invoked before > and after the page render and not the individual component render, even > when implemented by a component (correct?). If so, then > Page<Foo>RenderListener seems like a perfectly good name for the > interface. > > If the interface was called Component<Foo>RenderListener, I would expect > its methods to be invoked before and after the implementing component > renders. > > Is this even what you're asking about or am I completely missing the > point? ;) > > Jesse Kuhnert wrote: > > >I'm not sure if this is what Mind Bridge fixed the other day, but just in > >case I thought I'd float it past the list. > > > >I personally ran into a lot of issues developing components because I was > >confused about the semantics of Page<Foo>RenderListener. Of course this > >interface only applies to the page itself, but it would be a lot nicer if > it > >were refactored into a simple Component<Foo>RenderListener sort of > semantic > >itself, only going to Page interfaces where the logic absolutely requires > >it. (as in pooling semantics and such) > > > >One use case for this was during development of components that > interacted > >with hibernate. Let's say I had a page, with component A on it. A would > >contain a primary key property for the hibernate entity being managed (as > it > >is of course horribly inefficient to just store the entity in the > session, > >at least in a lot of instances) ..So, my logic would be that upon begin > of > >render the entity would be turned whole again via a Session.refresh() or > >lock() sort of block. This worked great in Pages only, but once you start > >writing lots of components to "componetize" this logic it started > breaking > >down. > > > >I know it's possible to create the interfaces and follow some sort of > >semantic, and I also know the IComponent sort of generally provides this > >interface already, but it's misleading in a lot of instances because > people > >get soo used to the Page<Foo>Render semantics that it's not natural to > turn > >around and do it a different way with components. > > > >Am I being brain dead or does any of this make sense? > > > >-- > >Jesse Kuhnert > >Tacos/Tapestry, team member/developer > > > >Open source based consulting work centered around > >dojo/tapestry/tacos/hivemind. http://opennotion.com > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
