That's exactly how it's supposed to work :-)

I don't know the syntax for (or even if it's possible with) Trinidad's
subform, but the Tomahawk sandbox subform can be submitted by
explicitly providing an "actionFor" attribute on your t:commandButton
which lists out which subForms should be submitted.   I think I saw a
previous post where this hadn't been added to the Trinidad subform
yet.

<h:form>
   <sandbox:subForm id="mysubform">
      <tr:inputText value="#{pageFlowScope.inputValue}" label="Input"
required="true" />
   <sandbox:subForm>
   <t:commandButton text="Submit" actionFor="mysubform" action="doIt"/>
</tr:form>


On 4/24/07, D. Cardon <[EMAIL PROTECTED]> wrote:
I don't know if this is a related issue (it seems to be to me), but subform 
validation does not
occur when a parent form is submitted.  I.e., say that I have a form with a 
subform in it and a
submit button outside of the subform---like this:

<tr:form>
   <tr:subform>
      <tr:inputText value="#{pageFlowScope.inputValue}" label="Input" 
required="true" />
   </tr:subform>

   <tr:commandButton text="Submit" action="doIt"/>

</tr:form>

If I press the command button, then the parent form will submit even if the 
required field is left
empty!  It doesn't seem as if that is how it is supposed to work, but I don't 
know.

--David

--- Adam Winer <[EMAIL PROTECTED]> wrote:

> It's a known limitation of how subforms are implemented:
> they look for FacesEvents queued during processDecodes()
> to see if that subtree should be further processed.  However,
> autoSubmit components don't queue a FacesEvent until
> ValueChangeEvent, which happens later in the cycle.
>
> It should get fixed, though.
>
> -- Adam
>
>
> On 4/24/07, D. Cardon <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I've done some more testing with the subform functionality in Trinidad and
> > think I've isolated a bug with a very simple test case.  To reproduce this
> > functionality, a few modifications need to be made to the blank project 
that is
> > found in the trinidad repository.  Here's what to do:
> >
> > - Modify the index.jspx entry for the tr:inputText, replacing it with:
> >
> > <tr:inputText label="Your name" id="input1" 
value="#{helloWorldBacking.name}"
> >   autoSubmit="true" valueChangeListener="#{helloWorldBacking.changeMethod}" 
/>
> >
> > Then, implement the changeMethod in the backing bean:
> >
> >   public void changeMethod( ValueChangeEvent event )
> >   {
> >           System.out.println( "Change method called!" );
> >   }
> >
> > Now, test the page by entering a value into the test field and then tabbing
> > away from it.  This will fire the field to be submitted.  In your console, 
you
> > should see the "Change method called!" message appearing--this behaves as
> > expected.
> >
> > To reproduce the invalid behavior with a subform, alter index.jspx 
slightly, by
> > wrapping the inputText (or its containing component) in a tr:subform tag.
> > Reloading the page and performing the test again, you should no longer see 
the
> > "Change method called!" message.  This behavior appears to be the same for 
any
> > component set to autoSubmit.
> >
> > After digging into the code somewhat, it appears that the subform is unaware
> > that the inputText component has changed and so it does not run its children
> > through the necessary phases.
> >
> > The root of this symptom actually relates to a lot of other problems with 
the
> > subform tag.  For example, using the subform to isolate regions for 
validation
> > does not work at all due to this issue, because validations are not 
processed
> > and model values are not updated for the components in the subform.
> >
> > Since I'm a new Trinidad user, I don't really know how this should be 
reported.
> >  I did sign up for JIRA, but I'm not sure what the severity of the issue 
should
> > be.  Also, it would be reassuring if someone else can reproduce this, that
> > would verify that it's not just some problem with my machine / setup.
> >
> > Thanks,
> >
> > --David
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
>


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Reply via email to