A reader wrote in to ask about ADF Model page definition variables, wondering if he could use them instead of having to define a JSF backing bean just to hold onto temporary values.
The answer is a big, "yes". In fact, ADFM design time automatically creates page definition variables for you whenever you setup an ADF parameter form for a method binding or ExecuteWithParams operation.
If you have worked with Struts before, then declaratively-configured, named variables in the ADFM page definition XML file are conceptually quite similar to the declaratively-configured, named properties in a Struts DynaActionForm. ADFM models page definition variables as attributes in a rowset containing a single row. The special ADFM iterator binding implementation called the "variables iterator", behaves as if its current row were always pointing at this one row of variable values. You would be justified in wondering, "Why do you model variables in this weird way?" The answer is easy. By modeling things this way, any kind of ADFM binding that works with attributes in an iterator can also work with page definition variables in exactly the same way. For example, after creating a page definition variable named "Quantity" in the executables section of the page definition (as a child of the variableIterator iterator), you can use an attribute binding (related to an inputText field, for example) and bind it to the Quantity attribute in the variableIterator iterator binding, just the same as you could use the attribute binding to bind the text field to a "Price" attribute in an iterator related to a view object in the data model.
The page def variables are therefore defined by inserting <variable> or <variableUsage> elements as children of the <variableIterator> iterator binding in the <executables> section of the page definition. Each <variable> element requires a name and type property. You use this kind of variable when you want to define the place-holder right in the page def itself. If instead, you are working with a component like a view object that itself already supports variables (like it's named bind variables), then the <variableUsage> provides an alternative way to define the page definition variable by referencing a model-layer component's existing variable. This, for example, allows the page def to infer the data type and any UI hints at runtime from the view object's bind variable automatically.
If you currently have no page def variables, you can create one using the Structure Window for the page definition in question. If no "variableIterator" iterator exists in the "executables" section, you'll need to select the "executeable" section and click Insert Inside > variableIterator from the right-mouse. Then, select the "variables" node you just inserted, and again "Insert Inside > variable" from the right mouse to create a new variable.
After doing that, if you want to ceate an attribute binding in the "bindings" section, by choosing the "variables" iterator, you can pick the appropriate attribute/variable in its "current" (and only!) row to bind to.
3:37:42 PM 
|
|
