JSF 2.0 practice

This weekend, when my wife took her naps, I did some JSF 2.0 stuff…mostly getting a platform up and running on my work laptop that would allow me to write some JSF 2.0 code and perhaps have something to show y’all.

I have done this setup before on other machines, but I tried some different things.

I recommend the following download: http://netbeans.org/downloads/ (pick the “Java EE” download).

If you do this you get the netbeans IDE, and it will also install (optionally…you have to select a checkbox to install it) glassfish server 3.x. This version of Glassfish is Java EE 6 certified. And this version of Netbeans is integrated pretty well with Glassfish, even with regard to JSF 2.0.

If I do examples I will do it with these two. So if you want to reproduce whatever I will be able to give you specific advice.

I have used this combination of IDE and web server before for JSF 2.0, and it was recommended by the Burns and Schalk JSF 2.0 book that I read.

That said…I DID find a really good JSF 2.0 tutorial: http://www.coreservlets.com/JSF-Tutorial/jsf2/

This tutorial seems to have been put together really recently. They use eclipse Helios and Tomcat 7. I think this combination would be pretty easy to get started on as well, as Eclipse appears to have some decent support for Tomcat. However I would not recommend Eclipse/Glassfish combination, because the latest version of Eclipse’s Glassfish server adapter seems to have a bug or two…at any rate: figuring this particular problem is really not my top priority right this second, so I did not pursue this problem to the ends of the earth…just partway around the earth :-)

My new JSF 2.0 presentation

Well it is done...ish.

I have put a copy of this presentation on slide share, the link for which is here ; you can also see my other papers by using the link on the right side of this blog, in the section for resumes and presentations.

This presentation is also available in slideshare for download, in Powerpoint and PDF format.

Enjoy.

PDF What's new with JSF 2.0

View more documents from Michael Fons.

.

Yes, but WHAT IS A CONTROLLER??

I asked Simon Lessard (a guru among gurus for Java and ADF) in the ADF Methodology Group about what he thought a controller was, and his response is of great interest to me; so I am going to publish it.

From it I learned that Struts did not use the event model, what an Observer pattern was, and a better way to organize your backing bean (controller bean/data bean) code.

From this thread, we have the following:

Hi Michael,

It depends, "controller" can have many meanings. In the purist version, the MVC model is a triangle (http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller). The model exposes the data and services, the controller is the one in charge of calling the model, and the view represents it, calling the controller whenever a UI event occurs and observing (observer pattern http://en.wikipedia.org/wiki/Observer_pattern) the model layer for change and updating itself if something happens.

Now, since the Web model is a detached one, that last interaction is not possible so the MVC model in the Java web world is a mutation of the pure one. As of Struts, the controller was defined as the component in charge of managing the page flow, the navigation of which was implemented by two type of entities, the Action and the struts-config.xml file (and the control flow engine running it). With JSF, the event model like that of Swing was added, providing a way to implement another part of the controller layer -- the UI event management -- through various listeners. Each listener can therefore be considered a controller or part of a bigger controller (depending how you implement it) since these listeners can modify the component (refresh it, change its state, etc.). Also, since those listeners are accessed through EL and call managed bean methods in the end, then yes, I consider some managed beans a controller (or a part of a controller) -- but only if they are not used to store data. I call the latter data beans, and they often implement an interface from the model layer so that they can be used as service call parameters. So, in the pages, you have:

<af:inputText value="#{expressionToADataBeanField}"/>
<af:commandButton action="#{expressionToAControllerBeanMethod}"/>
<af:someComponent binding="#{expressionToAControllerBeanField}"/>

Since the controller bean often needs access to the data bean, I inject the data bean into the controller bean (using the managed-property feature of JSF) when the controller is created. The data bean is stored in a persistent scope like session or page flow and must therefore be Serializable. The controller bean, on the other hand, must be stateless; so it can only be placed in the backing bean or the request scope and cannot be Serializable since UIComponent (the root class for components) isn't and can be bound in the bean.

So yes, I call a backing bean a "controller" since they manage the UI interactions, call the model layer services and participate in the navigation through the action's outcome which is everything a controller should do. However, the controller layer is also completed by the JSF's NavigationHandler, which takes care of the actual page flow from the outcomes.

So to summarize, I consider:
- Managed beans used to bind components and deal with events: backing beans, controllers, controller beans
- Managed beans used to store the data entered by the user: data beans, page flow beans, session bean


I hope it clarifies the concepts a bit,

~ Simon

Backing Bean Scope

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.)

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.

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:

...onkeyup="var lArgs = {}; lArgs['render'] = 'form:output'; lArgs['javax.faces.behavior.event'] = 'keyup'; jsf.ajax.request(this,event,lArgs);"

I am currently in the best seat in an IMAX 3-D version of Tron Legacy!!!! Been waiting most of my adult life for this sequel. Lol...

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.

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!