Created my first ADF Faces application
Thursday 9 February 2006 @ 11:47 am
Filed under:

Finally got around to doing something with the new Oracle JDeveloper version 10.1.3 that went production a little while back. I’ve written a little about my first impressions that i had with the Early Access, but now it’s time for the ‘real deal’.

As a test i recoded an little application we made for a customer. It is surprisingly big (1 page) and contains next to no functionality. Always a good idea to start simple. Creating the workspace and projects was a breeze as always. The wizards in JDeveloper take a lot of the tedious work out of your hands. The improved integration with CVS seems to be a lot better. (Waiting for a good solution to switch over to subversion; it seems you can totally rewrite the CVS client configuration to use subversion but that is a little out of my league for the moment) The main feature i like is the improved ‘Pending Changes’ screen. Next to the changed files it also lists files that are ‘candidates’ or more commonly known ‘that (*$&%(*&$ file i forget to add’. However i divert from my story.

Using the new faces-config.xml is quite like the old struts-config Page Flow Diagrammer as doesn’t require much getting used to. Just drag the pages and start double clicking ;-) . Something i needed to get used to was the managed-bean facility of JSF. The whole ‘inversion of control’ pattern i know needed to get acquinted with. It works quite good… however it is a mind turner. People that have used Spring in the past will probably have no problem, but it is a little tricky for those, like me, who haven’t used it before.

I followed some of the guidelines that Oracle describes in their developer’s guide (674 pages!!!!). It is a good document that explains a lot of things. First i set the following rules for myself:

1. Use JSPX pages. They are more structured (and convenient for me because i’m used to the UIX xml files)
2. Only use the ADF Faces tags (let’s stick to one library of tags)
3. Only use Faces tags, no ‘hacking’ of HTML code in between the tags (worked well in UIX)

The positioning of the UI components was quite intuative for me. But i’m used the UIX and that part really doesn’t differ a lot. You need to learn to use a different set of nodes (panelXXXX nodes for the XXXXlayout nodes, etc) but facets are the same as named children, so no difference there. Oracle quite literally just ported all their UIX UI Nodes to JSF UI Components so the panelPage has exactly the same facets as the pageLayout had named children.

Unfortunately here the power and convenience of UIX started showing. UIX has a templating mechanism that JSF lacks. I had the idea to ‘replace’ that templating mechanism with programmatically changing the UI Components in my backing bean. I had the idea of extending my backing beans from a common backing bean and in that common backing bean create the getter and setter for my Page component and changing it there. It would mean that in each page i only would have to add the binding for the af:page component and it would be configured correctly. That actually works! The base backing bean now sets some common facets and attributes for the af:page component (branding, appBranding and copyrightApp facets) and the afh:head component (title attribute). It makes for a layout that is the same in each page without having the copy-paste it. In my opinion JSF really has a fatal lack of functionality here.

On to my next favorite subject in applications, the menu. I’m a firm believer in the fact that you should create of menu once and not in each page. The ADF Developer Guide gives you an elegant solution for creating a Tree structure (based on the JSF DataModel object) that contains your complete menu. The af:page component has an attribute in with you can supply that tree and a facet with which you can specify how it should look. I’m currently trying to get that working in my base bean aswell. Here the lack of a templating mechanism comes up again. In UIX we would create a template for the PageLayout node and in that we would define our whole menu. Then the page would use that template as a reference.
I’ve heard some rumors that in the next version of JSF this will be addressed. I really hope so.

I next went on to doing some autorisation on the menu. In UIX we had the possibility of creating our own functions in expression language. We extensively used that (think of the function #{auth:hasRole( ‘ADMIN’ )} in the rendered attribute, how simple) but in the ADF Faces reference it states that there isn’t a replacement for UIX EL functions in JSF. I still need to check the ‘normal’ tag libraries because a little voice in my head says you can add EL functions there.

Finally i went on to the part that customers always find especially important: the look-and-feel. Here the real nightmare starts. The things you have to do in ADF Faces to get it right are…. well, i don’t even have words for it. First let me explain somethnig i found out the hard way: JSF has render kits and renderers for its components. The ADF Faces renderers have added the skinning functionality. Creating JSF renderers is a painfull proces. I cannot fathom why everything needs ids, families, types and all sorts of things. I have component A and want renderer B to render that component A. I don’t want to create a renderkit (well that is a good idea because you group renderers in a kit) and renderers that must link to families and types. What is that whole family idea? Next the actual renderer itself. What were they thinking when creating the ResponseWriter class? To start an element you must always give a UI Component? I just throw out null everywhere. To write an attribute you need three(?) parameters? The attribute name (ok, logical), the attribute value (ok, logical aswell) and the property name (HUH? what the heck is that?) So we first wrote a wrapper around that beast to fill all those ‘weird’ parameters with null or defaults. Then the road straightened out a little. Now the renderers make a little sense, basically the same as UIX ;-)

Next on to the beast they call skinning in ADF Faces. Never have i seen such a confusing thing. I’m personally quite favored to the Oracle libraries, but here they made a mistake. In order to change the skin of the ADF Faces components (technically you change the generated CSS file), you must edit a CSS file. That CSS file in the reincarnation of XSS files from UIX. In XSS files you had an XML file in which you defined styles and styles could be specifically added for browsers, platforms and/or locales. But now you must do the same in CSS using a syntax that is completely of the world. I already made my first SR (Service Request on the Oracle Metalink support site, formerly known as a TAR) about the problems you get when Oracle has a browser specific setting somewhere and you can only override generic settings in the CSS, but the specific settings overrule the generic ones. The nice thing is that if you go searching in the ADF Faces library you acutally find those XSS files back!!! So why not give us developers that same power? Now we need to do things in a CSS file for which CSS was never intended. Hopefully the guys (and gals) over at Oracle support can clear things up, possibly we can use something else than that CSS file….

Although it seem i’m only ranting about the negative things of the new framework i’m quite pleased about it. As a whole it still is quite a productive technology stack (or framework if you please), but after my current experiences with it, it cannot compare with the previous stack that contained Oracle ADF UIX. My admiration geos to the people of Oracle that came up with the UIX technology and my sympathies go out to them because they must now be marginally depressed by the way JSF replaced UIX.

However, only the future will learn if JSF can reach the same as UIX. We will certainly choose for the technology stack that contains JSF, but only because Oracle will not support or further develop UIX.

Now the only challenge left is to convince our customer to install a new OC4J to run the new version of the application ;-)

PS: First reply from Metalink: “Could you send us a testcase showing your problem?”. How typical. Quick reaction though…

— By Robert Willems of Brilman   Comments (0)   PermaLink

Menu


Blog Categories

Browse by Date
February 2006
M T W T F S S
 12345
6789101112
13141516171819
20212223242526
2728EC

Upcoming Events

Monthly Archives

Recent Comments

Links


XML Feeds Option


Get Firefox  Powered by WordPress

code validations
Valid RSS 2.0  Valid Atom 0.3
Valid W3C XHTML 1.0  Valid W3C CSS