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