Community
Participate
Working Groups
The Faces Config Editor is not ensuring that navigation case "from-action" element values correspond to expected syntax. In Faces 1.2, this becomes a bigger problem (although it's also true in 1.1) since the XSD schema flags a pattern match error. The syntax must match EL syntax, i.e. #{var.prop}.
Triaged for WP 2.0.
Consider for 3.0
Deferred due to lack of resources.
This is really confusing to the end user, since as long as you add a navigation rule (through the editor's UI!) the faces-config is marked with two errors. The user obviously didn't do anything wrong, why the errors? And, of course, the errors are cryptic enough to confuse the user and not make it clear how to fix the problem. This is what I see in the Problems view: cvc-complex-type.2.2: Element 'from-action' must have no element [children], and the value must be valid cvc-pattern-valid: Value ' #{pc_P1.doButton1Action}' is not facet-valid with respect to pattern '#\{.*\}' for type 'faces-config-el-expressionType'.
I agree the error is confusing to the users and is not easy to resolve. We will review this bug in detail, but it could be an issue with a subsystem. Workaround: Removing the whitesapace around the from-action element fixes the issue: <from-action>#{loginBean.doLogin}</from-action>
Created attachment 98919 [details] proposed fix
I looked at this problem and found that it's related to the use of getTextContent() as the getter for an element's body text (which is signified by using the TEXT_ATTRIBUTE_VALUE constant for a Translator class). I found a similar situation with the web.xml EMF model and that example put me on the track of using a slightly different constructor in the Translator classes for the various faces-config elements. If instead of using this call to the super constructor: public FromActionTranslator(String domNameAndPath, EStructuralFeature aFeature) { super(domNameAndPath, aFeature); } we instead use ... public FromActionTranslator(String domNameAndPath, EStructuralFeature aFeature) { super(domNameAndPath, aFeature, END_TAG_NO_INDENT); } ... then the additional END_TAG_NO_INDENT parameter causes the emitted XML to be properly written wihtout linebreaks and extraneous indenting as a continuous start-tag/body/end-tag string. Not only does this fix the reported problem which affects all pattern-based strings in the schema, but it also improves readability of the total faces-config file. I've attached a proposed patch that makes this change for all the "text content" elements in the EMF model.
Thanks for looking into this issue and the patch. We will review the patch. If this is an issue that must be fixed in 3.0, please raise the Priority on the bug.
I can't seem to change the priority myself but we would really like this fix in 3.0. Could somebody bump it up? Thanks.
The Faces Config Editor incorrectly reports error and as detailed in Comment 4, this is confusing to the user and there is no obvious way for the user to 'fix' the error. This is an adopter requested fix. We have reviewed the patch and find it safe and low risk. Requesting PMC approval.
Well ... since it's for Scott ... :)
Patch checked-in 5/9/08.
This only fixes part of the original issue. I can still enter "foo" for the from-action in the navigation rule property editor (right-click on the link between two nodes in the navigation editor and select "Show Properties"), and it allows the source to be updated with it. The syntax must match the #{} EL expression to be correct. It will flagged immediately by the WST schema validator if the file is >=1.2 and our own JSF validator will flag it if it's <=1.1. The editor should not allow the user to accept data values that it can easily verify are incorrect.
Re-marking as fixed. Bug has been cloned as bug 247274 for future consideration.
Typo above. Bug has been cloned as bug 247374 for future consideration.
