Hmm..I guess my points are all moot until I find the example I had in mind. I'm working towards some fun all nighter stuff right now so I'll either bring the thread back up this weekend when I find it or quietly hope everyone forgets I started it if my example was just implemented incorrectly. :)
On 3/23/06, Fernando Padilla <[EMAIL PROTECTED]> wrote: > > I have been using this interface in pages, and I think even components. > Essentially if you implement the interface you're asking tapestry to > add you as a listener automatically for page rendering events ( at the > begin or end of rendering, both during rewind and regular ). > > So no matter if it's a page or a component, you'll get called by > tapestry before the render starts, or after it ends.. but only if you > implement the interface. > > So I think this interface is correct, and it's expected behavior is > consistent with it's naming.. now the implementation might not be > consistent.. :) but it has remained consistent for me so far. :) > > > So how did you get confused: The question is who keeps the list of > listeners, and who notifies them. That could be the root of the > confusion. I think it's implemented by AbstractPage ( I'm not checking > code right now, so don't take my word ). I can't remember where the > listener list was maintained.. so maybe you were doing something fancy > that confused it. Maybe you overrode a method in AbstractPage that > actually went through and notified all of the component listeners.. > > > > Jesse Kuhnert wrote: > > 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 > > > > --------------------------------------------------------------------- > 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
