Hi Jim,
just out of curiousity: why do you enclose the last
commandbutton in a <af:subform default="true">? What is the
effect?
I played around with subforms today, too, but failed to get
what I wanted to achieve.
If you're interested, here is what I wanted to do.
Originally I had:
<af:form>
<af:inputText label="ABC" value"..." > <!--
with validation! -->
...
<af:selectBooleanCheckbox autoSubmit="true"
label="Enable XYZ" value="#{enableXYZ}"/>
<af:inputText label="XYZ parameter"
disabled="#{!enableXYZ}"/>
...
<af:commandButton label="Submit"
.../>
</af:form>
There is a problem with this: when clicking on the
checkbox, the form is validated. When the validation fails, the form is broken
(checkbox enabled though "XYZ parameter" field disabled.
So, I thought I have to find a way to bypass the validation
for the autosubmit of the checkbox. Immediate=true didn't solve it, so I tried
to do the following with subforms:
<af:form>
<af:subform default="true"
<af:inputText label="ABC" value"..."
> <!-- with validation! -->
</af:subform>
...
<af:subform>
<af:selectBooleanCheckbox
autoSubmit="true" label="Enable XYZ"
value="#{enableXYZ}"/>
<af:inputText label="XYZ parameter"
disabled="#{!enableXYZ}"
</af:subform>
...
<af:commandButton label="Submit"
.../>
</af:form>
Still, the validation happened on autoSubmit. When I put
default="false", then there was no validation, but on submit the values of the
first subform were not saved. After trying some more different arrangements, I
gave up.
Frank Felix
Hi
Everyone,
I'm having some
problems with form validation in ADF. I have a form with multiple sections
that need to be validated separately - the reason is that some commandButtons do
things like add a selection to a list that is built up as the form is filled out
(e.g. a list of key-value properties where you can add a new key value pair or
delete existing ones in the list). In those cases I don't want the main
form validation to happen and block submission. For a while I was using
buttons with immediate="true", but that means that the values that you are
interested in don't get written into their backing beans before your action
method is called. Now I was getting around this by binding the control to
a backing bean and getting the value directly from the control object. But
I thought that was a bit horrible - additionally if the field I need is a Choice
box then I can only get the index of the selected item and have to look it up
all over again. That works, but I wanted to find a better way. I
thought I had when I (again) tried using <af:subform>. I'm trying to
do this (I've simplified it):
<af:form>
<af:subform default="true">
<!-- some fields I want validated when the form is complete
-->
<af:inputText ..../>
<af:inputText ..../>
<af:inputText ..../>
</af:subform>
<!-- my properties
table -->
<af:table
values="backingBean.propertiesList" var="property">
<af:column>
<af:outputText
value="#{property.key}"
</af:column>
<af:column>
<af:outputText
value="#{property.value}"
</af:column>
<f:facet name="actions">
<af:subform>
<af:inputText
value="#{backingBean.newKey}">
<af:inputText
value="#{backingBean.newValue}">
<af:commandButton
action="">
</af:subform>
</f:facet>
</af:table>
<af:subform>
<!-- some more fields I want validated when the form is complete
-->
<af:inputText .../>
<af:inputText .../>
</af:subform>
<!--
submit the complete form -->
<af:subform default="true">
<af:commandButton action="">
</af:subform>
</af:form>
which all works
great except that anything sitting in the input fields of the subforms other
than the one submitted is wiped. The wierd thing is that the fields in the
other (non default=true) subforms stay populated. The reason I thought
this would work is the docs:
A UIXSubform
will always allow
the "Apply Request Values" phase to execute for its children, even when not
"submitted", but when not "submitted", the "Process Validations" and "Update
Model Values" phases will be skipped. This differs from an ordinary form
component, which, when not submitted, does not (and cannot) run "Apply Request
Values" either.
UIXSubform and "default"
In some scenarios, there may be buttons (or other components that submit the
page) outside of the main content of a page. If this main content is in a
UIXSubform, it could not be fully processed whenever those buttons are clicked,
since those buttons aren't inside of the UIXSubform. To support this scenario,
ADF Faces supports a "default" property on UIXSubform. A "default" subform
behaves like any other subform in most respects, but if no subforms are
"submitted" - if no subform has an appropriate event come from its children -
then all "default" subforms act as if they are "submitted".
The first paragraph
seems to imply that just the Apply Request Values phase will be executed for the
'unsubmitted' subforms, but shouldn't this be enough to maintain their values on
the page? Am I missing something?
Anyone any
ideas?
Jim
--
Jim
Moores