How to display error messages in editable tables
Jonas de Graaff
- Declarative or programmatic attribute-level validation rules.
Example: Salary must be less than 50000
Definition: Compare validator on Salary - Declarative entity-level validation rules that can be linked to an attribute.
Example: An employee cannot be his own manager
Definition: Compare validator based on EmployeeId and ManagerId + Triggering attributes EmployeeId and ManagerId
- Declarative or programmatic entity-level validation rules that cannot be linked to an attribute.
Example: Salary must be less than 40000 for department 100
Definition: Script validator + Triggering attributes Salary and Department
- Validation rules only forced by the underlying DB-package
Example: Not very useful in the HR situation, but just for the example: Salary must be between min and max salary of job
Defintion: PLSQL package called by the doDML method of the entity object, returning an error when the rule is not met. If an errorcode is returned we throw a new JboException.
- Change the salary of employee 100 into 55000 and select a different row.
Expected outcome: A red box around the Salary field with an error message
Actual outcome: Nothing, until I found out that this only works properly when the rangesize of the table > number of rows displayed! (Is this a bug?)
Change the rangesize of the table into e.g. 50 so it will be more than the number of rows displayed. - Rollback. Change the ManagerId of employee 101 into 101 and select a different row.
Expected outcome: A red box around the Manager field with an error message
Actual outcome: A red box around the Manager field with an error message: so this is OK
- Rollback. Change the Salary of an employee from department 100 into 43000 and select a different row.
Expected outcome: A red box around the Salary or Department field with an error message.
Actual outcome: A message popup with the errormessage 'Salary must be less than 40000 for department 100'. The rowselection is changed to the different row.
Since I have defined the triggering attributes, I would have expected the framework to highlight one of these fields as the 'errorfield'. Now I only get an errormessage and the rowselection is changed. So it is not clear to the end user which row caused the error. In the old Forms world this error-row became the current row. Ofcourse we can add identifying information to the error-message, but this is not very user-friendly compared to the red-box functionality of the attribute validation. The user has to find the row(s) in the list based on an identifier that is not always as simple as an EmployeeId. What I would like to see is a kind of error-indicator (!) on the rowlevel indicating which rows contain errors.
-
Rollback. Change the salary of two or more employees so the salary does not fall between the min and max salary of their job. Press Commit.
Expected outcome: A list of the error messages returned from the database package.
Actual outcome: Only the first JboException from the doDml method is displayed. It seems bundled exception handling is not working for exceptions thrown from the doDml method.
Grant Ronald
mode = clickToEdit - there are a number of overheads and some subtle
nuances to a fully editable table which make it less desirable. Click
to edit should give you the full flexibility without these overheads.
Plus, I tried a couple of your use cases and all worked fine with
clickToEdit.
regards
Grant
p.s. I use this in my Forms to ADF case study
http://download.oracle.com/otn_hosted_doc/jdeveloper/11gdemos/SummitADF/SummitADF_Redevelopment.pdf
Jonas de Graaff wrote:
> We are in the startup phase of a redesign of a large Oracle Forms
> application based on ADF. Of course we encounter a lot of challenging
> issues. One of them has kept me busy for some time.
> Coming from a Form world our customers are used to edit data in
> tables. Going to an ADF world means, as we have heard an read many
> times, that we have to rethink the way our application and our screens
> are organized. The result of this thinking is that there is still some
> need to edit data in tables. In our situation we have implemented most
> of out business logic and validations in database-packages that
> maintain the tables. Of course we would like to use these packages.
> However only validating the data entered in the tables on commit time,
> based on the packages, is not very user-friendly. For this reason we
> have decided to also implement business rules in the model-layer on
> the entity objects.
>
> Now suppose, for the example, that we have the following kind of
> validation-rules for the HR employees data:
>
>
> 1. Declarative or programmatic attribute-level validation rules.
> Example: Salary must be less than 50000
> Definition: Compare validator on Salary
> 2. Declarative entity-level validation rules that can be linked to
> an attribute.
> Example: An employee cannot be his own manager
> Definition: Compare validator based on EmployeeId and ManagerId
> + Triggering attributes EmployeeId and ManagerId
> 3. Declarative or programmatic entity-level validation rules that
> cannot be linked to an attribute.
> Example: Salary must be less than 40000 for department 100
> Definition: Script validator + Triggering attributes Salary and
> Department
>
> 4. Validation rules only forced by the underlying DB-package
> Example: Not very useful in the HR situation, but just for the
> example: Salary must be between min and max salary of job
> Defintion: PLSQL package called by the doDML method of the
> entity object, returning an error when the rule is not met. If
> an errorcode is returned we throw a new JboException.
>
> Based on this model I created a simple DnD page with an editable table
> with editMode=editAll and rowSelecion=single. Furthermore I placed a
> commit and rollback button on the page. Now let's test the different
> rules:
>
>
> 1. Change the salary of employee 100 into 55000 and select a
> different row.
> Expected outcome: A red box around the Salary field with an
> error message
> Actual outcome: Nothing, until I found out that this only works
> properly when the rangesize of the table > number of rows
> displayed! (Is this a bug?)
>
> Change the rangesize of the table into e.g. 50 so it will be
> more than the number of rows displayed.
> 2. Rollback. Change the ManagerId of employee 101 into 101 and
> select a different row.
> Expected outcome: A red box around the Manager field with an
> error message
> Actual outcome: A red box around the Manager field with an error
> message: so this is OK
> 3. Rollback. Change the Salary of an employee from department 100
> into 43000 and select a different row.
> Expected outcome: A red box around the Salary
> or Department field with an error message.
> Actual outcome: A message popup with the errormessage 'Salary
> must be less than 40000 for department 100'. The rowselection is
> changed to the different row.
>
> Since I have defined the triggering attributes, I would have
> expected the framework to highlight one of these fields as the
> 'errorfield'. Now I only get an errormessage and the
> rowselection is changed. So it is not clear to the end user
> which row caused the error. In the old Forms world this
> error-row became the current row. Ofcourse we can add
> identifying information to the error-message, but this is not
> very user-friendly compared to the red-box functionality of the
> attribute validation. The user has to find the row(s) in the
> list based on an identifier that is not always as simple as an
> EmployeeId. What I would like to see is a kind of
> error-indicator (!) on the rowlevel indicating which rows
> contain errors.
> 4.
> Rollback. Change the salary of two or more employees so the
> salary does not fall between the min and max salary of their
> job. Press Commit.
> Expected outcome: A list of the error messages returned from the
> database package.
> Actual outcome: Only the first JboException from the doDml
> method is displayed. It seems bundled exception handling is not
> working for exceptions thrown from the doDml method.
>
>
> In the above situation we have 4 different validation scenario's in
> one application all resulting in different ways the errors are
> displayed in an editable table. What I would like is to present our
> customers with a more consistent way of displaying errors. For
> attribute level validations, and entity level validations that can
> directly be linked to an attribute, the error display using the red
> boxes goes fine. However for the remaining entity level validations
> (both coming from the BC layer and the DB layer) I would like to have
> a better way to display which errors occurred in which rows. It would
> be great if there was a red-box kind of error-indicator (!) on the
> rowlevel indicating and showing the errors for that row.
>
> So my questions to the community are:
> - Does my need to display rowlevel errors in a userfriendly and
> consistent way make sense or am I thinking to much in the old Forms way?
> - Has anyone any suggestions for the way my requirements can be met?
>
> Jonas de Graaff
> --
> You received this message because you are subscribed to the ADF
> Enterprise Methodology Group
> (http://groups.google.com/group/adf-methodology). To unsubscribe send
> email to adf-methodolo...@googlegroups.com
>
> All content to the ADF EMG lies under the Creative Commons Attribution
> 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/).
> Any content sourced must be attributed back to the ADF EMG with a link
> to the Google Group (http://groups.google.com/group/adf-methodology).
Jonas de Graaff
very useful. We did consider and test clickToEdit. Most of the cases
do work fine but we encountered the following problems:
1. Violate an entity-level rule that cannot be related an attribute
(testcase 3), and navigate to a different record. A popup is presented
with the related error message. So far so good. HOWEVER, the error
message is added to the list of error messages in the popup every time
you try to navigate away from the record.
2. Violate an attribute level rule (e.g. salary set for employee 100
to 55000) and use the scollbar to scroll to employee 175. The expected
outcome would be an error message for employee 100. The actual outcome
is that the changed value is reverted to its original value and there
is no error message. As far as I can analyze, this is caused because I
scroll out of the rangeset of 50 records. At first the invalid value
of 55000 is submitted and an error message is thrown. However due to
scrolling the error message disappears as a result of a new request.
The rangeset it changed an my submitted value is lost because it is
not stored in the model, and it is not stored in the clientside page.
This behaviour appears in version 11.1.1.4.0 both for editAll and
clickToEdit.
If I test the same scenario in 11.1.2.0.0 with editAll mode, I'm not
able to scroll out of the rangeset. That's good. However after the
scrolling, I don't get an error message anymore, not even at commit.
If I test the same scenario in 11.1.2.0.0 with clickToEdit mode, I'm
not able to scroll out of the rangeset. I receive an popup with the
error message. However, the error message is added to the list of
error messages in the popup every time I try to navigate away from the
record
3. Error messages thrown from the DB-layer are still not clearly
related to the error-records.
The behavior as mentioned under 1. and 2. is probably caused by a bug.
If this bug is fixed, the clickToEdit mode can be a good way to
display all model-based validations. But the error messages from the
DB still remain a problem.
What suprises me is that the way the framework handles errors in
editable tables seems not as robust as it was in the old Forms world.
The editAll mode is the default when I create a DnD editable table,
but as described this mode leads to inconsistent error messaging. The
clickToEdit mode offers some more consistency but it still has some
problems.
As mentioned in my initial post, I would like to know how other people
deal with these issues in their applications.
Regards,
Jonas
On Aug 9, 11:27 am, Grant Ronald <grant.ron...@oracle.com> wrote:
> Jonas, a quick response to your question - have you considered a edit
> mode = clickToEdit - there are a number of overheads and some subtle
> nuances to a fully editable table which make it less desirable. Click
> to edit should give you the full flexibility without these overheads.
> Plus, I tried a couple of your use cases and all worked fine with
> clickToEdit.
>
> regards
> Grant
> < 1KViewDownload- Hide quoted text -
>
> - Show quoted text -