Thursday, October 17, 2013

ADF Managed Bean Scope Issues

So yesterday we were having issues trying to access an ADF managed bean from code using the typical EL resolver code:

    FacesContext fctx = FacesContext.getCurrentInstance();
    Application app = fctx.getApplication();
    ExpressionFactory elFactory = app.getExpressionFactory();
    ELContext elCtx = fctx.getELContext();

    String el = "#{pageData}";
    ValueExpression ve = elFactory.createValueExpression(elCtx, el, Object.class);
    Object bean = ve.getValue(elCtx);

The problem was that the very last line was always returning null! Our pageData bean was originally scoped as "pageFlow", but setting it to "session", or "application", or "request" allowed the code to work. The only two scopes that did not work were "pageFlow" and "view". In fact our page that was referencing this bean with EL was also not seeing it when the bean was scoped this this way.

Turns out that unlike normal JSF scopes, ADF scopes require the scope to be specified when accessing the bean.  So we needed to change our EL statement from #{pageData} to #{pageFlowScope.pageData}.  In both the code and on the page this resolved our issue.

What notified me of this odd behavior was a small note in the ADF documentation here:

Note:
Write EL expressions that explicitly qualify the scope to access when writing EL expressions to access custom scopes unique to Oracle ADF (pageFlow, backingBean, and view scopes). For example, write an EL expression to access a pageFlow scope as follows:
#{pageFlowScope.inpTxtBB.uiComponent}

Personally, I find this behavior somewhat counterproductive, because you are going to need to find all references whenever you change a bean's scope (which will likely only happen in initial development).  Given that EL is very silent about missing references (by design), this increases the risk of broken code.  Hopefully it will not be too big of a deal in the future.

Wednesday, October 16, 2013

JDeveloper and SVN

As most of you are most likely aware, JDeveloper's SVN integration is not the easiest to use, and there are a number of features that seem relatively absent.  One such feature that I completely miss from Eclipse plug-ins like Subversive and Subclipse is the fact that they automatically do an SVN "Add" operation when new files are created.  Alas, JDeveloper may be capable of doing the same thing!

Friday, October 4, 2013

WebCenter Portal - Out-of-box services

I am working on a project right now to get our developers some practice with the WebCenter Portal (WCP) and ADF toolset.  As such, one of the things we needed to know was the complete list of features/services we can utilize in our custom development (beyond the basic ADF capabilities and navigation).  Since I could not find an nice quick list from a developer POV, I decided to create one, for my own future reference, and in case anyone else was looking for something similar.

Thursday, June 27, 2013

Navigation Models - Part 1: What is a navigation model?

Navigation models initially confused me.  I mean, I understood that they represented the navigation options on a WCP site, but I couldn't figure out why they were different from page hierarchies.  After reading much documentation, and thinking about it, trying to come up with an example of how these two items would differ, I think I finally got it.  Read on to see my example of why there are two different things.

A bit of history

Many of the articles I plan will illustrate some of the challenges we have faced moving to JDeveloper and ADF/FMW.  In order to give appropriate context, I feel that a quick background of where we came from is in order.

First a bit of history.  We came from an Eclipse based stack of tools.  We opted for the commercially available (and very reasonably priced) MyEclipse Professional package from Genuitec.  This gave us a good stack to start with standard JEE development, including Web Services, EJBs, and Struts.

As time went on, we adopted JSF to replace Struts, abandoned EJB 2.x by replacing the business layer with web services.  Eventually we also adopted the Spring IoC container to help with some of the container management we lost with the move to Web Services.

In addition, we grew our stack to also include some additional tools.  At the time of switch, we were running the following:

  • Java 6 (JRockit) with JEE 5 on Weblogic Server
  • MyEclipse Professional 10.6 (using the Pulse engine to ensure configurations are consistent across developer machines)
  • PMD - for static analysis of code smells, bugs and bad programming practices.
  • Checkstyle - for static analysis of code style standards adherence
  • Ant - for building the software packages and enforcing certain parts of our release process (for example to make certain that code is tagged before a release is cut and that manifest files are updated with proper version information).  We were going to start doing more continuous integration, automated delivery and automated dependency management, and were contemplating a switch to Maven before the switch.

Adventures in a new framework

Wow, it has been a long time since I updated this blog!  About time to change that!

The company I work for has recently decided to adopt Oracle's Fusion Middleware (FMW) stack and Application Development Framework (ADF) in order to rebuild their web-presence.  I have now had a few months to play around with the framework.  One thing I have noticed is that much of the documentation that exists is good at explaining the technical details of how to do something, but lacks the background about why you are doing things a certain way, or when you would apply it.

Out of this frustration, I am going to start posting my own versions of tutorials, notes, and tips and tricks, while trying to make clear all of that background information I have struggled to find is made clear (but does not overshadow getting things done).

Many of the articles I plan will illustrate some of the challenges we have faced moving to JDeveloper and ADF/FMW.  In order to give appropriate context, I feel that a quick background of where we came from is in order.

First a bit of history.  We came from an Eclipse based stack of tools.  We opted for the commercially available (and very reasonably priced) MyEclipse Professional package from Genuitec.  This gave us a good stack to start with standard JEE development, including Web Services, EJBs, and Struts.

As time went on, we adopted JSF to replace Struts, abandoned EJB 2.x by replacing the business layer with web services.  Eventually, we also adopted the Spring IoC container to help with some of the container management we lost with the move to Web Services.

In addition, we grew our stack to also include some additional tools.  At the time of switch, we were running the following:
  • Java 6 (JRockit) with JEE 5 on Weblogic Server
  • MyEclipse Professional 10.6 (using the Pulse engine to ensure configurations are consistent across developer machines)
  • PMD - for static analysis of code smells, bugs and bad programming practices.
  • Checkstyle - for static analysis of code style standards adherence
  • Ant - for building the software packages and enforcing certain parts of our release process (for example to make certain that code is tagged before a release is cut and that manifest files are updated with proper version information).  We were going to start doing more continuous integration, automated delivery and automated dependency management, and were contemplating a switch to Maven before the switch.
At