f:verbatim's affects on af:inputText

Did you know if f:verbatim is a parent of af:inputText that the af:inputText will ignore changes made by the end-user to its data??? That one drove me a little nuts. I am trying to integrate Dojo with ADF is why I ran into such a scenario.

Oracle Open World 2009 Campaign

All,
Thank you so much for your votes on my Oracle Open World presentation proposals. Many heavy hitters in the ADF community have voted for this presentation. It is on JSF Custom Components: Frank Nimphius, Grant Ronald, Peter Moskovits, and the list goes on and on.
I have noticed that Oracle Mix has been a bit flaky at time for the links that I distributed. If you wanted to vote but could not see the links, please try the proposal page; you should have better luck. At this time I am on the second page of Top proposals:
https://mix.oracle.com/oow/proposals/
I am very excited to be involved with this campaign. :-)
Michael Fons


Hi. I want to speak at Oracle Open World 2009. My paper is on creating JSF Custom Components.

Please read my abstract and vote for my paper at
https://mix.oracle.com/oow/proposals/10362

Note: in order for your vote to count, you will need to ...
1. Have/log into an Oracle Mix account (follow the appropriate links if you don't already have an Oracle Mix account; good site to check out, anyway)
2. Vote for at least 3 papers.

To help with 2. above, please also vote for a friend of mine...
https://mix.oracle.com/oow/proposals/10432

And then...your vote #3 can be random or pointed...

Thanks for your time.

sun's blueprints

Very nice. I just had another look at Duncan Mills' Autosuggest tutorial using Sun's blueprint project. I am really beginning to understand what they were doing. I downloaded a bunch more stuff to look at on the plane going back to Virginia. Very interesting.

http://www.oracle.com/technology/products/jdev/tips/mills/AjaxAutoSuggest/AjaxAutoSuggest.html

This is the article I am talking about. I looked at it a year or so ago; I understand it much better today. The blueprint project has a bunch of very useful, interesting custom JSF component code to look at for free. What a learning opportunity.

So was able to implement this as is, but I had some trouble using the BindingContainer. But I used #{data..dataProvider} to get the application module instead of going through the bindings layer, and that got me to the same place. I have not isolated the exact trouble with the bindings layer yet.

I realize that the BindingContainer layer (JSR 227?) is very important, but I believe I am still abiding by the overall architechtural bent of using the Application Module as a repository for services, and accessing only the exposed ones. Right now I just have some vague notion that creating a PageDef and hooking it into the DataBindings.cpx file is somehow fraut with opportunities to make mistakes. I have made a variety of mistakes setting these up, but the binding layer issues have the trouble of not yet revealing to me how on earth to troubleshoot the problem. I only see that when I get the value for #{bindings} that it is null.

Ah well. On the lighter side, I was able to download the source for this textfield.jar that this example uses; and I was able to get the source working just fine. I also obtained the source to the other aspects of J2EE blueprints avaialble in the same download, and also an additional download which gives the updates for Java EE 5.0 :-)

That should keep me busy on those 3.5 hour plane-trips. ;-)

One thing I would like to improve upon for this component is that it does not respond to a down arrow or up-arrow. I think this should be doable.

DOMSource

Time sink...

I spent way too much time trying to get this to work. It is upsetting me, so it goes on the blog.

The general idea is I wanted to change an XML file from my Java program. My approach was to load it into a Document object, manipulate it. Then when I was done I would use a DOMSource and a Transformer to convert this Document to a String.

What was supposed to work that did NOT was giving DOMSource a non-document Node...like an element. I wanted a string for a particular element. DOMSource would give me an empty string when I gave it a viable element, but gave me exactly what I expected when I gave it a real document.

I have no doubt that there is some magic I did not adhere to that will get this to work; by God I am have a limited life span!! Someday I will be savvy enough to deal with this problem I guess...but for now I found it easier to convert the whole document to a string and use regex to extract the node I wanted. Man!!

Decorator/Wrapper pattern

I started writing code using Document class from w3c.org.

Pretty soon it seemed like I was writing a lot of methods which would logically go into an extension of the Document implementation.

So I tried extending XMLDocument (Oracle's implementation of this) in order to have a better place to put these methods.

But the way I was producing this document I was using DocumentBuilder method that parses a file, and returns a Document.

So in my code I could not think of a way to call this, parse method and get a XMLDocument and then cast it to my class so I could use my new methods.

SO: Here is what I did. I created a decorator (wrapper) class which implements the Document interface, and then passed in the returned document from the parse method to the constructor to my new class. Then all I had to do was to implement every method in the Document and Node interface (Document interface extends Node interface).

Only trouble here is there were a lot of methods in these interfaces, and other than write my own program to generate the default wrapper methods I had to hand-type them all in. Pretty tedious and generates a gob of code.

Vik Kumar from Oracle Corporation seemed to agree that this extra code was necessary to "extend" implementations of the Document interface.

Someone else mentioned on the internet that IntelliJ IDEA had a wizard to generate this decorator pattern class, but I downloaded a trial and could not find such a wizard.

FindBugs

OK. Been too long. Must do blog entry. Appologies in advance.

I like FindBugs. Check it out. Help you with your Java form and application robustness. Thanks to Olaf Heimberger for pointing me to it...someone else too from another part of the world also that seemed to have his head screwed on straight.

It lists and categorizes suspicious and crappy stuff in your code. You just can point it at the root of your application and say go. In no time you are going..."gee!" and "golly!"

Try it! You'll like it!

exclusively programmatic use of PageDef iterators

Revision: if you have an iterator that you have included for usage programatically only, be very careful! I kept getting JBO-35007 errors when I did a post back!! So finally I removed the iterator and just got the app module programmatically, and did a findViewObject("viewObjectInstanceName") from it.

Where and how does ADF expand on or deviate from JSF?

ADF is different from JSF, that is for sure.

JSF is an open standard, whereas ADF open for its Trinidad components, but not its newest ones. For example ADF Faces UI components are custom JSF UI components. Generalizing about ADF Faces components, they usually have many more properties than the JSF components. For example, compare the af:table with the h:dataTable. There function is to be the same, but the af:table has many additional features that the h:dataTable does not have. For example the af:table has a selectionListener and sortListener built right into the component’s properties. The h:dataTable has no such property. It is still possible to have a radio button select a particular row in the table, but the way that is to be done is totally different. Selecting a row in a table can involve many things: selectionListener of the table, an tableBinding, the CollectionModel interface (for the value of the af:table), and the af:table’s selection facet. The h:dataTable does not have nearly so many hooks into this row selection functionality.
On the other hand there is a certain simplicity to the way JSF without ADF Faces works. For example, you may not need a SortListener, when you can write a backing bean method that does the sorting, and have your table column header link simply call the sucker.

Another difference between af:table and h:dataTable is that af:table can use the built-in Partial Page Rendering to simply refresh the table without refreshing the entire page. This refreshing can get a bit involved, but usually it is not if you remember one thing: the command item that instigates the partial page rendering of the table cannot be from within the table itself. So for example if there is a button within the action facet of a table that needs PPR-ing, then either the button needs to be moved out of the table, or it needs to use its onclick event property to press another (perhaps hidden) button which is outside of the table. But even with this odd caveat af:tables can do PPR relatively easily.

(PPR outside of tables seems to be pretty straight forward and helpful; some rudimentary AJAX at its best.)

Another add-on for af:table’s are how they work with the page def table binding and iterator definitions in order to easily page groups of rows forwards and backwards. The component that supports the h:table has hooks for this, but it must all be implemented relatively manually. This binding layer is part and parcel of JSR227 (Data binding). Part of this data binding layer also implements DataControl’s. I think this is very important for allowing the layers to be interchangeable, and hiding the implementation of the business service layer.

Another big addition that ADF brings to the table is the Page Definition file; this is also part of the data binding layer they implement. JSF components typically connect to backing beans for their values, whereas Oracle ADF likes to route value properties (and others) through the bindings in the page definition file for that page. Most times I think the addition of binding layer functionality is a boon.

At another level, Oracle ADF Faces Lifecycle augments the JSF Request Processing lifecycle; ADF lifecycle adds a prepareModel and a prepareRender and an extra validation phase to the various JSF phases.

Here is Oracle’s point of view of some of these differences:
The Java Server Faces components differ from the ADF Faces components in ways completely spelled out at the following URL: http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/jsf/doc/spec-diff.html

The following list gives Oracle’s list of advantages of ADF Faces component set over straight JSF HTML and Core components (Oracle Corporation, 2006)
1) Provide more efficient implementations of client-side state saving (reduced per-component size)
2) Rich set of components, validators, and converters
3) ADF Faces tags often offer more features than the standard tags; for example, all input components offer built-in label and message display support ( For more information on the differences between the ADF Faces tags and the standard Faces tags, please see the following document ).
4) Client-side converters/validators - JavaScript enabled converters and validators that attempt to catch and display errors on the client
5) ADF Faces tags can be used inside of the <> tag (it is, unfortunately, not possible to support standard tags inside <> ).
6) Accessibility - support similar to ADF UIX Accessibility
7) Bidirectional language support - ADF Faces components automatically render themselves appropriately for bidirectional languages. Users can also use the "start" and "end" constants described in ADF UIX Bidirectional Language Support
8) Partial Page Rendering (PPR) - support similar to ADF UIX PPR overview
9) Skinning - support similar to ADF UIX Look and Feel
10) ADF integration - including support for JSR227 (Data binding)
11) Rich Client - upcoming rich DHTML client-side renderers

Open World Abstract...

I have submitted an abstract for Oracle Open World. I want to do an instructive paper on how to do custom component development. I think I still have a lot to learn; I had read a chapter or two and done some exercises and examples and thought I knew what I was doing. At the time I learned these basics I felt very proud of them. Now I feel sheepish for feeling proud, since I now know definitively some things which then I only kind of knew.

At the height of my smugness I decided I would try and extend a rich faces component…that did not work out quite as well as I had hoped. I was able to put markup before and after the af:table (rich table, that is), but I cannot seem (yet) to figure out how to get into the middle of it – inside the box where the columns are or in-between the columns. I thought I knew where to look for this, but I am not finding what I expected when I look where I thought I should.

So far my efforts to augment these components have met with very limited success. There is a section in the Fusion Developers ADF Guide 11g about extending components (I hope they mean UI components and not business components) that I should read for sure and probably reference. Maybe that will give me some insight. Maybe for my understanding level, it would be more helpful to attendees if I stick with more basic concepts, like how the pieces I know about interact.

I know the declarative components are custom component combinations, which is quite handy. I have a 10g project where I could really use something like that. Maybe that is something I can explore for my paper: implementing declarative component conceptually, in order to help understand custom component development.

For my edification however I would like to know more details on how Oracle implemented their rich components. When I try to alter them or get inside of them, everything I do seems to not allow me to get at the inner parts of the component. I do not know how Oracle is hiding this.
For starters I see that there are property elements in the components when they are defined in faces-config.xml. I did not know that component properties could be define or elaborated on there. I do not know what that adds, but I would like to know.

I should study JSF details from the Java EE 5.0 tutorial. Hopefully they would have some further explanation of this. Or maybe the standards for Java EE 5.0: maybe they specify some details of JSF that would help me understand what Oracle and everybody else is doing with their components…and help me with this paper.

ADF 10g interfacing with Pentaho

Pentaho is an open-source reporting tool that has a Discoverer-like metadata store for ad-hoc querying; I am alternately battling with that getting my ADF interface to it implemented.

Yesterday I went down a path I had probably been down before but forgotten.

I used a tree binding on a table to have a table in the details facet of an af:table. This worked reasonably well until I tried to update the child table data. At that point all kinds of strange things started to happen. The rows would get mixed up as to who their parent was, I think there might have been some errors....at any rate I backed out of that and went another route because that one was proving somewhat unstable.

Things are starting to get green here in Virginia!