Thursday, March 7, 2013

How to Filter a table (QBE) using javascript

I recently had a requirement to double click some text on the page that would cause a table elsewhere on the page to populate one of the table column headers (Query by example) inputs and filter the table.   This can be done programmatically in a backing bean.  Here is a link to a forum thread for doing that and a sample can be downloaded from this page or directly with this link Programmatically Manipulating a Table's QBE Filter Fields  A different solution I came up with performs this action on the client side and was pretty simple to implement.   I was able to add the code for doing this to the jspx file while the server was running and test it without even having to restart the server.  I performed the following steps

  • Create a filter facet for the column you need to populate.  Add an inputText inside this facet and set it to be a clientComponent so that you can retrieve it on the clientSide by Id. (example)

                 <f:facet name="filter">
           
             <af:inputText value="#{vs.filterCriteria.MyColumnName}"
                                  simple="true"
                                  binding="#{requestScope.myColumnName}"
                                  id="ncode" clientComponent="true"/>
      </f:facet>
  • Add javascript method to a .js file loaded by your page that looks like this

    function filterByValue(){
      var flter= AdfPage.PAGE.findComponent(
    myColumnName); // retrieve filter input text
      flter.setValue("SomeValue")'  // populate the filter with your value
      // parent of the filter component is the table component
      flter.getParent().getPeer()._handleFilterCellAction(); // this submits the value (like hitting enter)
    }

     
  • The above code assumes there is a variable on the page named myColumnName contain the full component id of the inputText you are populating.  There are various ways to get this ID.   I used the technique described in my other blog posting here and set it using this script at the top of the page.  Note that ColumnName is an arbitrary name given to the component binding and is bound to requestScope so that it can be set into this javascript variable when the page loads.

    <trh:script text="var
    myColumnName= '#{ClientIdMap['requestScope.myColumnName']}';" /> 
  • Add a client listener to the component that you want to double click on

    <
    af:clientListener method="filterCollectorComments"  type="dblClick" /> 
That's is everything needed.  Double clicking the component will populate my filter table header and submit it.

Monday, March 4, 2013

Debugging tip

I have noticed that sometimes when stepping through ADF code in the debugger, there is a long lag of 2-5 seconds each time I step.   Other times it is snappy and I can quickly step over each line of code with no delay.   I recently discovered that this lag is caused by having the ADF Structure Panel visible (See Image).   This panel in the lower left corner contains some useful information if you need to look at it but if visible it takes a long time to refresh each time you stop at a breakpoint,.   So to speed up your debugging simply switch to another tab so that the ADF structure Panel is not visible and you can step through code a whole lot smoother.   You may not notice this if you have a simple structure but our page had a number of nested regions that was causing delays when stepping through code.

Friday, March 1, 2013

Working with multiple branches of your code base

It's often necessary to run a different branch of your code base in Jdeveloper.   For very large projects it is problematic to use the same installation of Jdeveloper for this because after you close your project and load the project for the other branch you must perform a full clean and build because the project will have the same name and deployment location.   This can be a time consuming process.  Even after this is done I have seen cases where Jdeveloper uses cached classes or meta data from the other project which makes me feel uncomfortable that I am truly running all code from the new branch.   To get around this in the past I've installed a separate instance of Jdeveloper for each code base that I might need to run.   When you do this you must make sure the new installation does not share the System directory with the original installation or you will have the same problem.  The System directory.  (the one with a name like  system11.1.1.4.37.59.23)  contains the Weblogic instance and deployment files.   It gets generated the first time you start up the server.  Deleting the System directory is one way to get your jdev installation back to a good state if it's configuration somehow gets messed up and is quicker than reinstalling.  The System directory will be placed in the location defined in an environment variable or else by default in your windows user profile.  See Oracle's documentation here on how to do that.   Another way to assure the system directory is unique is to edit the startup shortcut and add the -su parameter to the command line startup (i.e Jdeveloper.exe -su).  This causes the system directory to be placed in the same directory where Jdeveloper is installed.  I've used the -su parameter forever on all of my installations because it makes it easy to find the system directory for any particular installation.   If you only need two instances of Jdeveloper you can get away with using one installation and two shortcuts, one with -su and one without and you will be using two different system directories.  Starting up Jdeveloper with either shortcut will load the project you last had open using that shortcut and the system directory will contain a separate build so you won't need to perform a clean and rebuild all each time you switch branches.  Just close Jdeveloper and run the other one.

Instead of installing extra jdeveloper installations I recently discovered (as mentioned in the linked documentation above) that I can specify the system directory on the command line.  So I created a separate shortcut for each branch and they all use the same jdeveloper installation but different system directories  


The link looks like this.
C:\JDev11g\jdeveloper\jdev\bin\jdev.exe -J-Dide.user.dir=c:/mywork/system/dev

Another link might look like this
C:\JDev11g\jdeveloper\jdev\bin\jdev.exe -J-Dide.user.dir=c:/mywork/system/qa