>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 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: [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 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:[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 table?) > > -- 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 (necessarily, because 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 processRenderEnd(RenderEvent event) { > > > ... > > > } > > > }); > > > > > > > > > > > >
