Fancy inputsliders through declarative component

In one of our portals the user can use inputsliders to select different values. We made a fancy inputslider that shows not only a label, but also the minimum value and the maximum value allowed.
Next to the slider we have an inputText where the user can decide to type in the value, on this inputText we have a validator that also checks the min an max value.
The result looks like this:

The declarative component has 4 attributes: minval, maxval, value and label.
The code in the component definition is as followed:

The minvalue and maxvalue attributes are used for the labels, the minimum and maximum attribute on the inputNumberSlider and the validator on the inputText. The label attribute is used as label on the panelLabelAndMessage and the value attribute is used as value for the inputNumberSlider.

To illustrate an example of you easy it is to now use this declarative component I created a bean with five properties:

  public SliderBean()
  {
    lowpoint = 1;
    minval = 25;
    maxval = 75;
    highpoint = 100;
    value = 50;
  }

There are 3 sliders based on this properties, the first one to select the minimum value, the second one to select the maximum value and the last one to select a value.
It is very easy to create a slider based on this declarative component, all the code you need for 3 sliders is this:

Off course the page / sliders still need skinning, but you can look and play around with this example.

Get your version number from WebLogic

If you want to show the version of your application (for example in your template), you can get this from WebLogic in a bean. If you use the manifest.mf to set the Weblogic-Application-Version property, you can get this number with the help of the ApplicationVersionUtils. It’s in the package weblogic.application.utils:

 ApplicationVersionUtils.getCurrentVersionId();

Scope your breakpoints!

For something so simple, a breakpoint, this feature gave me a lot of headaches over the years. One off the things I find most frustrating is when I set a breakpoint in my source code and the debugger doesn’t stop on it. Recently a co-worker pointed out some great feature in the JDeveloper IDE: You can scope your breakpoints.

When working with small projects and workspaces for different functionality, we use a lot of libraries to include our jars, sources and docs. If you have a java file open from a different workspace, the debugger won’t always stop. 

The first sign is the red bullet without a green check in it. 

 

However, remember that if the class isn’t loaded by the compiler yet, the green check will also not show. If you know for sure that the code has been fired, for example because you see logging, but the debugger doesn’t stop there and the bullet is still red without a green check, scoping might be the answer!

One option is to Scope an individual breakpoint, you can do this in your breakpoints view, right click on it and go to Change Scope, then select a different scope. The default is Workspace, I suggest you put it on Global.

Now, I can’t imagine why you would want something else then the Global scope, so luckily the JDeveloper IDE has a preference to set for this.
Go to Preferences -> Debugger -> Breakpoints, and you can change the scope for all your future breakpoints.

This will result in happy green checks on your red bullets!