JSF Custom Components
•Als PPT, PDF herunterladen•
1 gefällt mir•2,233 views
This presentation explores and explains some concepts behind JSF/JSP Custom Components and how you might make them work for you.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie JSF Custom Components
Ähnlich wie JSF Custom Components (20)
Mehr von Michael Fons
Mehr von Michael Fons (9)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
JSF Custom Components
- 1. Some Examples Michael A. Fons Aderas
- 24. “ I want to use RichOutputText, Fred.” “ Our default render kit of oracle.adf.rich will help with that, Charlie.”
- 25. “ So we agree then: Charlie is a combineComponentType!” “ If that is how you feel, Fred, then we are agreed.”
- 26. <application> <default-render-kit-id> oracle.adf.rich </default-render-kit-id> </application> <component> <component-type> combineComponentType </component-type> <component-class> mfons.presentations.JSF.customcompdev.view.components.component.CombineSimple </component-class> </component>
- 27. I recognize all this!
- 28. private ValueExpression valueVE ; <attribute> <description> first value </description> <name> valueVE </name> <deferred-value> <type> java.lang.String </type> </deferred-value> </attribute>
- 31. @Override public void encodeEnd(FacesContext facesContext) throws IOException { ResponseWriter writer = facesContext.getResponseWriter(); super.encodeEnd(facesContext); encodeSecondField(facesContext); } RichOutputText embedded
- 40. oracle.adf.view.rich.component.rich.input.RichInputText inputComp = new RichInputText();
Hinweis der Redaktion
- EITHER: Aderas is a provider of professional services supporting the Department of Defense, Federal Civilian Agencies, Commercial Companies, and other technology integrators. The company specializes in implementing, extending, managing, and tuning Oracle enterprise applications, databases, applications servers as well as custom J2EE development. We are located in Reston, Virginia. OR: Company established about 5 years ago. Bright group of folks. Virginia-based Specializing in Oracle-based technology consulting. Database Development Web Development Oracle Application Development Framework APEX Oracle Financials
- I have been a JSF/ADF developer for 3 years Working with Java for 7 years A Web developer since 2000 An IT professional since 1990 Have worked in a variety of Oracle (and non-Oracle technologies) And are currently working for Aderas in Fairfax, VA on ADF assignment.
- And I am wondering are you… evaluating ADF/JSF for suitability in an upcoming project? an advanced technologist, who is afraid this topic might be too basic for you? a “declarative” ADF developer who wishes to learn more about advanced or programmatic coding in JSF, to appeal to potential job markets? At any rate: welcome, all!
- This is an Introduction to JSF Custom Component development. I will give Examples of Custom Component development, for illustration. These examples will be somewhat more complicated than “Hello, world” (so that they are at least somewhat useful).
- This first example should help you start thinking about some fundamentals of JSF custom components. Here you see a simple web page with 4 fields and a submit button. So…what’s behind these fields?
- Here is a code snippet from behind those four fields. This is JSP/JSF code. It is markup. It is XML elements/attributes, attribute value strings, and something called EL.
- This diagram further illustrates the mapping from JSP/JSF UI tags and components to web browser output. Multicomp:combine is a JSF Custom UI component, which I created recently. Each instance of this component maps to one input field on the web page.
- The point or purpose of the multicomp:combine component was to be able to use database meta-data to drive web page content dynamically. So database data would decide what kinds of components would appear on a web page, and in what order. But now the purpose this example provides is a good lead-in to my main point…JSF Custom Components development.
- We have a variety of things going on here in our JSF tag. We have Expressions or EL – Expressions like #{Combine.componentType} represent the returned value of a method named getComponentType() in a Class named Combine. Expressions like this are represented on the Java realm by objects called value bindings/expressions. We also have tag attributes: The Type attribute – … specifies what kind of field you will see in the browser. This attribute can also have constant values like “text”, “number”, “date”, and “list” – instead of EL. The Value attribute – … specifies the input/output value of the browser field. This attribute can also have a constant value. For the Listvalues attribute, – … if the value of “Type” attribute is “list,” then this attribute specifies what makes up the possible values in the list. (so this is a collection)
- One can build web pages using JSP/JSF technology. On JSF pages, JSF Components are the building blocks – like “multicomp:combine.” Different UI and non-UI components provide different outputs and functions to build with. Oracle ADF Faces/Apache Trinidad has around 50 components in its suite. The newer Oracle ADF Faces Rich Client library has around 300 different components. All of these are JSF “custom” components.
- Look at http://www.jsfcentral.org/ for examples of some other JSF custom component sources. There are lots of component-makers’ links, and component libraries to check out from this site alone! Some component suites are free or “open”; Some are not But all component makers are competing to have their components used in your JSF apps.
- Even so, you and your end users will have I.T. needs which nobody has yet predicted. This fact, combined with JSF’s inherent flexibility means YOU have more than enough reasons to learn and use JSF to build custom components. JSF is meant to work with just about any technology set. It is meant to render to any device. Just about any fundamental class related to JSF can be extended or re-implemented. So, you can fill the gap between your needs and what may be available commercially or through open sources.
- Creating a JSF component is a good way to learn… Java J2EE/JavaEE JSP/JSF. These will make you more valuable to many companies world-wide.
- Returning to our multicomp:combine component, which has within it a variety of field choices… This component is a little-bit like Oracle’s ADF Faces Rich Client -- Declarative Component feature This is a quick way to package up multiple components or a template for use by one or more applications. It is a great component, BUT… How would you build a Declarative Component of your own if… You could not use ADF Faces Rich Client because of licensing restrictions? OR You did not know about ADF Faces Rich Client? OR You did not like Oracle’s implementation of their Declarative Component.
- Our next example will be kind of like multicomp:combine, but it will be even simpler. This component contains two output text pieces. Adding input (read-write) ability adds complexity; so we will start with read-only…and move up to read-write.
- During this presentation, I will describe 4 major parts of JSF Custom Component development: The Component class… … is the Java code to control component behavior and (can be) how the component writes to the output device (like the web browser). The Component tag/tag handler class… … is Java code to map the JSP file to the component class The Tag library descriptor file… … is the Xml file to designate what is allowed and expected in the JSP file that uses this component And the faces-config.xml … … allows us to Register custom components for use
- You may have noticed my team members, who are helping me out here tonight… Here’s…Charlie, the Component Class! He’s a sort of compona-saurus…with, uh…red shoes.
- And here we have Torriador, the Component Tag Class! (He’s a vain creature…)
- … Lout, the Tag Library Descriptor file! (…he’s scary looking, but actually not that bad, once you get to know him)
- … and, Fred: the faces-config file!
- Our example is called “CombineSimple” Since our plan is to output two pieces of text, we will do this by using two different output text components combined into one custom component. But there are many output text components to choose from; which output text components will we use? This example combines h:outputText and af:outputText to make the new component. First, UIOutput is the component class for h:outputText, from the JSF standard component library. The other component we will use is RichOuputText from Oracle’s ADF Faces Rich Client; this is the component class associated with the af:outputText tag. We will extend UIOutput to create the CombineSimple class, and then embed the display of the Rich Ouputput Text inside of CombineSimple.
- I created this example using… JDeveloper 11g, and the Java EE template within Jdev 11g The Java EE template provides all the libraries and resource files the standard UIOutput needs; but RichOutputText also needs … The ADF Faces Runtime 11g library. The Trinidad “resources” servlet specified in web.xml. (In creating this app, we Could have used the Fusion template also; this would have provided everything both components need to work, but would have added a bunch of extra stuff we were not using as well.) As you can see, Charlie is getting everything he needs.
- Turning to Fred – the faces-config.xml, -- we see he has many jobs related to custom components. It turns out that Charlie needs to access a resource called “oracle.adf.rich” to keep his RichOutputText parts working properly. This resource is called a Render Kit, which is a class which includes a map of instances of classes called renderers, one of which controls how RichOutputText looks when it is rendered/drawn on the web browser page. (grouped by component family) So, for the af:outputText, we will use Fred (or faces-config.xml) to specify a default render kit of oracle.adf.rich for this app.
- Fred also keeps track of connections between some team members. The connection between Charlie and Torriador is established here by registering the component class (Charlie), and specifying a type identifier for this also. In this case, Charlie has the type, “combineComponentType”. This is because Torriador and Fred have agreed that this is the type Charlie has. This means: the getComponentType() method in the tag handler class returns the same String id as the component type element in faces-config.xml registration for our custom component. Furthermore Fred knows where to find Charlie…his virtual street address, if you will: Charlie’s full class name. The JSP/JSF runtime needs this information to know where to go next after processing the JSF tag we are considering in this example.
- So…for your reference, here is what Fred knows that applies to this example. In order, you see the default render kit, Charlie’s type to which Torriador referrs, and where to find Charlie in the classpath for this app.
- In Jdeveloper 11g, I added the following to a default JSF 1.2 page: An attribute/value pair to the jsp:root element, identifying our new tag library: xmlns:xyz=http://mfonsadf.blogspot.com/JSF/customcomp/combine I chose to name the component’s XML namespace of “xyz”, because I wanted to show that the name could be anything at all. The URL can also be anything at all; it is not a URL which points to an internet resource of some sort…it is just an identifier (in a URL format) which must match what Lout has! (Remember that Lout is our Tag Library Descriptor file, or TLD, for short.) Please also note the attributes we are passing to our component in this diagram; they are in the blue inner rectangle of our JSP Page diagram…with the first attribute being “the first value” and the second being “the second value ”
- Lout (or the TLD file)… can be easily created by using the menu options New Web Tier JSP JSP Tag Library, which is a wizard available in Jdeveloper. This file maps the reference of your tag library (in the jsp:root of your JSP page) and the particular tag you are using in that library, to the Component Tag implementation class (or Tag Handler class). this file also gives attribute tags which declare properties for the component; These attribute names match Torriador’s property names and accessor methods. (Remember: Torriador is the tag handler class).
- The tag handler class does several things: It’s setProperties() method moves the tag’s attribute values and value bindings into the associated custom component. It also maps the component type defined in the faces-config.xml to the renderer-type/renderer-class, if any; It helps map the tag reference in your page to the component class via the component type, which will match a component entry in your faces-config.xml file (see Fred in the picture?) The tag handler class is the place for accessor methods for each attribute of the tag; since this class may be accessed by multiple sessions at once, these methods are often “synchronized”.
- Component classes in general have the following functions: encode*() methods relate to generating the response (mark-up). The decode() method handles requests for the JSP page the component is part of (during postback requests only). Decode is not needed for this simple example, since our component only does output. Encode*() and Decode() methods can be separated out into a Renderer class as well, which would work with the component class.
- In this example, the purpose of this class is to … Extend UIOutput class and let default functionality take care of the first component’s functionality (h:outputText). After UIOutput is finished generating its response in an overridden encodeEnd() method (using super.encodeEnd()), Charlie, our custom component class, generates response for the second component (RichOutputText/af:outputText) by calling a new method named encodeSecondField().
- So here is our generated web page! Remember these values from the slide showing the JSP call to this component? These two strings shown here were passed in as attributes to our component’s tag.
- To review, here is the big picture. Do you need a minute to review this?
- For your reference, I will include the full code of this first example…. This is the TLD file we are using. (Hi, Lout!) Note: where it says the values of the attributes can be “deferred”; we’ll talk a bit more about that in a minute.
- Here’s Mr. T, first page…
- Here’s the second half of Torriador.
- Here is the first part of Charlie, our component class.
- … and his latter half. Note that since our RichOutputText is an embedded component within another component, the embedded component needs an Id to be given to it, in order for it to work. We will also talk more about this in a minute.
- And clearly Fred is a man of few words…especially on this project.
- The first example was very simple, because our component only did output. So, in our next example: we will produce another combined tag but, this time, with an UIOutput and RichInputText. (In JSP, the equivalent tags would be h:outputText and an af:inputText.) So, what happens if we just replace the embedded output text object for an input text object in our Component class? Altering this single line of code…see the bottom of the screen… … Gives us what you see here…
- So…We got an input field to display. More helpful would be if the input was part of an HTML form that could post and do something! So what do we change in our custom component to… … have a submit button to post changes? And to make the input field’s default value one that prompts the end-user to do something with this screen? And to make our output text display the posted input field’s value, after we submit it?
- To get the button, add a call to a method to encode the button in the custom component’s encodeEnd method after the call to encode the second field… This method, encodeSubmitButton(), is defined as shown. And it produces output, as shown, beneath it. Notice ResponseWriter methods allow us to write XML/HTML elements and attributes, in a reasonably intuitive coding format.
- In the jspx file we first change the value of the second tag attribute called “value2VE”, to a more appropriate default value of “Type something!”; this tag attribute controls the default value of the input field for this component. This is shown as OPTION 1. For OPTION 2: since we defined these values in the TLD file (that is, in Lout) as “deferred values”, we could have also used EL here instead of “Type something!” The result of the second version would be to use, as a value for attribute value2VE, the value returned by calling getInitialValue() in the Java class “myBackingBean”.
- Up to now we have done nothing with the component decode() method, because output-only components have no need for such a method. Using decode(), on a postback, we will capture the input field’s value from the request parameter map. (A postback is when you submit a form on a web page, and then when the web page re-renders, you still are on the same page.) Since we are getting our input value from the request parameters, this means that the value of the “name” attribute of any input elements in the HTML which this component generates is now very important, since we need to track field values from one request to another. We can somewhat control the id’s and names of the different tags that are rendered for our component; for embedded components the value of the name attributes in these tags is derived in part from our specified id value. The input elements’ names turn into the key names in our request’s parameter map. By viewing the source in our web browser, we see that our setId(“_second”) resulted in the following markup. (see the screen)
- Like most things, there are some things that people call “normal”, and then there is “reality”. In most cases when you have an input field as part of a JSF custom component, you will extend UIInput. But Charlie, our component, is extending from UIOutput for some reason. This makes our decode a bit abnormal, since we cannot use the setSubmittedValue() method of the input component here, because we create the input component on the fly. Normally, we would call the setSubmittedValue() method of the component here in decode() in order to give our input component a value to validate and process in the JSF lifecycle. But we will not even create our input component until the encode*() methods fire, which happens later in the lifecycle… So, we improvise: we actually set the value of a component property called postbackValue2 to contain this submitted value. Then, when it comes time to encode this input value, we will have a value with which to set the input component’s submitted value. The point of a component having a submitted value is to act as a starting point for the value that is bound to an input field. This value always starts out with a datatype of String, since it comes from a request parameter, but for a component the value may be converted and validated over the course of the JSF lifecycle.
- Another odd thing about this decode() method is that we have to work extra hard to find the request parameter map key of the input field in our component. Primarily this is because the ADF Faces input text component puts “::content” suffix on the end if its id. (the input text component is often used in a panelForm component where it has a separate “label” section. The “label” part of this component is suffixed with “::label”, since using suffixes to differentiate sub-elements in generated component output is standard practice in JSF component development.) Another piece to the puzzle is that, for custom components that accept input, they will need a HTML <form> tag in the eventual encoded HTML in order to be able to do a submit of the value in this input field. The way to get this form element, generally, is to use an <h:form> or <af:form> (or similar) to produce this html.. <h:form> is part of the JSF spec implementation, so it is often used by default for this purpose. <h:form> has a side-effect that all the id’s nested within the HTML generated by the components within the <h:form> will be prefixed with the id of the <h:form>. So…my process for finding the key to look through the request parameter map for my submitted value is (finally) to find the “form” id part of the “clientId” of this component, then to append my known “id” which I will later give my input text part in the encode method for this component. This process allows me to obtain the submitted value and display it in the output text portion of my component by simply setting my components value to the submitted value, which we recorded during decode().
- As I said, we added a property called postbackValue2 to temporarily store the value posted back from the input field; Also in encodeSecondField(), we alter the value of the input component if a value has been posted back. Additionally, we are doing a setValue or setValueExpression, as we would have in the tag handler’s setProperties() method…only we are doing it right here in the encode process of the component.
- Here is our end result.
- (Check time, and do demo if appropriate.) The “team” wants to know if that is all I am going to say? For now yes. This team is capable of so many things. They are an extremely flexible bunch. Lots of variations are possible. For example, it is possible to take an existing tag and make it look completely different for your purposes by using another team member call Rodney, the Renderer. Rodney’s father, Robert, the RenderKit also fits into this strange scenario. Another variation involves not even using a decode to handle input, but instead using ajaxian techniques which uses another friend Phoebos, the PhaseListener. He is a bit like Robin Hood: he likes to hijack requests to provide “resources” for the team…resources like data files, or Javascript files, or cascading style sheet files.
- Any questions? Hopefully this presentation has been informative. I have listed some references on the next slide for your study. I hope you learn a lot this week. Have a wonderful week.