I'd like to see this as a javax.faces.component.UIComponent feature, not anything specific to one library.
-- Adam On 7/18/07, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>From: "Simon Lessard" <[EMAIL PROTECTED]> >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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > > Sent: Monday, July 16, 2007 7:24 PM > > To: MyFaces Discussion > > Subject: Re: [Trinidad] Renderer Listeners > > > > > > On 7/16/07, William Hoover <[EMAIL PROTECTED]> 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 h elpful 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: [EMAIL PROTECTED] > > > Sent: Saturday, July 14, 2007 12:30 PM > > > To: MyFaces Discussion > > > Subject: Re: [Trinidad] Renderer Listeners > > > > > > > > > On 7/13/07, William Hoover <[EMAIL PROTECTED] > 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 sure that 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:[EMAIL PROTECTED] > > > > 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 ta ble?) > > > > > > > > -- Adam > > > > > > > > > > > > On 7/13/07, William Hoover < [EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > > > 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, William Hoover < [EMAIL PROTECTED]> 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) { > > > > > > ... > > > > > > } > > > > > > }); > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
