>From: "Adam Winer" <[EMAIL PROTECTED]> > > 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 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 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 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 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 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) { > > > > > > > > ... > > > > > > > > } > > > > > > > > }); > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
