Dive into Oracle ADF

Send me a mail
 Dive into Oracle ADF   Click to see the XML version of this web page.   (Updated: 2/3/2008; 9:23:39 PM.)
Tips and tricks from Steve Muench on Oracle ADF Framework and JDeveloper IDE

Search blog with Google:

Search BC4J JavaDoc:

January 2008
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Dec   Feb

Get Firefox!

Tuesday, January 08, 2008

One of the improvements in the JDeveloper 11g Tech Preview 3 release is that we've re-enabled support for ADFBC refactoring. Let us know in the 11g Tech Preview Discussion Forum if you run into any trouble trying it out.

11:18:19 PM    

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    

© Copyright 2008 Steve Muench.