Issue with SRDemo error handling

Question

Hi All,
Glad the forums are back up and running. In debugging some error-handling issues in our own application, I found an issue in the error handling code of SRDemo. I thought I'd post the issue here, as many of us (myself included) use some SRDemo code as the basis for our own applications.
The issue can be found in the oracle.srdemo.view.frameworkExt.SRDemoPageLifecycle class, specifically in the translateExceptionToFacesErrors method. I'll show the code that has the issue first, and explain the issue afterwards:
        if (numAttr > 0) {
            Iterator i = attributeErrors.keySet().iterator();
            while (i.hasNext()) {
                String attrNameKey = (String)i.next();
                 * Only add the error to show to the user if it was related
                 * to a field they can see on the screen. We accomplish this
                 * by checking whether there is a control binding in the current
                 * binding container by the same name as the attribute with
                 * the related exception that was reported.
                ControlBinding cb =
                    ADFUtils.findControlBinding(bc, attrNameKey);
                if (cb != null) {
                    String msg = (String)attributeErrors.get(attrNameKey);
                    if (cb instanceof JUCtrlAttrsBinding) {
                        attrNameKey = ((JUCtrlAttrsBinding)cb).getLabel();
                    JSFUtils.addFacesErrorMessage(attrNameKey, msg);
            }Now, this bit of code attempts to be "smart" and only show error messages relating to attributes if those attributes are in fact displayed on the screen. It does so by using a utility method to find a control binding for the attribute name. There are two issues with this code, one obvious, and one that is a bit more subtle.
The obvious issue: if there is a binding in the page definition, it doesn't necessarily mean that the attribute is shown on the screen. It's a good approximation, but not exact.
The other issue is more subtle, and led to errors being "eaten," or not shown, in our application. The issue comes if you are using an af:table to display and update your data. In that case, the findControlBinding will not find anything for that attribute, since the attribute is contained within a table binding.
Just posting this as a word to the wary.
Best,
john

Answer 1

somehow, this message got in the wrong thread....
Hi Frank,
Yes, I simply scripted it out this way to contrast the behaviour if the first attribute was read-only vs not read-only. I found the issue on a page in our app that was simply drag-and-drop the VO from the data control on the page.
It's quite annoying, because our particular use case that hit this error is a "save" button on the page. If the commit operation doesn't return any errors (and it doesn't in this use case!), we add a JSF message saying "save successful" - then the attribute errors are further added later in the page lifecycle, so we get 3 messages: "Save successful" and "Fix this error" and "Tried to set read-only attribute" - quite confusing to the end-user when the only message they should see is "fix this error."
At any rate, the fix is to simply re-order the attributes in the page definition - that doesn't affect the UI at all, other than to fix this issue.
John
it was supposed to be something like:
Hi Frank,
Thanks for the reply. I was simply posting this here so that people who use the SRDemo application techniques as a basis for developing the same functionality in their own apps (like me) can be aware of the issue, and avoid lots of head-scratching to figure out "what happened to the error message?"
John