myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gvanma...@comcast.net (Gary VanMatre)
Subject Re: [Trinidad] Renderer Listeners
Date Wed, 18 Jul 2007 20:20:10 GMT
>From: "Simon Lessard" <simon.lessard.3@gmail.com> 
>Yes, that would be awesome. I actually made a wrapper component doing just that in a project.
>JSF 1.2 also allows that on <f:view> which is better than nothing, but support on
most component >would be more useful and interesting to trap evil components not acting
like expected.



We tried something similar for the shale's "commons" validator.  This was an attempt to add
the ability for a validator to participate in rendering for client-side support.  We hooked
into the render kit [1] and wrappered renderers of the command [2] and input [3] families.


At first this seemed like a great trick but later interfered with tomahawks PPR.  The PPR
of tomahawk uses an interface implemented by the renderer that we were hiding.  I suppose
this would be OK if it was tuned specifically to a component library.

 
[1] http://svn.apache.org/viewvc/shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/faces/ValidatorRenderKit.java?view=markup
[2] http://svn.apache.org/viewvc/shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/faces/ValidatorRenderKit.java?view=markup
[3] http://svn.apache.org/viewvc/shale/framework/trunk/shale-validator/src/main/java/org/apache/shale/validator/faces/ValidatorInputRenderer.java?view=markup


Gary

On 7/18/07, Adam Winer <awiner@gmail.com> wrote: 
BTW, one thing I thought of recently is that it could be really 
handy for JSF debugging to support attaching component-level
phase listeners (render, and other phases), so you could
set a breakpoint at, for instance, "Before my table renders". 
Or "After this input field validates".  That'd be a generalization
of a render listener.  The trick would be doing this in a way
that doesn't drag down performance overall, which might be a lot 
easier if the overall UIComponent API were overhauled...


-- Adam




On 7/17/07, William Hoover <whoover@nemours.org> wrote: 
The problem with the tableSelection is that I can't ensure that the page will always be using
a table component for the list, but I think I might have a solution. Thanks for the help though!

Concerning the render listeners... I can understand your concern. I was thinking that another
solution (correct me if I'm wrong) might be using the "RenderStage" to track this. When a
new stage is set any listeners that are registered will be notified by a render event... Just
a thought :o) 

-----Original Message-----
From: Adam Winer [mailto:awiner@gmail.com]

Sent: Monday, July 16, 2007 7:24 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] Renderer Listeners


On 7/16/07, William Hoover <whoover@nemours.org> wrote: 
The intent is to track selections. It seems like a lot of extra work to maintain quite a few
tr:inputHidden components just to capture selection values. I see what your saying about post-processing
a pattern in JS, but I don't think that searching through table for fields might be the best
solution :) 

 For selection the Trinidad table has a built-in selection mechanism - tableSelection="single|multiple".
 Might not be the UI you love best, but it works.



It seems like a cleaner and less error prone solution would be a renderer listener that can
be invoked in either the encodeBegin() or encodeEnd() methods in the base component. That
way a custom component isn't necessary. All I would have to do is set the renderer listener
on the link component to process after the link has been rendered, capture the UIParameter
values (they will not be null at this stage as they were before the link was rendered), and
use them in a JS call to populate the selection input (as described below). I think this approach
would minimize the amount of work it takes to implement a custom component, and I'm sure that
code execution would be more efficient than adding a new component to the mix everytime that
a developer needs some code to execute before/after a component renders. I can see quite a
few scenarios where it might be helpful to fire some code before/after any component has been
rendered- don't you? 

Actually, I was imagining one custom component that exposes a generic "before/after rendering"
listener API.

My concern about adding this to all components is that adding overhead to every component's
rendering + state saving performance when only a small minority actually use the functionality
is very worrisome.  I've very rarely encountered the need for what you're going for. 

-- Adam

 


-----Original Message-----
From: Adam Winer [mailto: awiner@gmail.com]
Sent: Saturday, July 14, 2007 12:30 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] Renderer Listeners


On 7/13/07, William Hoover <whoover@nemours.org > wrote:
> As you guessed it, there are links within each table row that contain a f:param that
holds data for that row. When the user clicks on that row I need to update a separate input
field (outside the table- inside the same form) with the value from the f:param. I need this
to happen on the client side before the page submits. 
>

That, I don't get.  Is the intent to track selection in some way?
Couldn't you just stick a tr:inputHidden in the row and grab that
value on the client, copying it into that separate input field?   Or, 
for example, running some post-processing in JS (search for fields in
the table that match a pattern).  Etc.,  there's gotta be a better way
of handling this.

Alternatively, you could write a simple component of your own that 
doesn't render anything, but gets inserted into the table;  you
implement its encodeBegin() to
do your stuff.

-- Adam


> I know that I can make this happen using EL in the link's onclick attribute based upon
the current row data and the separate input field id ( i.e. onclick="javascript: setInputValue('separateInputFieldId',#{row.someValue}';"),
but I have a table view that gets reused quite a bit that may or may not need this feature
based upon individual needs. Also, I'm not sure that it's a good idea to capture the client
id for the separate input field in this manner due to the client id dependency on naming containers.
That's why I'm looking for a programmatic solution that will add the needed javascript call
on an as needed basis before the link/param are rendered outside the jsf page. 
>
> -----Original Message-----
> From: Adam Winer [mailto:awiner@gmail.com]
> Sent: Friday, July 13, 2007 3:24 PM
> To: MyFaces Discussion
> Subject: Re: [Trinidad] Renderer Listeners 
>
>
> Well, that's what you're doing, but doesn't quite explain
> (A) why the value is null until the link is rendered (though
> I'm guessing that's because its value comes from the 
> table data)
> (B) why you need to get the param value for this specific
> command link within this table (or a specific row
> of the table?)
>
> -- Adam
>
>
> On 7/13/07, William Hoover < whoover@nemours.org> wrote:
> > I am trying to get a f:param value from a CoreCommandLink, but the value is null
until the link has been rendered.
> >
> > The link is inside a tr:column- if that helps. 
> >
> > -----Original Message-----
> > From: Adam Winer [mailto:awiner@gmail.com]
> > Sent: Friday, July 13, 2007 2:42 PM
> > To: MyFaces Discussion 
> > Subject: Re: [Trinidad] Renderer Listeners
> >
> >
> > There's no event listener, but there is that ResponseWriter
> > API, which will get passed components on startElement(). 
> > 99% works (necessarily, because PPR relies on that!).
> > What functionality are you trying to get here?
> >
> > -- Adam
> >
> >
> > On 7/13/07, William Hoover < whoover@nemours.org> wrote:
> > > I don't suppose there are any event listeners that can detect when components
are being rendered? It would be nice if there was a way to be able to... 
> > >
> > > component.addRendererListener(new RendererListener() {
> > >         public void processRenderBegin(RenderEvent event) {
> > >                 ...
> > >         } 
> > >         public void processRenderEnd(RenderEvent event) {
> > >                 ...
> > >         }
> > > });
> > >
> > >
> >
> > 
>
>





 
Mime
View raw message