Hi .

I am facing the same problem.
I think the problem would be solved if we could gain the HttpServletRequest.
If we could get the request , then we could access the app mod
using the ADF Model , i mean by getting the binding container of the current page.......

But i have not seen any example that access the Request.

Please help.

Thank's.

Ok, I'm lost.

Can someone post some sample code that would spell out for me how I can access the application module or view object being used by a jsf page.

Thanks...

This early access 1 release is thin on doc in this area, but we've made most cases declarative now with new declarative control in the page definition.

What is the page definition? It's a slight generalization of what we previously called the UIModel at design time. It's still known as the BindingContainer at runtime.

You can get to the page definition for any page by using the right-mouse "Go to Page Definition" menu item.

The page definition is an XML metadata file just like the UI Model file was. A few key differences in 10.1.3 are that the file is now XML Schema based, and tied into our generic XML Schema-driven editing infrastructure so you can use the structure pane or code editor to perform schema-driven editing of the file.

The declarative way to bind an action binding to a method in a data control is still to create an action binding. To do this explicitly, first right-mouse "Go to Page Definition" while editing your JSP/JSF page. The XML file representing its page definition appears in the code editor, and the structure pane shows its structure. Select the "bindings" element (has a folder icon) in the structure pane, and right-mouse "Insert inside bindings > methodAction". Click on the root YourAppModuleDataControl node, and in the poplist select the "yourMethod" method. The "Action Binding Editor" dialog that appears shows you the arguments to the method and gives you a place to enter the EL expressions that will declaratively provide the values for each argument at invocation time. This same thing would get created for you implicitly if you dropped the "yourMethod" method onto the page from the data control palette, say, as a Command Button or Command Link. Doing it this way, it's not automatically wired to a UI control yet.

Now you have an action binding that is declaratively configured to invoke the method in question. By default the action binding will be named the same as your method.

You can leverage a new feature in 10.1.3 ADF binding layer called the "invokeAction" to invoke any action binding during any phase of the page lifecycle. In particular, you might want it to invoke your "yourMethod" action binding you just created. If no UI control is wired to the action binding, it's not going to "fire" any any automatic way based on a UI gesture, but the invokeAction can invoke it declaratively as part of the page definitions "executables" section.

The "executables" section is something you will have already in your page def if you have any iterators. Since these get implicitly executed, we've tried to make this more clear by grouping them into a category of "executables" and providing new declarative control over this implicitly executed things. In particular, anything that can appear in the "executables" section of your page definition has two important properties "Refresh" and "RefreshCondition". Refresh defines when this "executable" thing will be implicitly refreshed, and RefreshCondition gives you an optional place to enter a boolean-valued EL expression that can help further decide whether the "executable" thing will execute or not. If the expression is missing, then it evaluates to true. If the expression is present, the "executable" will only be implicitly executed by the binding layer if the expression evaluates to true. The Refresh property itself gives you declarative control over what phase of the lifecycle things should get executed. "prepareModel" is a good one that will make sense to folks who have used 10.1.2.

So, if you insert an "invokeAction" executable inside the "executables" section of your page definition, give it a name/id, pick which action binding it should invoke, and set the "Refresh" property to a different value (if appropriate), you'll be in business.

Also,

If you were invoking an application module method just to set bind variables in a more structured way, another of the cool new features in ADF Business Components for 10.1.3 is the full support for proper named bind variables, including support for binding their values declaratively in the ADF binding layer.

Try defining a few named bind variables, referencing them using :TheNameYouChose (in any order and number of occurrences) in the SQL query, and then you'll see that a new built-in action named "ExecuteWithParams" appears for that view object in the data control palette. If you expand that you'll see the named parameters and can drop them onto a form to create a parameter form. If you drop the "ExecuteWithParams" action as a button, then clicking that button will execute the query and pass the bind parameter values declaratively, too.

The regular "ExecuteQuery" built-in action still re-executes the query, but without causing the bind parameters to be rebound.

The answer to the original question in this thread is that currently in the EA1 release, you'll need to access the current binding container from the requestScope either programmatically or by evaluating a faces value binding. Just like in 10.1.2, you can access it as an attribute named "bindings".

We're experimenting with various techniques to improve the usability of this for 10.1.3 production, including having the bindingContainer injected into the backing bean using JSF managed properties, and other ideas.

You dont' need to write code to achieve this, or actually even have a backing bean at all.

You can just expand the CountriesView1 and drop its "Next" built-in operation as a commandButton.

The auto-binding feature for JSF pages is off by default because most of the time with JSF and ADF you don't actually need it. It's also a little bit confusingly worded because it's not the same kind of binding as the ADF binding layer is doing. What the auto-binding feature there (again, off by default!) is doing is, for each control in your JSP of JSPX page, automatically creating the following in the automatically generated backing bean class:

-- a member variable of the right type
-- getter/setter methods for this member of the right type

These are useful if you want to invoke methods on your UI components, for example, conditionally change the background color of some field based on some custom code.

For any kind of interaction with your back-end business service, that can all be done declaratively when you couple JSF and ADF, so in practice you won't really need
The JSF spec uses the notion of a bound component to mean binding the UI controls on your page to properties of a managed bean.

I've blogged a link to a working example of referencing bindings and the binding container from a JSF backing bean here:

http://radio.weblogs.com/0118231/2005/09/29.html#a606

For the EA1 release, this is the right place to report them.

I've reproduced your problem and the developers are looking into it. It's related to the fact that when you use auto binding, you have components in your page with their "binding" attribute set to a property in the backing bean that exposes the UI component to programmatic manipulation -- think, setting a field's background green under certain conditions, or something. When there are UI components with a JSF binding attribute set, then the JSF "RestoreView" phase kicks in and in that phase, for some reason, the "#{bindings}" expression is evaluating to null, so it's properly performing the injection of the managed property, but it's injecting null.

I'll update this thread if the devs identify a workaround.