One thing that would really help at my company to sell the idea of building UIX pages now and migrating them to JSF when the standard finalizes would be an example of what this transformation might look like. Is there any chance of a small example of a UIX page with a few interesting features and the JSF that would result from a translation?
Thanks Frank, but we still have some questions about this. From what I understand, JSF is like UIX in that all of the components are Java classes. Sun will provide JSP tags to instantiate and parameterize these classes, but that's only one way to do so. A colleague mentioned that he has also seen a XUL document to specify a JSF interface. So, when Oracle says that UIX documents will become JSF documents, does that mean that UIX documents will become JSPs using something like the UIX JSP tag library, or only that UIX documents will be another way to specify a JSF-compliant object model? In the former case, it might be easier to leverage developer's familiarity with JSPs, whereas in the latter, building UIX pages would still feel more proprietary. Or am I misunderstanding the 'translation' altogether? A before/after example would help illustrate these questions.
Also, at the Oracle Developer Days, we were told that the production release of JDev 10g (still this year?) would include the UIX->JSF translation, whereas the roadmap seems ambiguous as to whether this translation will only be available in the /next/ release of JDeveloper (timeframe?), after JSF has been finalized.
The natural extension of what we have today is that a .uix file (XML) would be making calls to JSF components instead of UIX components. This would be very much in line with your XUL example, and it means that a .uix file would be yet another way to access JSF, like JSP or XUL.
However, we are very aware of the advantage of developer familiarity with JSP that you mentioned. It is a very important goal of ours to continue to bring UIX technology closer in line with JSP, and the most recent evidence of that was the UIX support for JSP 2.0 EL we added in JDeveloper 10g. There will be more movement in that direction once JSF is finalized and fully supported in JDeveloper, but additional details are still in the works. :)
There will be some obvious differences between UIX and JSF. For example, JSF provides standard mechanisms for automatic event and state handling for components, and this will mean that some UIX code will no longer be needed in a JSF application. We expect to provide upgrade utilities for pages that use the UIX XML syntax, because that is one of the benefits of using XML.
However, JSF itself is still months away from completion. Providing support for JSF in JDeveloper is tied to that, as we cannot ship support for JSF in a production release until JSF itself is production. That doesn't match well with the JDeveloper 10g schedule, but the rough schedule diagram at:
might give you a better idea of which release would be in line with the current JSF schedule -- JDeveloper 10g 10.0.3.
I hope this helps. Let us know if you have more questions.
One thing to consider then is that I believe if you
use UIX XML we will be providing an upgrade tool. But
if you use UIX JSP we won't. Its much easier to upgrade
a well formed language than one that is not well formed.
I like the idea of having you guys write the migration scripts for us, rather than us having to refactor all of our code to meet the new standards. Of course, this is all assuming that JSF is really where the industry goes and therefore where we would want to be.
We've been stuck with proprietary solutions before (how about a large application in an unsupported dialect of Smalltalk, or a bunch of GUIs stuck in Visual Age for Java on JRE 1.2...) and so we're extra wary of getting locked in to anything that won't get sizeable multi-vendor support.
On the other hand, even if JSF were already finalized today, I've been looking around at what people are saying about it, and there's still a dearth of components and a sense that it's not really ready yet to jump-start anyone's productivity. Whereas with UIX, you guys have basically got everything we could ask for already integrated into one stack.
I just don't want to have to train everyone at my company in UIX for JSF any more than I'd want to use XUL for JSF if the rest of the industry winds up doing JSF with JSPs. So, I'm counting on you guys "to continue to bring UIX technology closer in line with JSP" so that I don't have to eat my words if I recommend that we go the full UIX route. :)
Here is one more thing from our management:
In the JSF world, the role of UIX is much more as a set of components than as an architecture, per se. Therefore, the goal would be to train your employees on JSF and choose those additional components to have a richer development environment than just using the JSF core. The nice thing about this is that it means that if UIX doesn't end up suiting your needs you can switch to someone else's JSF component set and still retain your JSF training. But unless you want to stick to the core components -- basically HTML forms -- you'll want to invest in learning and using some vendor's set. Hope that helps!