What is a key difference between JSF request scope and ADF backing bean scope?
Well, the "lifetime" of these two scopes is exactly the same. However if you need to create a backing bean for an ADF declarative component, the you will need to use backing bean scope for that managed bean. This enables using multiple instances of your declarative component in a single ADF page...something which the JSF request scope does NOT support.
(Please see the comments on this blog entry for an additional function of Backing Bean Scope as relates to regions and bounded task flows; many thanks to Chris Muir for pointing these things out.)
This site promotes and supports the development and deployment of JSF, Oracle ADF applications, and other web development topics. If you have interesting facts to share about any of these or any related technologies, please feel free to post a comment.
Thursday, January 27, 2011
Wednesday, January 26, 2011
Refresh Data Controls in JDeveloper 11g
If you are looking on your ViewController project and you do not see new columns you have added to your business components, press the refresh icon on your Data Controls pane. It is very important...this is not just a convenience...to hurry something along that just has not happened yet in the due process of polling or whatever other triggers might be used in the inner sanctums of JDeveloper. This refresh action is more like, the View does not even recognize the changes until this refresh button is pressed.
Perhaps it is just the way I am using JDeveloper, but this seems to be a very helpful thing to know, if you are used to JDeveloper 10g.
Perhaps it is just the way I am using JDeveloper, but this seems to be a very helpful thing to know, if you are used to JDeveloper 10g.
Thursday, January 20, 2011
JSF 2.0 observations on JavaScript format for Ajax
I notice that on the version of JSF 2.0 I have on GlassFish, that the jsf.js page may not be included to make a call to jsf.ajax.request(), if you need access to this function. I guess in that case you would either add a do-nothing f:ajax tag to your JSF file, or do some include of the jsf.js library programmatically. The former option may be better.
Also I noticed that if you want to key in on a non-default event when calling jsf.ajax.request() that you will need to create an object for the last parameter that includes the property javax.faces.behavior.event...but be careful: you will get a JavaScript error if you try to do this all in line without some extra work. Property names typically do not have periods in them ("."). So you have to do something like the following:
Also I noticed that if you want to key in on a non-default event when calling jsf.ajax.request() that you will need to create an object for the last parameter that includes the property javax.faces.behavior.event...but be careful: you will get a JavaScript error if you try to do this all in line without some extra work. Property names typically do not have periods in them ("."). So you have to do something like the following:
...onkeyup="var lArgs = {}; lArgs['render'] = 'form:output'; lArgs['javax.faces.behavior.event'] = 'keyup'; jsf.ajax.request(this,event,lArgs);"
Labels:
f:ajax,
JavaScript object properties,
JSF 2.0,
jsf.js
Saturday, December 25, 2010
Friday, December 17, 2010
JSF 2.0 paper coming
I am on the hook to present JSF 2.0 New Features presentation to the NoVAJUG February 17 or so. It should be fun. JSF 2.0 is really cool. I will publish this presentation to slideshare when I get it fleshed out.
J-Integra
On the project I am at now we are using a product called J-Integra for COM. It allows us to control Excel (in our case...probably any MS Office tool) through DCOM in Java. We tried things like Apache POI and Actuate BIRT Spreadsheet Engine/API first, but the spreadsheet we had to control had visual basic macros in it which called C++ DLL's. And Java does not (yet) understand anything about VBA, so those efforts did not work for us.
The set up of J-Integra is fairly minimal. There is a license xml file which is emailed to you upon request, and you must rebuild their product's JAR files using their JAR rebuild command. Then you have 30 days.
At that time you can run something called comtojava (I think) and it generates a great many java/class files which do the DCOM calls. There are also a lot of interfaces in there defined.
The result is that you can open/create a workbook, manipulate it, and close the book. The opening actually opens a copy of Excel, so you have pretty much complete API access. It is almost like a testing tool.
Hope this helps.
The set up of J-Integra is fairly minimal. There is a license xml file which is emailed to you upon request, and you must rebuild their product's JAR files using their JAR rebuild command. Then you have 30 days.
At that time you can run something called comtojava (I think) and it generates a great many java/class files which do the DCOM calls. There are also a lot of interfaces in there defined.
The result is that you can open/create a workbook, manipulate it, and close the book. The opening actually opens a copy of Excel, so you have pretty much complete API access. It is almost like a testing tool.
Hope this helps.
Friday, October 29, 2010
kudos to JSF 2.0's f:ajax tag!
It has been verging on too long since my last blog entry.
I have been reading in JSF 2.0: the complete referece by Burns, Schalk and Griffin about the f:ajax tag, and the Ajax implementation in JSF 2.0.
It's really cool.
Here is my background with Ajax. I have implemented Ajax solutions in JSF apps using straight JavaScript. This was kinda hard but not too bad actually. But I am fairly comfortable with JavaScript. I have also worked with the JSF Blueprint auto-suggest component. This worked out rather well and hid much of the details of the JavaScript functionality behind a JSF component. I have also studied a bit more than half of Deepak Vohra's book Ajax in Oracle JDeveloper and seen what a huge number of ways there are to do Ajax...and that is just with Java! I have also been working with ADF 10g's PPR solutions and my own frame/iframe kluges for years as well.
I really like the simplicity of the f:ajax tag. For starters, I love that you can get some basic, useful Ajaxian functionality simply by including the f:ajax tag either inside or wrapped around you JSF tags! This basically would do the equivalent of submitting those fields when the default event for those JSF components fires. The default JavaScript client event for a component is a sensible value depending on whether it is an action component or a value-change component.
Then it is possible to have all the flexibility of doing Ajax from raw JavaScript.
It is certainly much much easier than having to construct a bunch of JavaScript then do a bunch of request hijacking from a PhaseListener, like in JSF 1.1 and 1.2.
Thumbs way up guys!
I have been reading in JSF 2.0: the complete referece by Burns, Schalk and Griffin about the f:ajax tag, and the Ajax implementation in JSF 2.0.
It's really cool.
Here is my background with Ajax. I have implemented Ajax solutions in JSF apps using straight JavaScript. This was kinda hard but not too bad actually. But I am fairly comfortable with JavaScript. I have also worked with the JSF Blueprint auto-suggest component. This worked out rather well and hid much of the details of the JavaScript functionality behind a JSF component. I have also studied a bit more than half of Deepak Vohra's book Ajax in Oracle JDeveloper and seen what a huge number of ways there are to do Ajax...and that is just with Java! I have also been working with ADF 10g's PPR solutions and my own frame/iframe kluges for years as well.
I really like the simplicity of the f:ajax tag. For starters, I love that you can get some basic, useful Ajaxian functionality simply by including the f:ajax tag either inside or wrapped around you JSF tags! This basically would do the equivalent of submitting those fields when the default event for those JSF components fires. The default JavaScript client event for a component is a sensible value depending on whether it is an action component or a value-change component.
Then it is possible to have all the flexibility of doing Ajax from raw JavaScript.
It is certainly much much easier than having to construct a bunch of JavaScript then do a bunch of request hijacking from a PhaseListener, like in JSF 1.1 and 1.2.
Thumbs way up guys!
Wednesday, August 18, 2010
Value Change listener method hint
Here is an important fact. Amazing even.
If you have ever experienced where you have a difference in the behavior of your ADF Faces screen between when somebody when you do a commit by executing the commit Action binding, or doing a commit by pressing a commandLink which fires an action binding...I have some help for you.
In my (sample) senario, I had changed a name in the Name field on a screen. I wanted to get this change into the database, because there is a unique key constraint in the database on the table column associated with this name field. When I create a new record, I call a pl/sql procedure to do the work, then execute a query, then go to the screen where this name field is. The name field has a default value in it, but it is important that the end user change this name field. So I put a value change listener on the name field, so that if they change the name, a commit will be fired.
The only problem was that the value change listener method is called before the value in the fields gets written to the binding layer. So you have to force it prior to calling the commit.
If you have Steve Muench's EL helper class you can do the following in the value change listener method:
If you have ever experienced where you have a difference in the behavior of your ADF Faces screen between when somebody when you do a commit by executing the commit Action binding, or doing a commit by pressing a commandLink which fires an action binding...I have some help for you.
In my (sample) senario, I had changed a name in the Name field on a screen. I wanted to get this change into the database, because there is a unique key constraint in the database on the table column associated with this name field. When I create a new record, I call a pl/sql procedure to do the work, then execute a query, then go to the screen where this name field is. The name field has a default value in it, but it is important that the end user change this name field. So I put a value change listener on the name field, so that if they change the name, a commit will be fired.
The only problem was that the value change listener method is called before the value in the fields gets written to the binding layer. So you have to force it prior to calling the commit.
If you have Steve Muench's EL helper class you can do the following in the value change listener method:
EL.set("#{bindings.Name.inputValue}", valueChangeEvent.getNewValue());Works great!
Thursday, August 5, 2010
AjaxTags
As I continue to work through Deepak Vohra's Ajax in Oracle JDeveloper book, I was very impressed not only by the book (thanks Mr. Vohra!), but also AjaxTags. I must be tag/jsp-oriented, because I tend to view just using javascript to do Ajax as being kind of messy.
It has not taken me very long to get the example in this book which demonstrates AjaxTags up and running. There were a few gotchas. For example, in the example there were only three javascript files which needed to be included in the jsp page using script tags with source attributes. The book was written in 2006. Now in 2010, using the next major version of AjaxTags there are 7 or 8 javascript files, which I had to include. Also Vorha-ji used a "button" tag, which in my browser issued a submit. If you are doing Ajax you don't want to use a button that automatically submits, so I switched to using an <input> tag with a type attribute with the value of "button".
With this example I could register a select list and a button to do Ajax transactions with (in the jsp) only the following two tags:
The second tag, ajax:updateField, keys off of a button whose id is updateForm (see the action attribute of the tag above). This button click does a doGet on formupdateservlet, again passing the parameter of the current value of a select list with the id of catalogId. The target attribute is a comma-delimited list of element ids in our form of various fields we have. This servlet (formupdateservlet) produces XML, unlike the formservlet, which just produced text. So we specify a parser in the tag above to handle the XML. I think then that you just have to make your servlet produce elements which match these target element ids. Again...very compact...but exactly what we are looking for. The only javascript involved is the script tags which include the AjaxTags javascript libraries. These are the ones I had to include:
That's it!
I would like to explore this a bit more (since this example does not begin to cover AjaxTags functionality fully) and see how it performs when incorporated into JSF pages.
It has not taken me very long to get the example in this book which demonstrates AjaxTags up and running. There were a few gotchas. For example, in the example there were only three javascript files which needed to be included in the jsp page using script tags with source attributes. The book was written in 2006. Now in 2010, using the next major version of AjaxTags there are 7 or 8 javascript files, which I had to include. Also Vorha-ji used a "button" tag, which in my browser issued a submit. If you are doing Ajax you don't want to use a button that automatically submits, so I switched to using an <input> tag with a type attribute with the value of "button".
With this example I could register a select list and a button to do Ajax transactions with (in the jsp) only the following two tags:
<ajax:htmlContent baseUrl="formservlet" source="catalogId" target="validationMessage"So, in this example, you had to define two servlets, one called formservlet and one called formupdateservlet. The ajax:htmlContent tag above made it so that if you changed the selected value of a select list with the id of catalogId, it would "doGet" on formservlet with the request parameter which has that selected value. The value of the element with the id of "validationMessage" (as specified in the ajax:htmlContent tag above) is set to the text of the response of this servlet. That is a lot of meaning to pack into a little tag...but that "meaning" is just what we want, time and time again...isn't it...with AJAX.
parameters="catalogId={catalogId}"/>
<ajax:updateField action="updateForm" baseUrl="formupdateservlet"
parameters="catalogId={catalogId}" source="catalogId"
target="journal,publisher,edition,title,author"
parser="new ResponseXmlParser()"/>
The second tag, ajax:updateField, keys off of a button whose id is updateForm (see the action attribute of the tag above). This button click does a doGet on formupdateservlet, again passing the parameter of the current value of a select list with the id of catalogId. The target attribute is a comma-delimited list of element ids in our form of various fields we have. This servlet (formupdateservlet) produces XML, unlike the formservlet, which just produced text. So we specify a parser in the tag above to handle the XML. I think then that you just have to make your servlet produce elements which match these target element ids. Again...very compact...but exactly what we are looking for. The only javascript involved is the script tags which include the AjaxTags javascript libraries. These are the ones I had to include:
<script src="prototype.js" type="text/javascript"></script>Scriptaculous is used to make some of this happen, and is part of AjaxTags. It has some support javascript files which I did not include. It would probably be safest just to include all of them, since there are not that many.
<script src="scriptaculous.js" type="text/javascript"></script>
<script src="overlibmws.js" type="text/javascript"></script>
<script src="effects.js" type="text/javascript"></script>
<script src="controls.js" type="text/javascript"></script>
<script src="ajaxtags_controls.js" type="text/javascript"></script>
<script src="ajaxtags_parser.js" type="text/javascript"></script>
<script src="ajaxtags.js" type="text/javascript"></script>
That's it!
I would like to explore this a bit more (since this example does not begin to cover AjaxTags functionality fully) and see how it performs when incorporated into JSF pages.
Wednesday, August 4, 2010
Continuing to look at Task Flows
I have a question now about Task Flows in Oracle ADF Faces/Bindings 11g. I see from reading Frank Nimphius and Lynn Munnsinger's new ADF book, how you can make two page fragments talk to each other by creating an event map in the parent page's pageDef, and then raising events in one fragment's bindings, and "consuming" these events with a backing bean method in the other fragment.
What still does not make sense to me is...how does the binding know what event to raise? Granted: I am still messing with ADF Faces 10g, but af:tables, af:tree's, etc. have more than one event associated with them. And yet in this book I do not remember reading a description of how and event raised in the binding knows what kind of event to raise...
For example if I select a node on a tree and that triggers a context event, and then I expand a node on a tree and that triggers a context event (if that is possible...?), where does the link occur between the binding event and the particular component event?
This has more to do with events and production/consumption of them across bounded task flows for page fragments. The example in the book is as follows. On a page there is a panel splitter. On the left side is a tree with deparment nodes and employee nodes under each department node. On the right side is either a department or an employee data update screen with fields and a save buttons. The selection of a dept or emp node on the left gives you an update screen on the right with the correct row queried up. The left and right side are both regions with bounded task flows inside containing page fragments. the parent page (the one with the splitter) has the task flow bindings on it, plus it has the event map defined on the task flow bindings.
So the part I am confused about currently is when you click the tree and the tree binding raises an event, you just enter in the page def for the tree the xml element <events> with and <event> sub-element in it. In the event map you map this event producer to the consumer page/bindings on the right to get a sub-dynamic task flow to either show a emp or dept page fragment. But I do not see where it says what kind of event is getting generated. Surely a tree node can generate more than one kind of event. for example a node can be clicked/selected. Also a node can be disclosed/opened or closed/shut/collapsed/whatever.
I think the following comes close to answering my original question (taken from FUSION DEVELOPER'S GUIDE 11g):
What is confusing to me is the documentation says you can associate an event with bindings of different types, and that the binding-associated events are not the same as ui component-associated events. But then they turn around and say that these binding-associated events all happen in response to actions for which there are component listener properties. So I naturally would assume that we would then says that...these binding-associated events are raised in direct response to the corresponding component event.
From a high level, anyway, it appears that for these binding-associated events we are triggered by a particular event in association with that binding. For range bindingg (tables, trees) the big event is changing of "row currency". (OR POSSIBLY NAVIGATION). Action/Method: when the thing is executed. Attribute -- when the value is set. So I guess the payLoad is different in each case? For the row currency, is the default payload the row? I think for the action, the payload is whatever the action or method returns...? the attribute...the new value? More reading...
What still does not make sense to me is...how does the binding know what event to raise? Granted: I am still messing with ADF Faces 10g, but af:tables, af:tree's, etc. have more than one event associated with them. And yet in this book I do not remember reading a description of how and event raised in the binding knows what kind of event to raise...
For example if I select a node on a tree and that triggers a context event, and then I expand a node on a tree and that triggers a context event (if that is possible...?), where does the link occur between the binding event and the particular component event?
This has more to do with events and production/consumption of them across bounded task flows for page fragments. The example in the book is as follows. On a page there is a panel splitter. On the left side is a tree with deparment nodes and employee nodes under each department node. On the right side is either a department or an employee data update screen with fields and a save buttons. The selection of a dept or emp node on the left gives you an update screen on the right with the correct row queried up. The left and right side are both regions with bounded task flows inside containing page fragments. the parent page (the one with the splitter) has the task flow bindings on it, plus it has the event map defined on the task flow bindings.
So the part I am confused about currently is when you click the tree and the tree binding raises an event, you just enter in the page def for the tree the xml element <events> with and <event> sub-element in it. In the event map you map this event producer to the consumer page/bindings on the right to get a sub-dynamic task flow to either show a emp or dept page fragment. But I do not see where it says what kind of event is getting generated. Surely a tree node can generate more than one kind of event. for example a node can be clicked/selected. Also a node can be disclosed/opened or closed/shut/collapsed/whatever.
I think the following comes close to answering my original question (taken from FUSION DEVELOPER'S GUIDE 11g):
You can raise a contextual event for an action binding, a method action binding, a value attribute binding, a tree binding, a table binding, or a list binding. For action and method action bindings, the event is raised when the action or method is executed. For a value attribute binding, the event is triggered by the binding container and raised after the attribute is set successfully. For a range binding (tree, table, list), the event is raised after the currency change has succeeded. Value attribute binding and range binding contextual events may also be triggered by navigational changes.
Contextual events are not the same as events raised by UI components. For a description of these types of events, see the Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework. Contextual events can be used in association with UI events. In this case, an action listener that is invoked due to a UI event can, in turn, invoke a method action binding that then raises the event.
What is confusing to me is the documentation says you can associate an event with bindings of different types, and that the binding-associated events are not the same as ui component-associated events. But then they turn around and say that these binding-associated events all happen in response to actions for which there are component listener properties. So I naturally would assume that we would then says that...these binding-associated events are raised in direct response to the corresponding component event.
From a high level, anyway, it appears that for these binding-associated events we are triggered by a particular event in association with that binding. For range bindingg (tables, trees) the big event is changing of "row currency". (OR POSSIBLY NAVIGATION). Action/Method: when the thing is executed. Attribute -- when the value is set. So I guess the payLoad is different in each case? For the row currency, is the default payload the row? I think for the action, the payload is whatever the action or method returns...? the attribute...the new value? More reading...
Subscribe to:
Posts (Atom)