Friday, November 27, 2009

العيد بعيدين

and maybe more,

the first reason is because it is EID Al Adha, and instead for writing again and agian about it, i will just refer to
http://oraclejo.blogspot.com/2008/09/eid-dj-vu.html.

and for the second Eid, it about some technical issue that i figured about ADF technology. If you are not familiar with what Oracle ADF is, stop reading because this is not for YOU, or continue at our own risk

Well, i spend the day yesterday fiddling around with ADF binding concepts until i believe i have got it all figured out. I was working with this technology for quite sometime (only from out of the box) but since i am asked to do some consulting job next week in Kuwait, i have been doing nitty gritty details and trying to come done to core of the material.

I have designed two pages one based on on Table DEPT and with the following page definition information

Page definition name ="untitled1PageDef"
iterator name ="deptView1Iterator"

and the other is page is based on TRADE table with the following page definition information

Page definition name ="untitled1PageDef"
iterator name ="tradeView1Iterator"

A trivial scenario would be to read some page1 attribute (Text item) from page1 while running page one. All ADF programmers must have encountered this situation and have done it many times through several different solution. The solution i pick is a solution that i can always use and a solution that depends on the basics (No Eid here)

FacesContext ctx = FacesContext.getCurrentInstance();
Application app = ctx.getApplication();
ValueBinding bind = app.createValueBinding("#{data}");

BindingContext bindingCtx = (BindingContext)bind.getValue(ctx);
DCBindingContainer dcb = (DCBindingContainer)bindingCtx.findBindingContainer("untitled1PageDef");
DCIteratorBinding Iter = dcb.findIteratorBinding("DeptView1Iterator");
String attr =Iter.getCurrentRow().getAttribute(2).toString();

(note: i know that there are short cuts that would probably eliminate a few lines of code, but at the expense of hiding the basics).


Now, let us move to the following situation. I am running page1 and selected a specific row, and i am moving to page 2 and i am required to find an attribute of on page 1 (which i have already left) . Well many techniques exist and most of them depend on other standard web techniques like using Session Variables, or ADF actions set Action listener etc..
The basic concept in ADF relies on a model object that holds that sources based on View Object. Since view objects are already instantiated by the Application Module and their data is persistent as long as the application module is alive, and since such objects are bound to ADF iterator binding in the binding containers, then, its only makes sense that we should be able to read the iterator binding of any visited page definition.

Well, during my past readings , i came to know more things about iterator binding, that i undermined at that time. The Literature about ADF iterator binding says, that after the completion of the JSF and ADF lifecycle, the framework unbinds the iterator binding from its data source and rebinds it again when the page is loaded again. This is done automatically to save resources. This of course does not cause the loss of any data, because the view object is still there in the model layer. It is only the iterator binding pointer is not there and in most cases, it needs not be there since at that time the user is on a different page

So, for now, page2 is displayed on the screen and there is a button on page2 screen and i want to read information from page1, the same information that i read when i was already on page 1.

An innocent attempt would be to use the same code as before, and if you do, you will face a NullPointer exception when you run

DCIteratorBinding Iter = dcb.findIteratorBinding("DeptView1Iterator");

Because as i explained earlier the binding iterator of page 1 (DeptView1Iterator) is not bound after the page lifecycle is complete even though the iterator itself exists?? It will be bound during the iterator refresh step during page reload.

Well, then i can find some why to manually refresh the iterator binding, i should be able to accomplish what i want, and Eureka, after some brain drain investigating, i found it


call getRowSetIterator();


and then I included the above call in my code with my fingers crossed, and the Second Eid emerged for me , it worked like a
charm

FacesContext ctx = FacesContext.getCurrentInstance();
Application app = ctx.getApplication();
ValueBinding bind = app.createValueBinding("#{data}");

BindingContext bindingCtx = (BindingContext)bind.getValue(ctx);
DCBindingContainer dcb = (DCBindingContainer)bindingCtx.findBindingContainer("untitled1PageDef");
DCIteratorBinding Iter = dcb.findIteratorBinding("DeptView1Iterator");
String attr =Iter.getRowSetIterator().getCurrentRow().getAttribute(2).toString();
//simialr to DCBindingIterator Iter = (DCBindingIterator)Iter.get("binding iterator)
DCIteratorBinding Iter1 = dcb.findIteratorBinding("tradeView1Iterator");
String attr2 =Iter1.getRowSetIterator().getCurrentRow().getAttribute(2).toString();
System.out.println(attr);
System.out.println(attr2);

The getRowSetIterator() binds it again to the data control and hence it now points to current row of the view object (which would be the row you selected in the previous page when you navigated out of it)

Since I became more confident about my knowledge, i thought, ok what if the user ran page2 immediately without running page 1, and tried to access some data from page (1).
There is no data in page 1!!! and that is exactly the case, running the above code would legitimately yield NullPointer Exception. To demonstrate my understanding, i thought i would manipulate the code is a way, that in case the user skipped page1 , it only makes sense to say that in this case, the current row of the first page would be the first row in the view object, I figure what if i execute a query of the first page iterator after accessing it using

Iter.executeQuery();

Again, it worked like a charm

FacesContext ctx = FacesContext.getCurrentInstance();
Application app = ctx.getApplication();
ValueBinding bind = app.createValueBinding("#{data}");

BindingContext bindingCtx = (BindingContext)bind.getValue(ctx);
DCBindingContainer dcb = (DCBindingContainer)bindingCtx.findBindingContainer("untitled1PageDef");
DCIteratorBinding Iter = dcb.findIteratorBinding("DeptView1Iterator");
String attr =Iter.getRowSetIterator().getCurrentRow().getAttribute(2).toString();
//simialr to DCBindingIterator Iter = (DCBindingIterator)Iter.get("binding iterator)
DCIteratorBinding Iter1 = dcb.findIteratorBinding("tradeView1Iterator");
Iter1.executeQuery();
String attr2 =Iter1.getRowSetIterator().getCurrentRow().getAttribute(2).toString();
System.out.println(attr);
System.out.println(attr2);

I know it means nothing to most of you, but it sure does to me and others in who opt to understand the framework that way i want ....

Which brings up a new reason why it a Eid, well, right now, at about 8:10 PM, we are leaving home and heading for a 36 hours vacation at Aqaba, a decision taken at the spur of the moment

Happy Me

Saturday, November 21, 2009

Significant leap forward

the Large Hadron Collider is back after it was damaged last year. This collider is by far the largest ever built and will smash atoms in order to unleash the secrets hidden in the depth of matter.
Exciting experiments shall shed light on the Big Bang theory that explains h the world is started.

Getting Ref of the View Object referenced by the current Iterator binding for One iterator page without knowing the name of the iterator

Getting Ref of the View Object referenced by the current Iterator binding for One iterator page without knowing the name of the iterator ...