« ADF Faces: How-to define a default device for the ADF Faces Telnet Renderer | Main | Trinidad: Apache MyFaces Trinidad Core 1.2.1 for JSF 1.2 released »
ADF Faces RC: Dynamically showing/hiding components with JavaScript
By frank.nimphius | July 5, 2007
The following usecase is from the Oracle JDeveloper 11 forum on OTN: An ADF Faces Rich Client form (Ajax) should contain a component that is conditionally displayed or hidden depending from a value typed into a input text field.
Ric Smith from our team answered that this could be done by using an autosubmit=true property on the inputTextfield, in which case each key stroke will get reported to a managed bean in a ValueChange event. This is true – no doubt about it – but made me wonder if this isn’t a usecase that could be managed best with the JavaScript API in ADF Faces of JDeveloper 11.
Note that the following code is not optimized and I don’t yet have an idea whether or not this is best practices – I am still exploring the options that are provided by ADF Faces RC. One implementation detail of this example that you don’t want to copy into your applications is that I am using obtrusive JavaScript, meaning that I am adding my JavaScript code in a non generic fashion to the JSF page. For better re-use and – for sure best practice – you want to build a JavaScript library to use with ADF Faces RC (and also soon to be Trinidad RC) that is non-obtrusive using generic JavaScript eventing. I’ll keep the topic of JavaScript best practices for a possible how-to or whitepaper to write.
One benefit that the JavaScript implementation provides over the solution Ric suggested is that I don’t send unnecessary events to the server if e.g. the usecase is such that I want to show a command button if a field contains values. In this case I can stop sending events after the first letter being typed and send another one when the field is emptied.
What I did to implement the usecase is to provide a value to the text field and the button’s ID property. The buttons’ Id property is what I access through the AdfPage object to call a method on the adfRichCommanButton object. The text field’s Id is accessed through the document.getElementById() field because I don’t need a component reference but a HTML field reference. In addition, I added an af:clientListener to the inputText field. As you may not yet know, ADF Rich Client components – though Ajax – don’t necessarily have a client object. This is a design decision that our ADF Faces development team wisely did for performance reasons. Adding a clientListener component enables the creation of a client object so that you can selectively enable client behavior for components.
Being security paranoid, I like this design decisions from a security perspective as well. You simply cannot hack components through their JavaScript representative client object if the object doesn’t exist. Wondering if I should put this on a feature list for ADF Faces RC because not all Ajax component library designers think that far.
Back to the main topic and the usecase.
 |
As shown in the image above, the clientListener calls the “enableDisableButton” function whenever a key is pressed.
Note the inputText field element ID, which is “inputTextField1::content”. If you debug ADF Faces RC views with Firebug then you recognize that the text field component is rendered as a table, which has a HTML input component with the id of inputTextField1::content.
 |
Note that I could have disabled the button on the client as well using document.getElementById() but then the state wouldn’t be updated on the JSF component, which means that re-loading the page would again show the button.
Frank
Topics: ADF Faces RC | No Comments »
Comments are closed.