myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Hoover" <whoo...@nemours.org>
Subject RE: [Trinidad] Renderer Listeners
Date Thu, 19 Jul 2007 11:10:47 GMT
This sounds great! I think usage could extend well beyond debugging as well!
 
-----Original Message-----
From: Gary VanMatre [mailto:gvanmatre@comcast.net]
Sent: Wednesday, July 18, 2007 5:33 PM
To: MyFaces Discussion
Subject: Re: [Trinidad] Renderer Listeners


>From: "Adam Winer" <awiner@gmail.com> 
>
> I'd like to see this as a javax.faces.component.UIComponent 
> feature, not anything specific to one library. 
>
 
 
+1 That would be the place for it (JSF 2.0)
 
 

> -- Adam 
> 
> 
> On 7/18/07, Gary VanMatre wrote: 
> > 
> > >From: "Simon Lessard" 
> > >Yes, that would be awesome. I actually made a wrapper component doing just 
> > that in a project. >JSF 1.2 also allows that on 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 inte rfered 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 w rote: 
> > > 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 wrote: 
> > > > 
> > > > 
> > > > The problem with the tableSelecti on 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, Will iam Ho over 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 custo m 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 h 
> > elpful to fire some code before/after any component has been rendered- don't 
> > you? 
> > > > 
> > > > 
> > > > Actually , I wa s 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 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 in tent t o 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 su re tha t it's 
> > a good idea t o 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 i s 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 ta ble?) 
> > > > > > 
> > > > > > -- 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. 
> > > > > > > 
> > > > > > > -----O riginal 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 (necessari ly, be cause PPR relies on that!).

> > > > > > > What functionality are you trying to get here? 
> > > > > > > 
> > > > > > > -- Adam 
> > > > > > > 
> > > > > > > 
> > > > > > > On 7/13/07, Willi am 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 processRende rEnd(R enderEvent event)
{ 
> > > > > > > > ... 
> > > > > > > > } 
> > > > > > > > }); 
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > 
> > > 
> > 
> > 

Mime
View raw message