 |
Errata
|
 |
Oracle JDeveloper 10g for Forms
&
PL/SQL Developers
A Guide to Web Development with Oracle ADF
This page documents mistakes, clarifications or improvements
that we discover in
the book post publication.
Book Subtitle
Do you already have a copy of the first edition? - well if you do hang
onto it, it's a rarity. It turns out that the subtitle of the book on
the first print run contained a subtle mistake labeling the book as A Guide to J2EE Development with
Oracle ADF, rather than A Guide to Web Development with
Oracle ADF .
We felt that this was not a significant enough error to reprint, as a
quick read of the intro makes it clear that the focus here is
specifically on J2EE Web development rather than the broader topic J2EE
as a whole.
Improvement to the SQL Injection Detection Code
Markus Heinisch pointed out a possible flaw in the supplied code for
getViewCriteriaClause(). Although this code works correctly for the
TUHRA example, if you reuse it you could run into a problem. If your
view objects use transient attributes that are not directly based on a
column in the underlying table you could end up with a Null Pointer Exception. Markus proposed a simple solution to
this, which is to explicitly check the isQueriable() property of the
attribute definition before getting the column name and appending it to
the list to check. Something like this:
for (AttributeDef attr: attrs) {
if (attr.isQueriable()){
columnNameListBuff.append(attr.getColumnName().toUpperCase());
columnNameListBuff.append('|');
}
}
Thanks to Markus for that useful enhancement!
Using JDeveloper 10.1.3.1. - Beware of Bug 5665931
Readers who have upgraded to JDeveloper 10.1.3.1 and use that as the
version to work through the examples have reported hitting Bug 5665931
in the product. This bug causes the template page not to be
rendered in WYSIWYG in the visual editor - instead you just see the tag
placeholders. The bug is a design time annoyance only. To work around
this you have two choices, either use a 10.1.3.0 version of JDeveloper,
or store the template file somewhere other than under WEB-INF/ under
the public_html structure (e.g. create a new top level directory called
templates) . The only reason we store the template under WEB-INF is
because files there are not directly runnable, and the
template has not life of it's own to be worth running standalone.
In reality you'd simply not include the template in the
distributed application.
JSPX v's JSP Revisited
In the TUHRA sample we have adopted conventional JSP as the basic
format for our pages. Well things evolve and we'd now recommend
that you actually adopt JSPX (JSP Documents) as your preferred format.
This has no effect on an application as it stands today, however,
because JSPX documents are well formed XML it does mean that future
migration to use new JSF components will be much easier. If the page
description is in XML then an XSLT style-sheet can be used to transform
from one component set to another without too much manual intervention.
So this is all about future proofing your applications.