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]
