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
