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]
