Region Best Practices post on David Giammona’s Blog

January 26, 2009

David Giammona, whose blog has somehow escaped my notice until today, has written an excellent whitepaper on best pratices for sharing data and intitating navigation within regions. You can read about it here


Cuil seach not so cool

July 28, 2008

Not really on-topic to my usual ADF postings, but I read a news article today about a new search engine (www.cuil.com) that was supposed to be a challenger to Google. I did a search or two, and really liked the layout of the search results. Then I did what everyone does with a search engine (search for his or her own name) and searched on “John Stegeman Jdeveloper” – that’s when I started to dislike the engine.

Here’s a few of the pictures that were included next to various results:

who is that guy?

this one shows up next to a blurb about one of my blog posts on Steve M’s blog.. Steve has more hair than that!

I’m not Don Burleson!

I’ve got a few years on him…

Another one next to a Steve M blog post…

I guess I don’t like cuil that much after all


How not to ask a question

July 7, 2008

Well, I’m back to the blog after a long hiatus. Much like Tom Kyte, I seem to be getting much grouchier lately. No, it isn’t age, the weather, or the fact that <insert name of sports team here> didn’t win the <insert name of major sporting event here>, it’s the fact that quality of the questions over on the JDeveloper Forum seem to be going downhill lately. Yes, there are some people who still take their time to post well thought-out questions that include versions, a description of what they are trying to do, what they have tried, what they found when googling, etc.; however, there seems to be a growing number who:

  • Obviously haven’t or are too lazy to click the “search” button or use Google to find the solution.
  • Clearly think their time is too valuable to waste over posting more than one sentence plus the obligatory “PLZZZ its URGENT.”
  • Post to the wrong forum. The OA Framework people seem to be pretty notorious for this.
  • Don’t want to try to solve the problem themselves. Sometimes, I’ll drop a hint for such questioners, but it’s usually firmly ignored.
  • (had to come back and update this post about this one) Post their question as a reply to another question from 3 years ago asking the original poster (who often hasn’t posted anything in the intervening 3 years) “did you solve this?”

Now, I know we all don’t have scads of free time, but it seems to me just common courtesy to invest at least some time in researching and debugging on your own before posting a question and similarly investing some time in phrasing a proper question with details, use case, etc? The people who are answering questions on the forum are usually doing so on their own time and really do want to help, but I am finding that I’m less and less motivated to answer questions when I see more and more people commiting blunders like this. I’m guessing that I’m starting to sound like an old f*rt on the forums now. Sure, it’s fun posting sarcastic replies (depending upon my mood at the time), but I really do start to notice my blood pressure going up nowadays.

Is it just me?


Using a custom login module in JDeveloper 11g TP2

December 18, 2007

It’s been a while since I’ve posted here – working on client projects and attending/presenting at a conference here or there takes up a bit of time.

Now that things have cooled off a bit for the holidays, I took the opportunity to attempt migrating a JDeveloper 10.1.3.3 ADF BC/ADF Faces application to the 11g  TP2 release of JDeveloper. The migration was, for the most part, pretty smooth… that is, until I tried to run the application. The application uses a custom Login Module to handle authentication; I tried setting up JDeveloper 11g the same way I set up 10.1.3.3 only to (eventually) discover that JDev 11g doesn’t use JAAS, but uses something new called “JPS;” of course, there’s no documentation yet.

I tried my usual best effort of munging about with the jps-config.xml file with no success. Then, out of frustration more than anything, I stumbled upon the “ADF Security Wizard” lurking up there in the “Tools” menu. The nice thing about this wizard is that it (on step 6 of 9) provides a nice dialog box for configuring login modules for the application. Furthermore, it creates an application-specific jps-config.xml in your application directory, and does not modify the global one in the oc4j config directory. Whoo hoo! No more manually editing system-jazn-data.xml every time I need to switch to a different application with a differing login strategy

Happy Christmas to all!


Frequently asked questions, or "the human Google"

June 28, 2007

I really like the JDeveloper Forum on OTN. I have a little desktop widget that uses RSS to show the latest posts as they come in. I read the forum almost like a Blog – it’s always interesting, informative, and helpful to see what issues people are grappling with; lots of times, I get new ideas to try by reading posts there. I also try to answer as many of the questions that come up as I can. Why? The forum was helpful to me starting out, and, personally, I’d like to see others be successful with JDeveloper and the marketplace for JDeveloper to grow – purely for selfish reasons. I’m a consultant, and the more potential customers use JDeveloper and Oracle stuff, the more potential customers for me and the company I work for.

As I read the posts, there are some that just come up over and over and over and over. Lots of times, I’ll answer the questions by doing a quick search on the forum and posting the link (hence “the human Google”). So I thought I’d compile a list of questions and answers here, sort of an unofficial FAQ. For what it’s worth, I mostly use ADF Business Components and ADF Faces – not much of an EJB/Swing guy at the moment, so don’t expect to see Swing/EJB questions.

By the way, if there’s a better answer somewhere or something that should be added, let me know and I’ll update the list – just post a comment to this entry.

Some of the questions/answers are a bit tongue-in-cheek ;)


Question: I’d like to create a page to frobdigate the whigginator. It’s urgent so please help me!

Answer: Would you now? Honestly, there are a fair number of questions on the forum that are about this comprehensible. If you want a good answer, be sure to provide enough information so that the readers at least know what you’re talking about.


Question: When will version xyz of JDeveloper be available?

Answer: When it’s ready. I’ve been guilty of asking this question a few times myself.


Question: How do I convert among java.util.Date and oracle.jbo.domain.Date and java.sql.Date

Answer: Here’s a good post that gives a few examples.


Question: How can I create two drop-down list boxes (af:selectOneChoice) such that when I pick a value from the first one, it changes the values in the second one – for example, when I pick the State from the first, the second one should contain a list of cities in that state?

Answer: Frank Nimphius of Oracle has written about this.


Question: I want to add security to my Faces application where I can validate the username and password against a database table. How do I do that?

Answer: Here’s one way.


Question: blah blah blah OAF blah blah Oracle Applications Framework blah blah OA Framework?

Answer: Try the OA Framework forum on OTN.


Question: I want to have a gap-less sequence number as the key for my table, how

Answer: No, you don’t.


Question: but I wasn’t finished with my question yet.

Answer: Yes you were.


Question: OK, I understand I should use a database sequence. Why is the number negative/how do I use the sequence?

Answer: Have a read of the ADF Developer’s Guide for Forms/4GL Developers, section 6.6.3.8 for starters. Then, read the rest of that document ;)


Question: How can I display images that are stored in a blob in the database?

Answer: Read this post


Question: How can I use a drop-down list (af:selectOneChoice) inside of an editable table (af:table)?

Answer: Steve Muench of Oracle did a nice screencast showing how to do that.


Question: How can I call a stored procedure from my application module code? I don’t want to open a new database connection

Answer: Check out this post.


Question: I am trying to connect to my Oracle XE database and am getting errors. What do I need to do?

Answer: The Oracle XE connection information is localhost:1521:XE. Most likely, you forgot to change the SID from “ORCL” to “XE” when you set up the connection.


Question: How do I get the selected label of an af:selectOneChoice? Every time I try, I just get a number

Answer: Frank Nimphius to the rescue again.


Question: How do I highlight the selected row in an af:table?

Answer: Check out this post for a couple of answers.


Who likes JDeveloper and who pooh-poohs?

June 5, 2007

Jan Vervecken started a recent thread on the OTN JDeveloper Forum entitled, “The forgotten Java IDE?” It’s quickly garnered a lot of replies (57 at the current count!). It’s lead me to do some thinking and some researching around the Web.

To paraphrase both Blondie aka “the man with no name” (Clint Eastwood) and Tuco (Eli Wallach) as they were wont to say in my all-time favorite movie, “There are two types of people in the world my friend, those who like JDeveloper, and those who pooh-pooh it.” Well, the world is more complex than that, but it seems to be the case that a given person either loves JDeveloper, or thinks it’s completely useless and irrelevant. Can both types of people be talking about the same thing?

In my experience on the OTN forums, at Java One, and from reading blogs and other Internet posts, I’ve been able to create some stereotypes of the two types of people, and gain some insight into the “why” of the stereotypes.

People who like JDeveloper tend to:

  • Already be Oracle customers
  • Have experience with 4GL languages, especially Oracle Forms
  • Use Oracle’s Application Development Framework (ADF)
  • Like the integrated SOA development tools in JDeveloper

People who pooh-pooh JDeveloper tend to:

  • Think of themselves as “hard-core” java programmers or “java gurus”
  • Dislike anything “proprietary,” and thus tend to discount ADF
  • Really like open source, “free” things (although, as a sidebar, my friend always used to say, “if it’s free, I can’t afford it”)

People who have traditionally used Oracle’s (quite good) 4GL tools like Oracle Forms tend to be able to jump right in to ADF, with some training of course, and work in JDeveloper in a familiar paradigm. For them, learning Java/J2EE in the context of doing a JDeveloper/ADF project, tends to be, “teach me the syntax” and, “learn the ADF framework.” All of the J2EE complexity is hidden under the covers of the ADF framework for these folks.

The hard-core java guys, on the other hand, want to fiddle with every bit and byte. Now, in my opinion, JDeveloper can do this just as well, if not better, than the other IDE’s out there (Eclipse, Netbeans, IntelliJ, etc); however, most of these folks already have an established IDE preference, and changing IDE’s is something that requires a conscious effort and reason to change. Thus, even though I really like JDeveloper, and think it’s a world-class IDE, and would like more people to use it (selfish reasons, I guess – I want to ensure that Oracle will always be putting lots of effort into new releases), I would say to this group of people, “keep using whatever you are using.” If you want a nice productive database development environment, or a nice BPEL development environment, come on over and take a look. Heck, I’d be willing to bet that most of the hard-core guys, if they would be willing to take an honest look at ADF, would find that there are some good things there for them.

As to which type of person am I… I’ve got some characteristics of both. I’ve done some Oracle Forms (mostly Forms 2.3 and Forms 3.0!) programming in my life. I actually got my start doing more hard-core C/C++ programming and did “hard-core” java before I got into ADF; so I guess I don’t fit the stereotypes I’ve laid out here.

…..


Conditionally showing fields based upon attribute value part deux

June 3, 2007

This is the second in a two-part series showing how to conditionally show/hide fields based upon the value of another field. In case you haven’t read the first part, start here.

As we left before the commercial break, we had just set up the navigation links between our emplist and empedit pages. Let’s first fix up the “Edit” and “New Employee” buttons on the emplist page so that clicking them will take us to the edit page. To do this is really quite simple. For the edit button, select the button using either the visual editor or the structure window; then, use the property inspector to set the Action property to “edit,” which is the navigation case you created. There’s even a drop-down list in the property inspector – JDeveloper knows about the navigation cases, and thus can give you a drop-down list. Now, just do the same thing for the “New Employee” button; in this case, at run-time, the action listener (which creates the new employee record) will fire first, and then the action property causes the navigation case “edit” to fire, taking you to the empedit page.

Now, let’s create the skeleton of the empedit page. First, ensure empedit.jspx is shown in the visual editor. Then, in the data control palette, drag MyEmpView1 to the empedit.jspx page and drop it. In the pop-up menu, select “Forms” and then “ADF Form” from the sub-menu. Ensure the “Include Submit Button” checkbox is selected and click “OK.”

Let’s next add a commit button to the page so that the changes can be saved to the database. In the data control palette, expand the AppModuleDataControl and then expand the “operations” folder from the data control – be sure it’s the AppModuleDataControl’s operations folder, and not the MyEmpView1′s. If you have the correct one, you’ll see Commit and Rollback operations. Drag the commit operation and drop it on to the empedit.jspx page next to the submit button. In the pop-up menu, choose “ADF Command Button.” Finally, select the “Commit” button and use the property inspector to set the Action property to “returntolist.” This will make clicking the commit button take us back to the list page as well as committing the data to the database.

Now, we’ve got a basic working application. Let’s test it; right-click the emplist.jspx page in the applications navigator and choose “run.” You should see an (empty) list of employees. Click the “New Employee” button, fill in some values, and click commit. You can also test editing an employee you create (use the “submit” button to submit changes and make ADF enable the commit button). For now, create at least two employees, one with emptype of “H” and one with emptype of “S.” Here’s what my emplist.jspx looks like after I did that:


There’s a lot more we should to to make this a real application (adding a “Cancel” button, for example), but I’ll leave that to you. What we really want to show now is how to make the Salary field hidden (and set to null in the database) when the employee type is “hourly” and make the Hourly Rate field hidden (and set to null in the database) when the employee type is “salaried.” There are a number of ADF Faces controls we could use to implement this (they all start with “ShowOne”), but for this example, let’s use a ShowOneRadio.

In the Component Palette, ensure the ADF Faces Core components are showing and locate the ShowOneRadio. Drag it to the empedit page and drop it between the Emptype and Salary fields (it’s easiest if you use the Structure window). Use the property editor to change the label to “Employee Type.” You should now have something that looks like this:


The “ShowOne” components work by having “ShowDetail” components as their children. So, locate the ShowDetail component in the Component Palette and drag one to the af:showOneRadio you just created; again, it’s easiest if you use the Structure window to ensure you are dropping it on the right component. Use the property inspector to change the Text property to “Hourly.” Then, repeat the same process to create another ShowDetail component with its text set to “Salaried.” When you are done, the Structure should look something like this:


The next step is to put the Salary and HourlyRate fields into the appropriate ShowDetail component. To do this, just use the structure window to drag the Salary’s af:inputText component to the “Salaried” showDetailItem and the Hourly Rate’s af:inputText component to the “Hourly” showDetailItem. Your structure now should look like this:


If you run the application now, you’ll see that clicking the Hourly or Salaried radio buttons automatically hide/show the appropriate fields; however, the value of the EMPTYPE field doesn’t have anything to do with the radio buttons at this point. We’ll need to write some code to make that part work.

The code that you will write needs to be in a java class known as a “managed bean.” We’ll let JDeveloper create the managed bean for us. If you click one of the af:showDetailItem components and look in the Property Inspector, you’ll see a property called the “Disclosure Listener.” This is where we will write our Java code (for you experts out there, yes, the af:showOneRadio has an attribute change listener that is a better place for the code, but for some reason, it does not fire correctly in JDev 10.1.3.1). To create the managed bean, select the Hourly showDetailItem in the Structure window and then click in the blank field next to “DisclosureListener” in the Property Inspector. You should see a button appear with an elipsis (…) in the label – click this button. You’ll get a dialog that looks like this:


Click the “New…” button to create a new managed bean. Use “empedit_bean” for both the name and class and leave the scope set at request:


After clicking “OK”, click the “New…” button next to the Method drop-down list. Provide a method name of “hourly_disclosed” and click “OK.” The dialog now looks like this:


Click “OK” in the managed bean window. You should see a new tab at the top of the editor for the empedit_bean.java file that was just created. The code looks like this:

import oracle.adf.view.faces.event.DisclosureEvent;
public class empedit_bean
 {
 public empedit_bean()
 {
 }
public void hourly_disclosed(DisclosureEvent disclosureEvent)
 {
 // Add event code here...
 }
 }

Let’s add some simple code to the disclosure listener so that we can see how it works. Change the hourly_disclosed method so that it looks like this:

public void hourly_disclosed(DisclosureEvent disclosureEvent)
{
if (disclosureEvent.isExpanded())
{
System.out.println(“The hourly type was selected”);
}
else
{
System.out.println(“The hourly type was not selected”);
}
}

Now, let’s create a disclosure listener for the Salary radio button. Just type this code into the editor:

public void salaried_disclosed(DisclosureEvent disclosureEvent)
{
if (disclosureEvent.isExpanded())
{
System.out.println(“The salaried type was selected”);
}
else
{
System.out.println(“The salaried type was not selected”);
}
}

Finally, go back to the empedit.jspx page and select the af:showDetailItem for Salaried. In the property inspector, click the elipsis-button next to the DisclosureListener property and pick the empedit_bean managed bean and salaried_disclosed method:


Now, when you run the application and click the Hourly and Salaried radio buttons, you should see a pair of messages in the log window for each click. This shows us that our code is running correctly. We now just have two steps remaining. The first is to make the value in the database field EMPTYPE determine which radio button is selected. This is really quite simple. If you go back to the empedit.jspx page and select the “Hourly” af:showDetailItem, you’ll notice a property in the property inspector called “Disclosed,” which is set to false. What we will do is to use an Expression Language (EL) expression to set the item to be disclosed if the value of the EMPTYPE field in the database is “H.” To do so, click the Disclosed property in the inspector. You should see the “Bind to data” button become available in the property inspector toolbar – it looks like this:

Click the Bind to data button; this displays JDeveloper’s EL editor. In the editor, expand the ADF Bindings folder, then the bindings container. You should see an attribute binding for “Emptype.” Finally, expand that binding and double-click on the InputValue property. The Expression builder should now look like this:


Complete the expression by typing so that it reads:

#{bindings.Emptype.inputValue == “H”}

Remember before when we set the default value of the field EMPTYPE to “H?” This is so we didn’t have to code for the special NULL case here, although it’s not too difficult. Now, repeat the same process for the Salaried af:showDetailItem, except the “disclosed” property should be:

#{bindings.Emptype.inputValue == “S”}

At this point, if you run your application and edit the two employees you created earlier (one hourly and one salaried), you should see the correct radio button selected and the correct field shown.

We now just have some cosmetic issues to clean up (we still have the EMPTYPE field on the screen) and one remaining problem: clicking the Hourly and Salaried radio buttons do not change the value of the EMPTYPE field – we haven’t written the code to make this happen yet. Let’s start by getting rid of the EMPTYPE field. If you just click on the EMPTYPE af:inputText and delete it, it will also delete the binding in the underlying page definition, which will make our page break, because we use that binding. Here’s a little trick that I use to avoid this behavior. Before you delete the af:inputText item, open the page definition for empedit.jspx by right-clicking in an empty area of the empedit.jspx page and choosing Go to Page Definition. Now, you can go back to the empedit.jspx page and delete the EMPTYPE field. Now, just switch back to the page definition and close it, answering “no” when prompted to save changes.

The last item remaining is to set the value of the EMPTYPE field as we click the radio buttons for Hourly and Salaried employees. This code will go into the disclosure listeners. Let’s code a simple utility method into our backing bean that will allow us to set the employee type, and we can call that utility method from the disclosure listeners. For good measure, let’s also NULL out the salary for hourly employees and null out the hourly rate for salaried employees. I provide the code here with no explanation; this is pretty straightforward JSF code at this point:

private void setEmpType(String type)
{
FacesContext ctx = FacesContext.getCurrentInstance();
Application app = ctx.getApplication();
ValueBinding bind = app.createValueBinding("#{bindings.Emptype.inputValue}");
bind.setValue(ctx, type);

if (“S”.equals(type))
{
bind = app.createValueBinding(“#{bindings.Hourlyrate.inputValue}”);
}
else
{
bind = app.createValueBinding(“#{bindings.Salary.inputValue}”);
}

bind.setValue(ctx, null);
}

Now, it’s simply a matter of fixing up the disclosure listeners to look like this:

public void hourly_disclosed(DisclosureEvent disclosureEvent)
{
if (disclosureEvent.isExpanded())
{
setEmpType(“H”);
}

}

public void salaried_disclosed(DisclosureEvent disclosureEvent)
{
if (disclosureEvent.isExpanded())
{
setEmpType(“S”);
}
}

There we are…. there are lots of little things that can be cleaned up and made more robust, but that’s the technique.


Follow

Get every new post delivered to your Inbox.