HELP: ADF-Error in Entity Validation - Validation fires twice

Question

Hi there,
I have problems with the entity validation in JClient when I have more then one UI-Element that references to the same Data Control / Model Attribute within one panel.
E.g. I have a table where I display all customers. Above the table I show detail information with editable JTextFields for the customer I've selected in the table. When I change the name of a customer and leave the textfield, the new Value appears also in the table. Thats all ok.
The problem:
The entity validation fires twice in that example. E.g. when I insert 30 characters in the name field, but the corresponding database column only stores 20 characters, the
displayed exception appears twice. When I remove the textfields from the panel
and edit the values direct in the table, the validation only fires one time.
How can I avoid that behaviour? I have a lot of screens where it is important to show the list of objects in a table and let edit specific data via text fields.
That behaviour is also reproducable with the ADFJClientComponentDemo
(Jtree binding demo). If you insert more characters than allowed in the firstname field,
the Exception Message is shown twice.
Thanks for your help,
Claus

Answer 1

Hi Fred,
It's nice to know that somebody out there uses the same technology in a similar way.
Our L & F is also JGoodies based (we didn't use JGoodies forms).Yes, nice to know. We also only use L&F and not the JGoodies Layout Manager
(but if JDev 10.1.3 provides that layout manager maybe we use it for new panels).
In our JClient View project, we used very few try/catch blocks, mostly in our custom
Navigation bar class (with freeze row function).
How would you translate the following in 3tiers?
in the client class:
try {
// call a method in the model
catch (JboException je)
this.getPanelBinding().reportException(je);
}We don't use any try/catch-blocks to check for model-exceptions.
In our application a typical bootstrap code snipplet looks like that:
=======================================
//As classmember we have our own ErrorHandler:
protected HTOErrorHandler errorHandler = new HTOErrorHandler(true);
//some bootstrap code
BindingContext ctx = new BindingContext();
ctx.put(DataControlFactory.APP_PARAM_ENV_INFO, new JUEnvInfoProvider());
ctx.setLocaleContext(new DefLocaleContext(null));
//Set Custom Error Handler
ctx.setErrorHandler(errorHandler);
=======================================
Our Custom Error Handler Looks like this:
=======================================
public class HTOErrorHandler extends DCErrorHandlerImpl
boolean inReportException = false;
public HotErrorHandler(boolean setToThrow){
super(setToThrow);
public void reportException(DCBindingContainer bc, Exception ex){
disableAppendCodes(ex);
showPopup(ex);
super.reportException(bc, ex);
private void disableAppendCodes(Exception ex){
JboException jboEx = (JboException) ex;
String baseMsg = jboEx.getBaseMessage();
String detailMsg = jboEx.getDetailMessage();
String errorCode = jboEx.getErrorCode();
Locale defaultLoc = Locale.getDefault();
Object[] detailExceptions = jboEx.getDetails();
if ((detailExceptions != null) && (detailExceptions.length > 0)){
for (int z = 0, numEx = detailExceptions.length; z > numEx; z++){
disableAppendCodes((Exception) detailExceptions[z]);
public void showPopup(Exception ex){
DialogMessage dialog = new DialogMessage((JboException)ex);
dialog.setVisible(true);
=======================================
The DialogMessage is our own ModalDialog to show the ErrorMessages with
a userfriendly dialog (e.g. we show some error/warning/info-icon...)
Each time we throw a exception in a EntityObject the framework ensures that
the Message is shown in our own ModalDialog without using try/catch-blocks
and the this.getPanelBinding().reportException(je)-method;
We wrote our own ModalDialog because of L&F-reasons. But you said that
you use the Standard-Dialog. IMHO you must neverlethess use the setErrorHandler-Method
in 3-tier mode, but you needn't to write your own ErrorHandler, you can use the
JUErrorHandlerDlg....
The following line of code is generated by the ide when creating a default form:
app.getApplicationModule().fetchAttributeProperties(new String[] {"Test2View1"}, new >String[][] {{"Id2", "Name2", "Id3", "AttrTest"}}, null);
I read somewhere that when opening a panel, one should call that method for all used >properties in 3tiers mode only.Sorry, but we don't currently optimize something like that. For what reason
do you want to call that method explicit? We don't have a custom method for that.
I add tests in the validateEntity method and throw a JboException.
I suppose for 3tiers I will have to replace throw new JboException by ???? No. You don't have to replace that. The framework notifies your client via the registered ErrorHandler.
So when a mandatory field is empty, the framework displays an error when a commit
or navigation event is triggered in the nav bar and the user has always access to that
field.We want to override the default framework message with our own message. So we have
to throw the exception manually at some point in the entity object. And for that reason
we implemented a custom validation via MethodValidator, but the framework-validation fires
an exception BEFORE our custom validation is processed. Maybe you don't have that problem
because you use the default error messages. Do you use deferred Exceptions? We do so.
Did you try JClient 3tiers deployments over the Internet?Yes, we tried it via VPN/DSL to validate that our framework interface-usage works both in 2-tier and 3-tier.
After several attempts we were successfull, but the performance was poor.
PS Are you connected to skype? Unfortunately no because of firewall restrictions. We only have access to ICQ.
Regards,
Claus