Save (most of) your changes to the JDeveloper IDE

Under some circumstances you may need to rename or remove your system11.x.x.x folder to overcome errors with the IDE which can’t be solved otherwise. I blogged about this How to find and reset the system11.x.x.x folder for a JDeveloper installation.
However, this means that you loose all of the changes you made to IDE, e.g. connections to DBs, code templates and many more.
In the current version or JDeveloper there is no feature to save all the changes you made with a simple export or click on a button. An ER for this is about to be filed.

Until we see this ER implemented you need to store the changes you made yourself. First of all we need to know all the places were changes can be saved in a file or exported into a file. I put all those files under source control. This makes them available for other developers in the same team and allows to hold different configurations for different or the same JDeveloper version. This blog post lists all the places I know. If you know any other place, please drop a comment so that I can include it here.
To my knowledge the locations below are working for all JDeveloper version from 11.1.1.x up to the current version 11.1.2.1.0.

There are three locations where you can save your changes

1. Recource Palette
2. Preferences
3. File menu

Lets start with the Resource Palette:

Resource Palette 1

This will bring up

Resource Palette 2

This dialog allows you to save all the connection to DBs and Weblogic Servers you have defined as well as Catalogs. All you have to do is to specify a path and a file name to store the information.

Next are the Preferences. Here are a couple of places where you can export your changes.
Audit Profiles:

Audit Profiles

Code Editor – Code Style

Code Editor - Code Style

Code Editor – Code Templates

Code Editor - Code Templates

Code Editor – Syntax Colors

Code Editor - Syntax Colors

Database – SQL Formatter

Database - SQL Formatter

Database – SQL Formatter – Oracle Formatting

SQL Formatter - Oracle Formatting

Database – SQL Formatter – Other Vendors (each vendor can be saved)

Database - SQL Formatter - Other Vendors

Shortcut Keys

Versioning – Comment Templates

Versioning - Comment Templates

Finally the ‘File’ menu which mainly allows to export the connections to the source control system you use

File - Export

Remove Automatic Component Bindings

The last couple of day I spend some time investigating the ‘Automatic Component Binding’ feature. A code review I did lately showed that about 40% of the jspx pages of one project (about 60 pages in total) had automatic component binding on. As each page thus have a bean defined where the ui components are bound to, the project also contains a lot of beans. The beans are generated automatically and in this case don’t do anything but eat memory.

So two questions came up:
1) Why where automatic component binding on in so many pages, as we don’t use this feature?
2) How to get rid of the bindings and the (for us) useless beans?

This blog entry answers the second question and at least gives one hint for the first one. Lets start with the second question.

Reading the documentation Oracle® Fusion Middleware Web User Interface Developer’s Guide for Oracle Application Development Framework shows how to turn on/off the automatic component binding via JDeveloper for a page or fragment

Automatic Component Binding On/Off

If you turn the automatic binding on you’ll notice a comment line in your jsxp file

</f:view>
  <!--oracle-jdev-comment:auto-binding-backing-bean-name:backing_view11-->
</jsp:root>

This entry in the file triggers the automatic binding. Removing it has the same effect as turning the feature off in the above dialog.
So, as the doc stated, turning the automatic binding off only has an effect for components which are put onto the page in the future. If your page contains e.g. one or more forms, there are many components which are bound needlessly to a bean. It’s an error prone task to go through the source and remove all the bindings properties by hand.
JDeveloper allows us to use regular expressions in search and replace operations (even in search and replace in files). Looking to the source of the jspx page reveals

<f:view>
    <af:document id="d2" binding="#{backingBeanScope.ffff.d2}">
      <af:messages id="m2" binding="#{backingBeanScope.ffff.m2}"/>
      <af:form id="f2" binding="#{backingBeanScope.ffff.f2}">
        <af:panelStretchLayout topHeight="50px" id="psl2"
                              binding="#{backingBeanScope.ffff.psl2}">

that the automatic bindings all are looking like ‘binding=”#{backingBeanScope.ffff.<id>’, so we only need a regular expression looking for this string and replace it with nothing.

Replace Dialog

Running the dialog above shows that the expression finds the desired targets

Running Replace

After all references to the bean have been deleted, we can simply delete the bean itself. This concludes the answer to the second question.

The answer to the first question is not that easy to give. First of all I found out, that if you once turned the automatic component binding on, it stays on for all other pages you put into the same task flow. It may stay on for all pages, but I couldn’t confirm this in all cases. At some time a developer turned this feature on in the dialog you see when you create a new page (or fragment) in the bounded task flow

Create Page Dialog

You have to click the ‘+’ sign by ‘Page Implementation’ to see the option. The thing is, the next time you create a new page the ‘Page Implementation’ is disclosed and you have to open it to see the current state. As I mentioned before, the option keeps its setting in the task flow. This answers the question of how we end up with so many pages using this feature. A developer turned this on for some reason and all pages added to the task flow later on inherited the behavior.
One interesting thing to note is, that you don’t see the ‘Bindings’ property for components, if you have the automatic component binding turned on

Bindings visible - Automatic Component Binding Off

Binding invisible - Automatic Component Bindings On

A summery of this is that you should only use the ‘Automatic Component Binding’ feature if you really need it. If you turn it on, make sure to check its status often and turn it off when not needed.