PageRenderListener

[Jesse Kuhnert <jk...@gmail.com>]

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

Re: PageRenderListener

[Jesse Kuhnert <jk...@gmail.com>]

Oh cool, so he did fix that :) Yay! So, nevermind then. Thanks Leonardo.

On 3/23/06, Leonardo Quijano Vincenzi <le...@dtqsoftware.com> wrote:
>
> Jesse, this is a classic of mine.
> Check out MindBridge's recent issue fix:
>
> http://issues.apache.org/jira/browse/TAPESTRY-733
>
> --
> Ing. Leonardo Quijano Vincenzi
> DTQ Software
>
>
> Jesse Kuhnert wrote:
> > 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. :)
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>


--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.  http://opennotion.com

Re: PageRenderListener

[Leonardo Quijano Vincenzi <le...@dtqsoftware.com>]

Jesse, this is a classic of mine.
Check out MindBridge's recent issue fix:

http://issues.apache.org/jira/browse/TAPESTRY-733

-- 
Ing. Leonardo Quijano Vincenzi
DTQ Software


Jesse Kuhnert wrote:
> 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. :)
>   



---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Re: PageRenderListener

[Jesse Kuhnert <jk...@gmail.com>]

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 <fe...@alum.mit.edu> 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 <ry...@hyperstep.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >>
> >>
> >
> >
> >
> > --
> > 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>


--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.  http://opennotion.com

Re: PageRenderListener

[Fernando Padilla <fe...@alum.mit.edu>]

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 <ry...@hyperstep.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
> 
> 
> 
> --
> 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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org

Re: PageRenderListener

[Jesse Kuhnert <jk...@gmail.com>]

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 <ry...@hyperstep.com> 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: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>


--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.  http://opennotion.com

Re: PageRenderListener

[Ryan Holmes <ry...@hyperstep.com>]

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: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org