You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Walter Mourão <wa...@gmail.com> on 2008/09/07 13:22:52 UTC
[Trinidad] Strange subform behavior
Hi folks,
I'm dealing with a strange behavior when using subforms and I reproduced it
using the trinidad-blank example (from 1.0.9, but I found the problem first
with 1.0.5).
When executing an action from subform 1, only the inputs of the subform 1
are refreshed and show the new value. Besides that, when I added a
tr:outputText to the subform, pointing to the same backing bean property, it
shows the new value, so the tr:inputText and tr:outputText (of the subform
2) shows differente values...
To reproduce using the trinidad-blank example:
1 - change HelloWorldBacking.send to:
public String send()
{
_name = _name.toUpperCase();
return null;
}
2 - add the file two_subforms.jspx with the content:
<?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:tr="http://myfaces.apache.org/trinidad" >
<jsp:directive.page contentType="text/html;charset=utf-8"/>
<f:view>
<tr:document title="Apache Trinidad Blank Demo">
<tr:form partialTriggers="sub1:button1 sub2:button1">
<tr:subform id="sub1">
<tr:panelPage>
<tr:outputText value="#{helloWorldBacking.name}" />
<tr:inputText label="Your name" id="input1"
value="#{helloWorldBacking.name}" required="true"/>
<tr:commandButton id="button1" text="press me"
action="#{helloWorldBacking.send}" partialSubmit="true"/>
</tr:panelPage>
</tr:subform>
<tr:subform id="sub2">
<tr:panelPage>
<tr:outputText value="#{helloWorldBacking.name}" />
<tr:inputText label="Your name" id="input1"
value="#{helloWorldBacking.name}" required="true"/>
<tr:commandButton id="button1" text="press me"
action="#{helloWorldBacking.send}" partialSubmit="true"/>
</tr:panelPage>
</tr:subform>
</tr:form>
</tr:document>
</f:view>
</jsp:root>
3 - start the application, go to /faces/two_subforms.jspx, add a text in one
of the inputs and click "press me".
This behavior happens with partialSubmit="false" too.
Please confirm if it is a bug (and I file a jira issue) and if it has an
workaround.
Thanks in advance,
Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br
Re: [Trinidad] Strange subform behavior
Posted by Simon Kitching <sk...@apache.org>.
Hi Walter,
I think this is the general approach needed for input components in
tables (untested):
int n = 0;
dataTable.setRowIndex(n);
while (dataTable.isRowAvailable()) {
// here apply the resetValues code for each component in the table
dataTable.setRowIndex(++n);
}
dataTable.setRowIndex(-1);
As an alternative, I think for myfaces that this single line will clear
*everything* from the components while still leaving the "value" EL
expression valid:
dataTable.setValue(null)
However that approach may not be portable to other JSF implementations.
Regards,
Simon
Walter Mourão schrieb:
> The resetValues method is working fine with editable values, but I
> could not figure out a way to make it work with tables...
>
> Hints ?
>
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>
>
> On Sun, Sep 21, 2008 at 9:34 AM, Walter Mourão
> <walter.mourao@gmail.com <ma...@gmail.com>> wrote:
>
> Thanks Volker, but if I return an outcome != null the PPR does not
> work.
>
> The solution I found so far was the creation of a resetValues
> method which resets the values of the editable components:
>
> ...
> private void resetValues(UIComponent uic){
> if(uic instanceof UIXEditableValue){
> ((UIXEditableValue)uic).resetValue();
> }
> for(UIComponent component: uic.getChildren()){
> resetValues(component);
> }
> }
>
> /**
> * Method that is backed to a submit button of a form.
> */
> public String send()
> {
> final FacesContext facesContext=FacesContext.getCurrentInstance();
> UIViewRoot viewRoot=facesContext.getViewRoot();
> resetValues(viewRoot);
> ...
>
> It is (apparently) working fine, incuding when using PPR. In know
> it works only with Trinidad components and later I will take a
> look at the UIXEditableValue.reset method to extend the solution
> to all JSF components. Despite the fact the resetValues method
> must be executed in each action handler (I will think about
> later), does anybody see a problem in this approach ?
>
> Cheers,
>
>
Re: [Trinidad] Strange subform behavior
Posted by Walter Mourão <wa...@gmail.com>.
The resetValues method is working fine with editable values, but I could not
figure out a way to make it work with tables...
Hints ?
Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br
On Sun, Sep 21, 2008 at 9:34 AM, Walter Mourão <wa...@gmail.com>wrote:
> Thanks Volker, but if I return an outcome != null the PPR does not work.
>
> The solution I found so far was the creation of a resetValues method which
> resets the values of the editable components:
>
> ...
> private void resetValues(UIComponent uic){
> if(uic instanceof UIXEditableValue){
> ((UIXEditableValue)uic).resetValue();
> }
> for(UIComponent component: uic.getChildren()){
> resetValues(component);
> }
> }
>
> /**
> * Method that is backed to a submit button of a form.
> */
> public String send()
> {
> final FacesContext facesContext=FacesContext.getCurrentInstance();
> UIViewRoot viewRoot=facesContext.getViewRoot();
> resetValues(viewRoot);
> ...
>
> It is (apparently) working fine, incuding when using PPR. In know it works
> only with Trinidad components and later I will take a look at the
> UIXEditableValue.reset method to extend the solution to all JSF
> components. Despite the fact the resetValues method must be executed in each
> action handler (I will think about later), does anybody see a problem in
> this approach ?
>
> Cheers,
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>
>
> On Sat, Sep 20, 2008 at 12:10 PM, Volker Weber <v....@inexso.de> wrote:
>
>> return a outcome != null in your action.
>>
>> This will create a new view, so there are no submitted values in the
>> components.
>>
>> Regards,
>> Volker
>>
>> 2008/9/19 Walter Mourão <wa...@gmail.com>:
>> > Hi Andrew,
>> > Is there a way to force all components (editable or not) to be
>> "refreshed"
>> > from the bean values ?
>> >
>> > Thanks in advance,
>> >
>> > Walter Mourão
>> > http://waltermourao.com.br
>> > http://arcadian.com.br
>> > http://oriens.com.br
>> >
>> >
>> >
>> > On Wed, Sep 10, 2008 at 4:04 PM, Andrew Robinson
>> > <an...@gmail.com> wrote:
>> >>
>> >> I wonder if a better idea is to address this from JSF or from the
>> >> Input behavior. This is not restricted to the subform. The problem is
>> >> that a component with a submitted value will not display a model value
>> >> if the model value changes.
>> >>
>> >> This could be addressed by something like:
>> >>
>> >> <tr:inputText value="#{bean.value}">
>> >> <trs:modelChangeBehavior />
>> >> </tr:inputText>
>> >>
>> >> The modelChangeBehavior would be a component that would clear the
>> >> submitted value & local value when the value of the
>> >> EditableValueHolder parent (requirement) changes between the end of
>> >> the APPLY_REQUEST_VALUES phase and the end of the INVOKE_APPLICATION
>> >> phase.
>> >>
>> >> Note that this can be done in JSF 1.2 without a custom component by
>> >> using the <f:phaseListener /> tag. This may be the best solution.
>> >>
>> >> How to implement:
>> >> 1) Add <f:phaseListener />
>> >> 2) Have that bound to a managed bean (request scope)
>> >> 3) Have that managed bean implement PhaseListener
>> >> 4) Use ANY_PHASE for the PhaseId
>> >> 5) on APPLY_REQUEST_VALUES get the component (use component binding is
>> >> the best solution I guess)
>> >> 6) get the value attribute & store it somewhere (in the bean probably
>> >> best)
>> >> 7) in INVOKE_APPLICATION, check the value and see if it changed. If
>> >> so, then clear the component
>> >>
>> >> -Andrew
>> >>
>> >>
>> >> On Wed, Sep 10, 2008 at 12:25 PM, Walter Mourão <
>> walter.mourao@gmail.com>
>> >> wrote:
>> >> > I will try the Andrew's workaround and/or try another way to
>> accomplish
>> >> > what
>> >> > I want.
>> >> >
>> >> > I will defend my point of view because:
>> >> > 1 - PPR already allows perfectly one to avoid refresh some of the
>> view,
>> >> > so
>> >> > it is possible to have control when it is not desired to refresh a
>> >> > subform;
>> >> > 2 - tr:outputText and tr:inputText should have a similar behavior
>> when
>> >> > showing the property value.
>> >> >
>> >> > Thank you very much, guys.
>> >> >
>> >> > Walter Mourão
>> >> > http://waltermourao.com.br
>> >> > http://arcadian.com.br
>> >> > http://oriens.com.br
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Sep 10, 2008 at 3:12 PM, Andrew Robinson
>> >> > <an...@gmail.com> wrote:
>> >> >>
>> >> >> IMO, the user is submitting the subform, not the entire page,
>> >> >> therefore only the subform values should be sent & everything else
>> >> >> lost right? Perhaps a toggle option would be desired. I can see the
>> >> >> value of both approaches.
>> >> >>
>> >> >> Using two different tr:forms would theoretically work, but that is
>> not
>> >> >> always easy to visually use. I would think that this would be
>> >> >> discussed before any thought of a fix could be made. It just seems
>> >> >> that there is no support for Walter's use case. I would think that
>> it
>> >> >> would be possible to come up with both use cases of (1) preserving
>> >> >> current input components values that the client entered and (2)
>> losing
>> >> >> the values to reflect changes to the model.
>> >> >>
>> >> >> Right now, JSF treats use case #2 very poorly and the standard
>> >> >> work-around is to clear the submitted value and local values from
>> >> >> EditableValueHolders when it is desired to reset their rendered
>> state
>> >> >> to their model values.
>> >> >>
>> >> >> Maybe the subform is not the best place to fix this, I am not sure.
>> >> >>
>> >> >> -Andrew
>> >> >>
>> >> >> On Wed, Sep 10, 2008 at 11:58 AM, Walter Mourão
>> >> >> <wa...@gmail.com>
>> >> >> wrote:
>> >> >> > Hi Volker,
>> >> >> >
>> >> >> > I think the question is not if it was submitted or not but if all
>> the
>> >> >> > visible references (inputText, outputText or everything else) of a
>> >> >> > property
>> >> >> > instance show its current value when the view is rendered.
>> >> >> >
>> >> >> > Regards,
>> >> >> >
>> >> >> > Walter Mourão
>> >> >> > http://waltermourao.com.br
>> >> >> > http://arcadian.com.br
>> >> >> > http://oriens.com.br
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <v....@inexso.de>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> why would you expect a not submited subform should loose changes
>> >> >> >> made
>> >> >> >> on the client (the submitted value)?
>> >> >> >>
>> >> >> >> This is exact the behavior i would expect. And BTW how the tobago
>> >> >> >> subform
>> >> >> >> works.
>> >> >> >>
>> >> >> >>
>> >> >> >> Regards,
>> >> >> >> Volker
>> >> >> >>
>> >> >> >> 2008/9/10 Andrew Robinson <an...@gmail.com>:
>> >> >> >> > Okay, I know the problem:
>> >> >> >> >
>> >> >> >> > The Subform allows the decode phase of all the children,
>> >> >> >> > regardless
>> >> >> >> > of
>> >> >> >> > what was clicked on. If an event was queued inside of the
>> subform,
>> >> >> >> > but
>> >> >> >> > not during the apply phase, the form is considered "submitted".
>> >> >> >> > Only
>> >> >> >> > the submitted form will be validated & updated.
>> >> >> >> >
>> >> >> >> > Now, UIXInput (and UIInput) render the submitted value as the
>> >> >> >> > current
>> >> >> >> > value if it is set. Therefore:
>> >> >> >> >
>> >> >> >> > 1) subform 1 is submitted
>> >> >> >> > 2) subform 1 & 2 are decoded, storing the submitted value (""
>> for
>> >> >> >> > the
>> >> >> >> > inputText in the 2nd subform)
>> >> >> >> > 3) subform 1 is validated
>> >> >> >> > 4) subform 1 is updated
>> >> >> >> > 5) render subform 1, inputText renders the "value" attribute
>> >> >> >> > 6) render subform 2, inputText renders the "submittedValue"
>> >> >> >> > attribute
>> >> >> >> > (blank string - "")
>> >> >> >> >
>> >> >> >> > So to me this looks like a design flaw of the subform
>> component.
>> >> >> >> > IMO,
>> >> >> >> > I would file a bug. Fixing it based on looking at the current
>> >> >> >> > design
>> >> >> >> > could be a pain in the rear. I wonder how the Tomahawk subform
>> >> >> >> > handles
>> >> >> >> > the same situation?
>> >> >> >> >
>> >> >> >> > As a workaround, you would have to find all components under
>> >> >> >> > non-submitted subforms that implement EditableValueHolder and
>> set
>> >> >> >> > their submitted value to null.
>> >> >> >> >
>> >> >> >> > -Andrew
>> >> >> >> >
>> >> >> >> > On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão
>> >> >> >> > <wa...@gmail.com>
>> >> >> >> > wrote:
>> >> >> >> >> Actually it looks like the issue isn't related with PPR. I
>> just
>> >> >> >> >> tested
>> >> >> >> >> without PPR (see code below) and had the same result:
>> >> >> >> >>
>> >> >> >> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> >> >> >> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
>> version="2.0"
>> >> >> >> >> xmlns:f="http://java.sun.com/jsf/core"
>> >> >> >> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >> >> >> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> >> >> >> >> <f:view>
>> >> >> >> >> <tr:document title="Apache Trinidad Blank Demo">
>> >> >> >> >> <tr:form>
>> >> >> >> >> <tr:subform id="sub1">
>> >> >> >> >> <tr:panelPage>
>> >> >> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> >> >> <tr:inputText label="Your name" id="input1"
>> >> >> >> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >> >> <tr:commandButton id="button1" text="press me"
>> >> >> >> >> action="#{helloWorldBacking.send}"/>
>> >> >> >> >> </tr:panelPage>
>> >> >> >> >> </tr:subform>
>> >> >> >> >> <tr:subform id="sub2">
>> >> >> >> >> <tr:panelPage>
>> >> >> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> >> >> <tr:inputText label="Your name" id="input1"
>> >> >> >> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >> >> <tr:commandButton id="button1" text="press me"
>> >> >> >> >> action="#{helloWorldBacking.send}"/>
>> >> >> >> >> </tr:panelPage>
>> >> >> >> >> </tr:subform>
>> >> >> >> >> </tr:form>
>> >> >> >> >> </tr:document>
>> >> >> >> >> </f:view>
>> >> >> >> >> </jsp:root>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Walter Mourão
>> >> >> >> >> http://waltermourao.com.br
>> >> >> >> >> http://arcadian.com.br
>> >> >> >> >> http://oriens.com.br
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
>> >> >> >> >> <an...@gmail.com> wrote:
>> >> >> >> >>>
>> >> >> >> >>> Looks like you need to add partialTriggers to the components
>> you
>> >> >> >> >>> want
>> >> >> >> >>> to update / refresh
>> >> >> >> >>>
>> >> >> >> >>> -A
>> >> >> >> >>>
>> >> >> >> >>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão
>> >> >> >> >>> <wa...@gmail.com>
>> >> >> >> >>> wrote:
>> >> >> >> >>> > Sorry the bump, but I'm in a dead end... Does anybody know
>> a
>> >> >> >> >>> > workaround
>> >> >> >> >>> > ?
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> > Walter Mourão
>> >> >> >> >>> > http://waltermourao.com.br
>> >> >> >> >>> > http://arcadian.com.br
>> >> >> >> >>> > http://oriens.com.br
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão
>> >> >> >> >>> > <wa...@gmail.com>
>> >> >> >> >>> > wrote:
>> >> >> >> >>> >>
>> >> >> >> >>> >> Hi folks,
>> >> >> >> >>> >> I'm dealing with a strange behavior when using subforms
>> and I
>> >> >> >> >>> >> reproduced
>> >> >> >> >>> >> it using the trinidad-blank example (from 1.0.9, but I
>> found
>> >> >> >> >>> >> the
>> >> >> >> >>> >> problem
>> >> >> >> >>> >> first with 1.0.5).
>> >> >> >> >>> >> When executing an action from subform 1, only the inputs
>> of
>> >> >> >> >>> >> the
>> >> >> >> >>> >> subform
>> >> >> >> >>> >> 1
>> >> >> >> >>> >> are refreshed and show the new value. Besides that, when I
>> >> >> >> >>> >> added
>> >> >> >> >>> >> a
>> >> >> >> >>> >> tr:outputText to the subform, pointing to the same backing
>> >> >> >> >>> >> bean
>> >> >> >> >>> >> property, it
>> >> >> >> >>> >> shows the new value, so the tr:inputText and tr:outputText
>> >> >> >> >>> >> (of
>> >> >> >> >>> >> the
>> >> >> >> >>> >> subform
>> >> >> >> >>> >> 2) shows differente values...
>> >> >> >> >>> >>
>> >> >> >> >>> >> To reproduce using the trinidad-blank example:
>> >> >> >> >>> >> 1 - change HelloWorldBacking.send to:
>> >> >> >> >>> >> public String send()
>> >> >> >> >>> >> {
>> >> >> >> >>> >> _name = _name.toUpperCase();
>> >> >> >> >>> >>
>> >> >> >> >>> >> return null;
>> >> >> >> >>> >> }
>> >> >> >> >>> >>
>> >> >> >> >>> >> 2 - add the file two_subforms.jspx with the content:
>> >> >> >> >>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes"
>> ?>
>> >> >> >> >>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
>> >> >> >> >>> >> version="2.0"
>> >> >> >> >>> >> xmlns:f="http://java.sun.com/jsf/core"
>> >> >> >> >>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >> >> >> >>> >> <jsp:directive.page
>> contentType="text/html;charset=utf-8"/>
>> >> >> >> >>> >> <f:view>
>> >> >> >> >>> >> <tr:document title="Apache Trinidad Blank Demo">
>> >> >> >> >>> >> <tr:form partialTriggers="sub1:button1
>> sub2:button1">
>> >> >> >> >>> >> <tr:subform id="sub1">
>> >> >> >> >>> >> <tr:panelPage>
>> >> >> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}"
>> />
>> >> >> >> >>> >> <tr:inputText label="Your name" id="input1"
>> >> >> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >> >>> >> <tr:commandButton id="button1" text="press me"
>> >> >> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >> >> >> >>> >> </tr:panelPage>
>> >> >> >> >>> >> </tr:subform>
>> >> >> >> >>> >> <tr:subform id="sub2">
>> >> >> >> >>> >> <tr:panelPage>
>> >> >> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}"
>> />
>> >> >> >> >>> >> <tr:inputText label="Your name" id="input1"
>> >> >> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >> >>> >> <tr:commandButton id="button1" text="press me"
>> >> >> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >> >> >> >>> >> </tr:panelPage>
>> >> >> >> >>> >> </tr:subform>
>> >> >> >> >>> >> </tr:form>
>> >> >> >> >>> >> </tr:document>
>> >> >> >> >>> >> </f:view>
>> >> >> >> >>> >> </jsp:root>
>> >> >> >> >>> >>
>> >> >> >> >>> >> 3 - start the application, go to /faces/two_subforms.jspx,
>> >> >> >> >>> >> add a
>> >> >> >> >>> >> text
>> >> >> >> >>> >> in
>> >> >> >> >>> >> one of the inputs and click "press me".
>> >> >> >> >>> >>
>> >> >> >> >>> >> This behavior happens with partialSubmit="false" too.
>> >> >> >> >>> >>
>> >> >> >> >>> >> Please confirm if it is a bug (and I file a jira issue)
>> and
>> >> >> >> >>> >> if
>> >> >> >> >>> >> it
>> >> >> >> >>> >> has
>> >> >> >> >>> >> an
>> >> >> >> >>> >> workaround.
>> >> >> >> >>> >>
>> >> >> >> >>> >> Thanks in advance,
>> >> >> >> >>> >>
>> >> >> >> >>> >>
>> >> >> >> >>> >> Walter Mourão
>> >> >> >> >>> >> http://waltermourao.com.br
>> >> >> >> >>> >> http://arcadian.com.br
>> >> >> >> >>> >> http://oriens.com.br
>> >> >> >> >>> >>
>> >> >> >> >>> >
>> >> >> >> >>> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> inexso - information exchange solutions GmbH
>> >> >> >> Bismarckstraße 13 | 26122 Oldenburg
>> >> >> >> Tel.: +49 441 4082 356 |
>> >> >> >> FAX: +49 441 4082 355 | www.inexso.de
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> >
>>
>>
>>
>> --
>> inexso - information exchange solutions GmbH
>> Bismarckstraße 13 | 26122 Oldenburg
>> Tel.: +49 441 4082 356 |
>> FAX: +49 441 4082 355 | www.inexso.de
>>
>
>
Re: [Trinidad] Strange subform behavior
Posted by Walter Mourão <wa...@gmail.com>.
Thanks Volker, but if I return an outcome != null the PPR does not work.
The solution I found so far was the creation of a resetValues method which
resets the values of the editable components:
...
private void resetValues(UIComponent uic){
if(uic instanceof UIXEditableValue){
((UIXEditableValue)uic).resetValue();
}
for(UIComponent component: uic.getChildren()){
resetValues(component);
}
}
/**
* Method that is backed to a submit button of a form.
*/
public String send()
{
final FacesContext facesContext=FacesContext.getCurrentInstance();
UIViewRoot viewRoot=facesContext.getViewRoot();
resetValues(viewRoot);
...
It is (apparently) working fine, incuding when using PPR. In know it works
only with Trinidad components and later I will take a look at the
UIXEditableValue.reset method to extend the solution to all JSF components.
Despite the fact the resetValues method must be executed in each action
handler (I will think about later), does anybody see a problem in this
approach ?
Cheers,
Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br
On Sat, Sep 20, 2008 at 12:10 PM, Volker Weber <v....@inexso.de> wrote:
> return a outcome != null in your action.
>
> This will create a new view, so there are no submitted values in the
> components.
>
> Regards,
> Volker
>
> 2008/9/19 Walter Mourão <wa...@gmail.com>:
> > Hi Andrew,
> > Is there a way to force all components (editable or not) to be
> "refreshed"
> > from the bean values ?
> >
> > Thanks in advance,
> >
> > Walter Mourão
> > http://waltermourao.com.br
> > http://arcadian.com.br
> > http://oriens.com.br
> >
> >
> >
> > On Wed, Sep 10, 2008 at 4:04 PM, Andrew Robinson
> > <an...@gmail.com> wrote:
> >>
> >> I wonder if a better idea is to address this from JSF or from the
> >> Input behavior. This is not restricted to the subform. The problem is
> >> that a component with a submitted value will not display a model value
> >> if the model value changes.
> >>
> >> This could be addressed by something like:
> >>
> >> <tr:inputText value="#{bean.value}">
> >> <trs:modelChangeBehavior />
> >> </tr:inputText>
> >>
> >> The modelChangeBehavior would be a component that would clear the
> >> submitted value & local value when the value of the
> >> EditableValueHolder parent (requirement) changes between the end of
> >> the APPLY_REQUEST_VALUES phase and the end of the INVOKE_APPLICATION
> >> phase.
> >>
> >> Note that this can be done in JSF 1.2 without a custom component by
> >> using the <f:phaseListener /> tag. This may be the best solution.
> >>
> >> How to implement:
> >> 1) Add <f:phaseListener />
> >> 2) Have that bound to a managed bean (request scope)
> >> 3) Have that managed bean implement PhaseListener
> >> 4) Use ANY_PHASE for the PhaseId
> >> 5) on APPLY_REQUEST_VALUES get the component (use component binding is
> >> the best solution I guess)
> >> 6) get the value attribute & store it somewhere (in the bean probably
> >> best)
> >> 7) in INVOKE_APPLICATION, check the value and see if it changed. If
> >> so, then clear the component
> >>
> >> -Andrew
> >>
> >>
> >> On Wed, Sep 10, 2008 at 12:25 PM, Walter Mourão <
> walter.mourao@gmail.com>
> >> wrote:
> >> > I will try the Andrew's workaround and/or try another way to
> accomplish
> >> > what
> >> > I want.
> >> >
> >> > I will defend my point of view because:
> >> > 1 - PPR already allows perfectly one to avoid refresh some of the
> view,
> >> > so
> >> > it is possible to have control when it is not desired to refresh a
> >> > subform;
> >> > 2 - tr:outputText and tr:inputText should have a similar behavior when
> >> > showing the property value.
> >> >
> >> > Thank you very much, guys.
> >> >
> >> > Walter Mourão
> >> > http://waltermourao.com.br
> >> > http://arcadian.com.br
> >> > http://oriens.com.br
> >> >
> >> >
> >> >
> >> > On Wed, Sep 10, 2008 at 3:12 PM, Andrew Robinson
> >> > <an...@gmail.com> wrote:
> >> >>
> >> >> IMO, the user is submitting the subform, not the entire page,
> >> >> therefore only the subform values should be sent & everything else
> >> >> lost right? Perhaps a toggle option would be desired. I can see the
> >> >> value of both approaches.
> >> >>
> >> >> Using two different tr:forms would theoretically work, but that is
> not
> >> >> always easy to visually use. I would think that this would be
> >> >> discussed before any thought of a fix could be made. It just seems
> >> >> that there is no support for Walter's use case. I would think that it
> >> >> would be possible to come up with both use cases of (1) preserving
> >> >> current input components values that the client entered and (2)
> losing
> >> >> the values to reflect changes to the model.
> >> >>
> >> >> Right now, JSF treats use case #2 very poorly and the standard
> >> >> work-around is to clear the submitted value and local values from
> >> >> EditableValueHolders when it is desired to reset their rendered state
> >> >> to their model values.
> >> >>
> >> >> Maybe the subform is not the best place to fix this, I am not sure.
> >> >>
> >> >> -Andrew
> >> >>
> >> >> On Wed, Sep 10, 2008 at 11:58 AM, Walter Mourão
> >> >> <wa...@gmail.com>
> >> >> wrote:
> >> >> > Hi Volker,
> >> >> >
> >> >> > I think the question is not if it was submitted or not but if all
> the
> >> >> > visible references (inputText, outputText or everything else) of a
> >> >> > property
> >> >> > instance show its current value when the view is rendered.
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Walter Mourão
> >> >> > http://waltermourao.com.br
> >> >> > http://arcadian.com.br
> >> >> > http://oriens.com.br
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <v....@inexso.de>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> why would you expect a not submited subform should loose changes
> >> >> >> made
> >> >> >> on the client (the submitted value)?
> >> >> >>
> >> >> >> This is exact the behavior i would expect. And BTW how the tobago
> >> >> >> subform
> >> >> >> works.
> >> >> >>
> >> >> >>
> >> >> >> Regards,
> >> >> >> Volker
> >> >> >>
> >> >> >> 2008/9/10 Andrew Robinson <an...@gmail.com>:
> >> >> >> > Okay, I know the problem:
> >> >> >> >
> >> >> >> > The Subform allows the decode phase of all the children,
> >> >> >> > regardless
> >> >> >> > of
> >> >> >> > what was clicked on. If an event was queued inside of the
> subform,
> >> >> >> > but
> >> >> >> > not during the apply phase, the form is considered "submitted".
> >> >> >> > Only
> >> >> >> > the submitted form will be validated & updated.
> >> >> >> >
> >> >> >> > Now, UIXInput (and UIInput) render the submitted value as the
> >> >> >> > current
> >> >> >> > value if it is set. Therefore:
> >> >> >> >
> >> >> >> > 1) subform 1 is submitted
> >> >> >> > 2) subform 1 & 2 are decoded, storing the submitted value (""
> for
> >> >> >> > the
> >> >> >> > inputText in the 2nd subform)
> >> >> >> > 3) subform 1 is validated
> >> >> >> > 4) subform 1 is updated
> >> >> >> > 5) render subform 1, inputText renders the "value" attribute
> >> >> >> > 6) render subform 2, inputText renders the "submittedValue"
> >> >> >> > attribute
> >> >> >> > (blank string - "")
> >> >> >> >
> >> >> >> > So to me this looks like a design flaw of the subform component.
> >> >> >> > IMO,
> >> >> >> > I would file a bug. Fixing it based on looking at the current
> >> >> >> > design
> >> >> >> > could be a pain in the rear. I wonder how the Tomahawk subform
> >> >> >> > handles
> >> >> >> > the same situation?
> >> >> >> >
> >> >> >> > As a workaround, you would have to find all components under
> >> >> >> > non-submitted subforms that implement EditableValueHolder and
> set
> >> >> >> > their submitted value to null.
> >> >> >> >
> >> >> >> > -Andrew
> >> >> >> >
> >> >> >> > On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão
> >> >> >> > <wa...@gmail.com>
> >> >> >> > wrote:
> >> >> >> >> Actually it looks like the issue isn't related with PPR. I just
> >> >> >> >> tested
> >> >> >> >> without PPR (see code below) and had the same result:
> >> >> >> >>
> >> >> >> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
> >> >> >> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
> version="2.0"
> >> >> >> >> xmlns:f="http://java.sun.com/jsf/core"
> >> >> >> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
> >> >> >> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
> >> >> >> >> <f:view>
> >> >> >> >> <tr:document title="Apache Trinidad Blank Demo">
> >> >> >> >> <tr:form>
> >> >> >> >> <tr:subform id="sub1">
> >> >> >> >> <tr:panelPage>
> >> >> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> >> >> >> <tr:inputText label="Your name" id="input1"
> >> >> >> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >> >> >> <tr:commandButton id="button1" text="press me"
> >> >> >> >> action="#{helloWorldBacking.send}"/>
> >> >> >> >> </tr:panelPage>
> >> >> >> >> </tr:subform>
> >> >> >> >> <tr:subform id="sub2">
> >> >> >> >> <tr:panelPage>
> >> >> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> >> >> >> <tr:inputText label="Your name" id="input1"
> >> >> >> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >> >> >> <tr:commandButton id="button1" text="press me"
> >> >> >> >> action="#{helloWorldBacking.send}"/>
> >> >> >> >> </tr:panelPage>
> >> >> >> >> </tr:subform>
> >> >> >> >> </tr:form>
> >> >> >> >> </tr:document>
> >> >> >> >> </f:view>
> >> >> >> >> </jsp:root>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Walter Mourão
> >> >> >> >> http://waltermourao.com.br
> >> >> >> >> http://arcadian.com.br
> >> >> >> >> http://oriens.com.br
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
> >> >> >> >> <an...@gmail.com> wrote:
> >> >> >> >>>
> >> >> >> >>> Looks like you need to add partialTriggers to the components
> you
> >> >> >> >>> want
> >> >> >> >>> to update / refresh
> >> >> >> >>>
> >> >> >> >>> -A
> >> >> >> >>>
> >> >> >> >>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão
> >> >> >> >>> <wa...@gmail.com>
> >> >> >> >>> wrote:
> >> >> >> >>> > Sorry the bump, but I'm in a dead end... Does anybody know a
> >> >> >> >>> > workaround
> >> >> >> >>> > ?
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> > Walter Mourão
> >> >> >> >>> > http://waltermourao.com.br
> >> >> >> >>> > http://arcadian.com.br
> >> >> >> >>> > http://oriens.com.br
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão
> >> >> >> >>> > <wa...@gmail.com>
> >> >> >> >>> > wrote:
> >> >> >> >>> >>
> >> >> >> >>> >> Hi folks,
> >> >> >> >>> >> I'm dealing with a strange behavior when using subforms and
> I
> >> >> >> >>> >> reproduced
> >> >> >> >>> >> it using the trinidad-blank example (from 1.0.9, but I
> found
> >> >> >> >>> >> the
> >> >> >> >>> >> problem
> >> >> >> >>> >> first with 1.0.5).
> >> >> >> >>> >> When executing an action from subform 1, only the inputs of
> >> >> >> >>> >> the
> >> >> >> >>> >> subform
> >> >> >> >>> >> 1
> >> >> >> >>> >> are refreshed and show the new value. Besides that, when I
> >> >> >> >>> >> added
> >> >> >> >>> >> a
> >> >> >> >>> >> tr:outputText to the subform, pointing to the same backing
> >> >> >> >>> >> bean
> >> >> >> >>> >> property, it
> >> >> >> >>> >> shows the new value, so the tr:inputText and tr:outputText
> >> >> >> >>> >> (of
> >> >> >> >>> >> the
> >> >> >> >>> >> subform
> >> >> >> >>> >> 2) shows differente values...
> >> >> >> >>> >>
> >> >> >> >>> >> To reproduce using the trinidad-blank example:
> >> >> >> >>> >> 1 - change HelloWorldBacking.send to:
> >> >> >> >>> >> public String send()
> >> >> >> >>> >> {
> >> >> >> >>> >> _name = _name.toUpperCase();
> >> >> >> >>> >>
> >> >> >> >>> >> return null;
> >> >> >> >>> >> }
> >> >> >> >>> >>
> >> >> >> >>> >> 2 - add the file two_subforms.jspx with the content:
> >> >> >> >>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes"
> ?>
> >> >> >> >>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
> >> >> >> >>> >> version="2.0"
> >> >> >> >>> >> xmlns:f="http://java.sun.com/jsf/core"
> >> >> >> >>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
> >> >> >> >>> >> <jsp:directive.page
> contentType="text/html;charset=utf-8"/>
> >> >> >> >>> >> <f:view>
> >> >> >> >>> >> <tr:document title="Apache Trinidad Blank Demo">
> >> >> >> >>> >> <tr:form partialTriggers="sub1:button1
> sub2:button1">
> >> >> >> >>> >> <tr:subform id="sub1">
> >> >> >> >>> >> <tr:panelPage>
> >> >> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}"
> />
> >> >> >> >>> >> <tr:inputText label="Your name" id="input1"
> >> >> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >> >> >>> >> <tr:commandButton id="button1" text="press me"
> >> >> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> >> >> >> >>> >> </tr:panelPage>
> >> >> >> >>> >> </tr:subform>
> >> >> >> >>> >> <tr:subform id="sub2">
> >> >> >> >>> >> <tr:panelPage>
> >> >> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}"
> />
> >> >> >> >>> >> <tr:inputText label="Your name" id="input1"
> >> >> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >> >> >>> >> <tr:commandButton id="button1" text="press me"
> >> >> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> >> >> >> >>> >> </tr:panelPage>
> >> >> >> >>> >> </tr:subform>
> >> >> >> >>> >> </tr:form>
> >> >> >> >>> >> </tr:document>
> >> >> >> >>> >> </f:view>
> >> >> >> >>> >> </jsp:root>
> >> >> >> >>> >>
> >> >> >> >>> >> 3 - start the application, go to /faces/two_subforms.jspx,
> >> >> >> >>> >> add a
> >> >> >> >>> >> text
> >> >> >> >>> >> in
> >> >> >> >>> >> one of the inputs and click "press me".
> >> >> >> >>> >>
> >> >> >> >>> >> This behavior happens with partialSubmit="false" too.
> >> >> >> >>> >>
> >> >> >> >>> >> Please confirm if it is a bug (and I file a jira issue) and
> >> >> >> >>> >> if
> >> >> >> >>> >> it
> >> >> >> >>> >> has
> >> >> >> >>> >> an
> >> >> >> >>> >> workaround.
> >> >> >> >>> >>
> >> >> >> >>> >> Thanks in advance,
> >> >> >> >>> >>
> >> >> >> >>> >>
> >> >> >> >>> >> Walter Mourão
> >> >> >> >>> >> http://waltermourao.com.br
> >> >> >> >>> >> http://arcadian.com.br
> >> >> >> >>> >> http://oriens.com.br
> >> >> >> >>> >>
> >> >> >> >>> >
> >> >> >> >>> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> inexso - information exchange solutions GmbH
> >> >> >> Bismarckstraße 13 | 26122 Oldenburg
> >> >> >> Tel.: +49 441 4082 356 |
> >> >> >> FAX: +49 441 4082 355 | www.inexso.de
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>
>
>
> --
> inexso - information exchange solutions GmbH
> Bismarckstraße 13 | 26122 Oldenburg
> Tel.: +49 441 4082 356 |
> FAX: +49 441 4082 355 | www.inexso.de
>
Re: [Trinidad] Strange subform behavior
Posted by Volker Weber <v....@inexso.de>.
return a outcome != null in your action.
This will create a new view, so there are no submitted values in the components.
Regards,
Volker
2008/9/19 Walter Mourão <wa...@gmail.com>:
> Hi Andrew,
> Is there a way to force all components (editable or not) to be "refreshed"
> from the bean values ?
>
> Thanks in advance,
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>
>
> On Wed, Sep 10, 2008 at 4:04 PM, Andrew Robinson
> <an...@gmail.com> wrote:
>>
>> I wonder if a better idea is to address this from JSF or from the
>> Input behavior. This is not restricted to the subform. The problem is
>> that a component with a submitted value will not display a model value
>> if the model value changes.
>>
>> This could be addressed by something like:
>>
>> <tr:inputText value="#{bean.value}">
>> <trs:modelChangeBehavior />
>> </tr:inputText>
>>
>> The modelChangeBehavior would be a component that would clear the
>> submitted value & local value when the value of the
>> EditableValueHolder parent (requirement) changes between the end of
>> the APPLY_REQUEST_VALUES phase and the end of the INVOKE_APPLICATION
>> phase.
>>
>> Note that this can be done in JSF 1.2 without a custom component by
>> using the <f:phaseListener /> tag. This may be the best solution.
>>
>> How to implement:
>> 1) Add <f:phaseListener />
>> 2) Have that bound to a managed bean (request scope)
>> 3) Have that managed bean implement PhaseListener
>> 4) Use ANY_PHASE for the PhaseId
>> 5) on APPLY_REQUEST_VALUES get the component (use component binding is
>> the best solution I guess)
>> 6) get the value attribute & store it somewhere (in the bean probably
>> best)
>> 7) in INVOKE_APPLICATION, check the value and see if it changed. If
>> so, then clear the component
>>
>> -Andrew
>>
>>
>> On Wed, Sep 10, 2008 at 12:25 PM, Walter Mourão <wa...@gmail.com>
>> wrote:
>> > I will try the Andrew's workaround and/or try another way to accomplish
>> > what
>> > I want.
>> >
>> > I will defend my point of view because:
>> > 1 - PPR already allows perfectly one to avoid refresh some of the view,
>> > so
>> > it is possible to have control when it is not desired to refresh a
>> > subform;
>> > 2 - tr:outputText and tr:inputText should have a similar behavior when
>> > showing the property value.
>> >
>> > Thank you very much, guys.
>> >
>> > Walter Mourão
>> > http://waltermourao.com.br
>> > http://arcadian.com.br
>> > http://oriens.com.br
>> >
>> >
>> >
>> > On Wed, Sep 10, 2008 at 3:12 PM, Andrew Robinson
>> > <an...@gmail.com> wrote:
>> >>
>> >> IMO, the user is submitting the subform, not the entire page,
>> >> therefore only the subform values should be sent & everything else
>> >> lost right? Perhaps a toggle option would be desired. I can see the
>> >> value of both approaches.
>> >>
>> >> Using two different tr:forms would theoretically work, but that is not
>> >> always easy to visually use. I would think that this would be
>> >> discussed before any thought of a fix could be made. It just seems
>> >> that there is no support for Walter's use case. I would think that it
>> >> would be possible to come up with both use cases of (1) preserving
>> >> current input components values that the client entered and (2) losing
>> >> the values to reflect changes to the model.
>> >>
>> >> Right now, JSF treats use case #2 very poorly and the standard
>> >> work-around is to clear the submitted value and local values from
>> >> EditableValueHolders when it is desired to reset their rendered state
>> >> to their model values.
>> >>
>> >> Maybe the subform is not the best place to fix this, I am not sure.
>> >>
>> >> -Andrew
>> >>
>> >> On Wed, Sep 10, 2008 at 11:58 AM, Walter Mourão
>> >> <wa...@gmail.com>
>> >> wrote:
>> >> > Hi Volker,
>> >> >
>> >> > I think the question is not if it was submitted or not but if all the
>> >> > visible references (inputText, outputText or everything else) of a
>> >> > property
>> >> > instance show its current value when the view is rendered.
>> >> >
>> >> > Regards,
>> >> >
>> >> > Walter Mourão
>> >> > http://waltermourao.com.br
>> >> > http://arcadian.com.br
>> >> > http://oriens.com.br
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <v....@inexso.de>
>> >> > wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> why would you expect a not submited subform should loose changes
>> >> >> made
>> >> >> on the client (the submitted value)?
>> >> >>
>> >> >> This is exact the behavior i would expect. And BTW how the tobago
>> >> >> subform
>> >> >> works.
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >> Volker
>> >> >>
>> >> >> 2008/9/10 Andrew Robinson <an...@gmail.com>:
>> >> >> > Okay, I know the problem:
>> >> >> >
>> >> >> > The Subform allows the decode phase of all the children,
>> >> >> > regardless
>> >> >> > of
>> >> >> > what was clicked on. If an event was queued inside of the subform,
>> >> >> > but
>> >> >> > not during the apply phase, the form is considered "submitted".
>> >> >> > Only
>> >> >> > the submitted form will be validated & updated.
>> >> >> >
>> >> >> > Now, UIXInput (and UIInput) render the submitted value as the
>> >> >> > current
>> >> >> > value if it is set. Therefore:
>> >> >> >
>> >> >> > 1) subform 1 is submitted
>> >> >> > 2) subform 1 & 2 are decoded, storing the submitted value ("" for
>> >> >> > the
>> >> >> > inputText in the 2nd subform)
>> >> >> > 3) subform 1 is validated
>> >> >> > 4) subform 1 is updated
>> >> >> > 5) render subform 1, inputText renders the "value" attribute
>> >> >> > 6) render subform 2, inputText renders the "submittedValue"
>> >> >> > attribute
>> >> >> > (blank string - "")
>> >> >> >
>> >> >> > So to me this looks like a design flaw of the subform component.
>> >> >> > IMO,
>> >> >> > I would file a bug. Fixing it based on looking at the current
>> >> >> > design
>> >> >> > could be a pain in the rear. I wonder how the Tomahawk subform
>> >> >> > handles
>> >> >> > the same situation?
>> >> >> >
>> >> >> > As a workaround, you would have to find all components under
>> >> >> > non-submitted subforms that implement EditableValueHolder and set
>> >> >> > their submitted value to null.
>> >> >> >
>> >> >> > -Andrew
>> >> >> >
>> >> >> > On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão
>> >> >> > <wa...@gmail.com>
>> >> >> > wrote:
>> >> >> >> Actually it looks like the issue isn't related with PPR. I just
>> >> >> >> tested
>> >> >> >> without PPR (see code below) and had the same result:
>> >> >> >>
>> >> >> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> >> >> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>> >> >> >> xmlns:f="http://java.sun.com/jsf/core"
>> >> >> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >> >> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> >> >> >> <f:view>
>> >> >> >> <tr:document title="Apache Trinidad Blank Demo">
>> >> >> >> <tr:form>
>> >> >> >> <tr:subform id="sub1">
>> >> >> >> <tr:panelPage>
>> >> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> >> <tr:inputText label="Your name" id="input1"
>> >> >> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >> <tr:commandButton id="button1" text="press me"
>> >> >> >> action="#{helloWorldBacking.send}"/>
>> >> >> >> </tr:panelPage>
>> >> >> >> </tr:subform>
>> >> >> >> <tr:subform id="sub2">
>> >> >> >> <tr:panelPage>
>> >> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> >> <tr:inputText label="Your name" id="input1"
>> >> >> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >> <tr:commandButton id="button1" text="press me"
>> >> >> >> action="#{helloWorldBacking.send}"/>
>> >> >> >> </tr:panelPage>
>> >> >> >> </tr:subform>
>> >> >> >> </tr:form>
>> >> >> >> </tr:document>
>> >> >> >> </f:view>
>> >> >> >> </jsp:root>
>> >> >> >>
>> >> >> >>
>> >> >> >> Walter Mourão
>> >> >> >> http://waltermourao.com.br
>> >> >> >> http://arcadian.com.br
>> >> >> >> http://oriens.com.br
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
>> >> >> >> <an...@gmail.com> wrote:
>> >> >> >>>
>> >> >> >>> Looks like you need to add partialTriggers to the components you
>> >> >> >>> want
>> >> >> >>> to update / refresh
>> >> >> >>>
>> >> >> >>> -A
>> >> >> >>>
>> >> >> >>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão
>> >> >> >>> <wa...@gmail.com>
>> >> >> >>> wrote:
>> >> >> >>> > Sorry the bump, but I'm in a dead end... Does anybody know a
>> >> >> >>> > workaround
>> >> >> >>> > ?
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > Walter Mourão
>> >> >> >>> > http://waltermourao.com.br
>> >> >> >>> > http://arcadian.com.br
>> >> >> >>> > http://oriens.com.br
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão
>> >> >> >>> > <wa...@gmail.com>
>> >> >> >>> > wrote:
>> >> >> >>> >>
>> >> >> >>> >> Hi folks,
>> >> >> >>> >> I'm dealing with a strange behavior when using subforms and I
>> >> >> >>> >> reproduced
>> >> >> >>> >> it using the trinidad-blank example (from 1.0.9, but I found
>> >> >> >>> >> the
>> >> >> >>> >> problem
>> >> >> >>> >> first with 1.0.5).
>> >> >> >>> >> When executing an action from subform 1, only the inputs of
>> >> >> >>> >> the
>> >> >> >>> >> subform
>> >> >> >>> >> 1
>> >> >> >>> >> are refreshed and show the new value. Besides that, when I
>> >> >> >>> >> added
>> >> >> >>> >> a
>> >> >> >>> >> tr:outputText to the subform, pointing to the same backing
>> >> >> >>> >> bean
>> >> >> >>> >> property, it
>> >> >> >>> >> shows the new value, so the tr:inputText and tr:outputText
>> >> >> >>> >> (of
>> >> >> >>> >> the
>> >> >> >>> >> subform
>> >> >> >>> >> 2) shows differente values...
>> >> >> >>> >>
>> >> >> >>> >> To reproduce using the trinidad-blank example:
>> >> >> >>> >> 1 - change HelloWorldBacking.send to:
>> >> >> >>> >> public String send()
>> >> >> >>> >> {
>> >> >> >>> >> _name = _name.toUpperCase();
>> >> >> >>> >>
>> >> >> >>> >> return null;
>> >> >> >>> >> }
>> >> >> >>> >>
>> >> >> >>> >> 2 - add the file two_subforms.jspx with the content:
>> >> >> >>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> >> >> >>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
>> >> >> >>> >> version="2.0"
>> >> >> >>> >> xmlns:f="http://java.sun.com/jsf/core"
>> >> >> >>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >> >> >>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> >> >> >>> >> <f:view>
>> >> >> >>> >> <tr:document title="Apache Trinidad Blank Demo">
>> >> >> >>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
>> >> >> >>> >> <tr:subform id="sub1">
>> >> >> >>> >> <tr:panelPage>
>> >> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> >>> >> <tr:inputText label="Your name" id="input1"
>> >> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >>> >> <tr:commandButton id="button1" text="press me"
>> >> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >> >> >>> >> </tr:panelPage>
>> >> >> >>> >> </tr:subform>
>> >> >> >>> >> <tr:subform id="sub2">
>> >> >> >>> >> <tr:panelPage>
>> >> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> >>> >> <tr:inputText label="Your name" id="input1"
>> >> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >>> >> <tr:commandButton id="button1" text="press me"
>> >> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >> >> >>> >> </tr:panelPage>
>> >> >> >>> >> </tr:subform>
>> >> >> >>> >> </tr:form>
>> >> >> >>> >> </tr:document>
>> >> >> >>> >> </f:view>
>> >> >> >>> >> </jsp:root>
>> >> >> >>> >>
>> >> >> >>> >> 3 - start the application, go to /faces/two_subforms.jspx,
>> >> >> >>> >> add a
>> >> >> >>> >> text
>> >> >> >>> >> in
>> >> >> >>> >> one of the inputs and click "press me".
>> >> >> >>> >>
>> >> >> >>> >> This behavior happens with partialSubmit="false" too.
>> >> >> >>> >>
>> >> >> >>> >> Please confirm if it is a bug (and I file a jira issue) and
>> >> >> >>> >> if
>> >> >> >>> >> it
>> >> >> >>> >> has
>> >> >> >>> >> an
>> >> >> >>> >> workaround.
>> >> >> >>> >>
>> >> >> >>> >> Thanks in advance,
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >> Walter Mourão
>> >> >> >>> >> http://waltermourao.com.br
>> >> >> >>> >> http://arcadian.com.br
>> >> >> >>> >> http://oriens.com.br
>> >> >> >>> >>
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> inexso - information exchange solutions GmbH
>> >> >> Bismarckstraße 13 | 26122 Oldenburg
>> >> >> Tel.: +49 441 4082 356 |
>> >> >> FAX: +49 441 4082 355 | www.inexso.de
>> >> >
>> >> >
>> >
>> >
>
>
--
inexso - information exchange solutions GmbH
Bismarckstraße 13 | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX: +49 441 4082 355 | www.inexso.de
Re: [Trinidad] Strange subform behavior
Posted by Walter Mourão <wa...@gmail.com>.
Thank you Marco, Andrew, Simon, Bernd, Volker & etc.
Sorry the long thread. I think I found my ways around the question. I will
rebuild the test project from scratch and try again.
Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br
On Wed, Oct 1, 2008 at 8:33 AM, Marco Grimm <Ma...@googlemail.com>wrote:
>
> I do not know, what you mean by "components". We set the UIXSubForm, we do
> not want the children to have submitted values, to transient.
>
>
> Walter Mourão-2 wrote:
> >
> > Yes, maybe the wrong way... during the action I set all the components to
> > transient...
> >
> > How do you use it ?
> >
> > Walter Mourão
> > http://waltermourao.com.br
> > http://arcadian.com.br
> > http://oriens.com.br
> >
> >
> >
> > On Wed, Oct 1, 2008 at 4:25 AM, Marco Grimm
> > <Ma...@googlemail.com>wrote:
> >
> >>
> >> Did you try the solution Andrew suggested to set the subform transient?
> >> We
> >> do
> >> use this approach already for some time and for us it works.
> >>
> >>
> >
>
> --
> View this message in context:
> http://www.nabble.com/-Trinidad--Strange-subform-behavior-tp19357062p19758582.html
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>
Re: [Trinidad] Strange subform behavior
Posted by Marco Grimm <Ma...@googlemail.com>.
I do not know, what you mean by "components". We set the UIXSubForm, we do
not want the children to have submitted values, to transient.
Walter Mourão-2 wrote:
>
> Yes, maybe the wrong way... during the action I set all the components to
> transient...
>
> How do you use it ?
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>
>
> On Wed, Oct 1, 2008 at 4:25 AM, Marco Grimm
> <Ma...@googlemail.com>wrote:
>
>>
>> Did you try the solution Andrew suggested to set the subform transient?
>> We
>> do
>> use this approach already for some time and for us it works.
>>
>>
>
--
View this message in context: http://www.nabble.com/-Trinidad--Strange-subform-behavior-tp19357062p19758582.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Strange subform behavior
Posted by Walter Mourão <wa...@gmail.com>.
Yes, maybe the wrong way... during the action I set all the components to
transient...
How do you use it ?
Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br
On Wed, Oct 1, 2008 at 4:25 AM, Marco Grimm <Ma...@googlemail.com>wrote:
>
> Did you try the solution Andrew suggested to set the subform transient? We
> do
> use this approach already for some time and for us it works.
>
>
> Andrew Robinson-5 wrote:
> >
> > Flag them as transient :)
> >
> > Other than that, not out of the box
> >
> > On Fri, Sep 19, 2008 at 2:12 PM, Walter Mourão <wa...@gmail.com>
> > wrote:
> >> Hi Andrew,
> >> Is there a way to force all components (editable or not) to be
> >> "refreshed"
> >> from the bean values ?
> >>
> >> Thanks in advance,
> >>
> >> Walter Mourão
> >> http://waltermourao.com.br
> >> http://arcadian.com.br
> >> http://oriens.com.br
> >
> --
> View this message in context:
> http://www.nabble.com/-Trinidad--Strange-subform-behavior-tp19357062p19755726.html
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>
Re: [Trinidad] Strange subform behavior
Posted by Marco Grimm <Ma...@googlemail.com>.
Did you try the solution Andrew suggested to set the subform transient? We do
use this approach already for some time and for us it works.
Andrew Robinson-5 wrote:
>
> Flag them as transient :)
>
> Other than that, not out of the box
>
> On Fri, Sep 19, 2008 at 2:12 PM, Walter Mourão <wa...@gmail.com>
> wrote:
>> Hi Andrew,
>> Is there a way to force all components (editable or not) to be
>> "refreshed"
>> from the bean values ?
>>
>> Thanks in advance,
>>
>> Walter Mourão
>> http://waltermourao.com.br
>> http://arcadian.com.br
>> http://oriens.com.br
>
--
View this message in context: http://www.nabble.com/-Trinidad--Strange-subform-behavior-tp19357062p19755726.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: [Trinidad] Strange subform behavior
Posted by Andrew Robinson <an...@gmail.com>.
Flag them as transient :)
Other than that, not out of the box
On Fri, Sep 19, 2008 at 2:12 PM, Walter Mourão <wa...@gmail.com> wrote:
> Hi Andrew,
> Is there a way to force all components (editable or not) to be "refreshed"
> from the bean values ?
>
> Thanks in advance,
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>
>
> On Wed, Sep 10, 2008 at 4:04 PM, Andrew Robinson
> <an...@gmail.com> wrote:
>>
>> I wonder if a better idea is to address this from JSF or from the
>> Input behavior. This is not restricted to the subform. The problem is
>> that a component with a submitted value will not display a model value
>> if the model value changes.
>>
>> This could be addressed by something like:
>>
>> <tr:inputText value="#{bean.value}">
>> <trs:modelChangeBehavior />
>> </tr:inputText>
>>
>> The modelChangeBehavior would be a component that would clear the
>> submitted value & local value when the value of the
>> EditableValueHolder parent (requirement) changes between the end of
>> the APPLY_REQUEST_VALUES phase and the end of the INVOKE_APPLICATION
>> phase.
>>
>> Note that this can be done in JSF 1.2 without a custom component by
>> using the <f:phaseListener /> tag. This may be the best solution.
>>
>> How to implement:
>> 1) Add <f:phaseListener />
>> 2) Have that bound to a managed bean (request scope)
>> 3) Have that managed bean implement PhaseListener
>> 4) Use ANY_PHASE for the PhaseId
>> 5) on APPLY_REQUEST_VALUES get the component (use component binding is
>> the best solution I guess)
>> 6) get the value attribute & store it somewhere (in the bean probably
>> best)
>> 7) in INVOKE_APPLICATION, check the value and see if it changed. If
>> so, then clear the component
>>
>> -Andrew
>>
>>
>> On Wed, Sep 10, 2008 at 12:25 PM, Walter Mourão <wa...@gmail.com>
>> wrote:
>> > I will try the Andrew's workaround and/or try another way to accomplish
>> > what
>> > I want.
>> >
>> > I will defend my point of view because:
>> > 1 - PPR already allows perfectly one to avoid refresh some of the view,
>> > so
>> > it is possible to have control when it is not desired to refresh a
>> > subform;
>> > 2 - tr:outputText and tr:inputText should have a similar behavior when
>> > showing the property value.
>> >
>> > Thank you very much, guys.
>> >
>> > Walter Mourão
>> > http://waltermourao.com.br
>> > http://arcadian.com.br
>> > http://oriens.com.br
>> >
>> >
>> >
>> > On Wed, Sep 10, 2008 at 3:12 PM, Andrew Robinson
>> > <an...@gmail.com> wrote:
>> >>
>> >> IMO, the user is submitting the subform, not the entire page,
>> >> therefore only the subform values should be sent & everything else
>> >> lost right? Perhaps a toggle option would be desired. I can see the
>> >> value of both approaches.
>> >>
>> >> Using two different tr:forms would theoretically work, but that is not
>> >> always easy to visually use. I would think that this would be
>> >> discussed before any thought of a fix could be made. It just seems
>> >> that there is no support for Walter's use case. I would think that it
>> >> would be possible to come up with both use cases of (1) preserving
>> >> current input components values that the client entered and (2) losing
>> >> the values to reflect changes to the model.
>> >>
>> >> Right now, JSF treats use case #2 very poorly and the standard
>> >> work-around is to clear the submitted value and local values from
>> >> EditableValueHolders when it is desired to reset their rendered state
>> >> to their model values.
>> >>
>> >> Maybe the subform is not the best place to fix this, I am not sure.
>> >>
>> >> -Andrew
>> >>
>> >> On Wed, Sep 10, 2008 at 11:58 AM, Walter Mourão
>> >> <wa...@gmail.com>
>> >> wrote:
>> >> > Hi Volker,
>> >> >
>> >> > I think the question is not if it was submitted or not but if all the
>> >> > visible references (inputText, outputText or everything else) of a
>> >> > property
>> >> > instance show its current value when the view is rendered.
>> >> >
>> >> > Regards,
>> >> >
>> >> > Walter Mourão
>> >> > http://waltermourao.com.br
>> >> > http://arcadian.com.br
>> >> > http://oriens.com.br
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <v....@inexso.de>
>> >> > wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> why would you expect a not submited subform should loose changes
>> >> >> made
>> >> >> on the client (the submitted value)?
>> >> >>
>> >> >> This is exact the behavior i would expect. And BTW how the tobago
>> >> >> subform
>> >> >> works.
>> >> >>
>> >> >>
>> >> >> Regards,
>> >> >> Volker
>> >> >>
>> >> >> 2008/9/10 Andrew Robinson <an...@gmail.com>:
>> >> >> > Okay, I know the problem:
>> >> >> >
>> >> >> > The Subform allows the decode phase of all the children,
>> >> >> > regardless
>> >> >> > of
>> >> >> > what was clicked on. If an event was queued inside of the subform,
>> >> >> > but
>> >> >> > not during the apply phase, the form is considered "submitted".
>> >> >> > Only
>> >> >> > the submitted form will be validated & updated.
>> >> >> >
>> >> >> > Now, UIXInput (and UIInput) render the submitted value as the
>> >> >> > current
>> >> >> > value if it is set. Therefore:
>> >> >> >
>> >> >> > 1) subform 1 is submitted
>> >> >> > 2) subform 1 & 2 are decoded, storing the submitted value ("" for
>> >> >> > the
>> >> >> > inputText in the 2nd subform)
>> >> >> > 3) subform 1 is validated
>> >> >> > 4) subform 1 is updated
>> >> >> > 5) render subform 1, inputText renders the "value" attribute
>> >> >> > 6) render subform 2, inputText renders the "submittedValue"
>> >> >> > attribute
>> >> >> > (blank string - "")
>> >> >> >
>> >> >> > So to me this looks like a design flaw of the subform component.
>> >> >> > IMO,
>> >> >> > I would file a bug. Fixing it based on looking at the current
>> >> >> > design
>> >> >> > could be a pain in the rear. I wonder how the Tomahawk subform
>> >> >> > handles
>> >> >> > the same situation?
>> >> >> >
>> >> >> > As a workaround, you would have to find all components under
>> >> >> > non-submitted subforms that implement EditableValueHolder and set
>> >> >> > their submitted value to null.
>> >> >> >
>> >> >> > -Andrew
>> >> >> >
>> >> >> > On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão
>> >> >> > <wa...@gmail.com>
>> >> >> > wrote:
>> >> >> >> Actually it looks like the issue isn't related with PPR. I just
>> >> >> >> tested
>> >> >> >> without PPR (see code below) and had the same result:
>> >> >> >>
>> >> >> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> >> >> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>> >> >> >> xmlns:f="http://java.sun.com/jsf/core"
>> >> >> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >> >> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> >> >> >> <f:view>
>> >> >> >> <tr:document title="Apache Trinidad Blank Demo">
>> >> >> >> <tr:form>
>> >> >> >> <tr:subform id="sub1">
>> >> >> >> <tr:panelPage>
>> >> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> >> <tr:inputText label="Your name" id="input1"
>> >> >> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >> <tr:commandButton id="button1" text="press me"
>> >> >> >> action="#{helloWorldBacking.send}"/>
>> >> >> >> </tr:panelPage>
>> >> >> >> </tr:subform>
>> >> >> >> <tr:subform id="sub2">
>> >> >> >> <tr:panelPage>
>> >> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> >> <tr:inputText label="Your name" id="input1"
>> >> >> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >> <tr:commandButton id="button1" text="press me"
>> >> >> >> action="#{helloWorldBacking.send}"/>
>> >> >> >> </tr:panelPage>
>> >> >> >> </tr:subform>
>> >> >> >> </tr:form>
>> >> >> >> </tr:document>
>> >> >> >> </f:view>
>> >> >> >> </jsp:root>
>> >> >> >>
>> >> >> >>
>> >> >> >> Walter Mourão
>> >> >> >> http://waltermourao.com.br
>> >> >> >> http://arcadian.com.br
>> >> >> >> http://oriens.com.br
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
>> >> >> >> <an...@gmail.com> wrote:
>> >> >> >>>
>> >> >> >>> Looks like you need to add partialTriggers to the components you
>> >> >> >>> want
>> >> >> >>> to update / refresh
>> >> >> >>>
>> >> >> >>> -A
>> >> >> >>>
>> >> >> >>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão
>> >> >> >>> <wa...@gmail.com>
>> >> >> >>> wrote:
>> >> >> >>> > Sorry the bump, but I'm in a dead end... Does anybody know a
>> >> >> >>> > workaround
>> >> >> >>> > ?
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > Walter Mourão
>> >> >> >>> > http://waltermourao.com.br
>> >> >> >>> > http://arcadian.com.br
>> >> >> >>> > http://oriens.com.br
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão
>> >> >> >>> > <wa...@gmail.com>
>> >> >> >>> > wrote:
>> >> >> >>> >>
>> >> >> >>> >> Hi folks,
>> >> >> >>> >> I'm dealing with a strange behavior when using subforms and I
>> >> >> >>> >> reproduced
>> >> >> >>> >> it using the trinidad-blank example (from 1.0.9, but I found
>> >> >> >>> >> the
>> >> >> >>> >> problem
>> >> >> >>> >> first with 1.0.5).
>> >> >> >>> >> When executing an action from subform 1, only the inputs of
>> >> >> >>> >> the
>> >> >> >>> >> subform
>> >> >> >>> >> 1
>> >> >> >>> >> are refreshed and show the new value. Besides that, when I
>> >> >> >>> >> added
>> >> >> >>> >> a
>> >> >> >>> >> tr:outputText to the subform, pointing to the same backing
>> >> >> >>> >> bean
>> >> >> >>> >> property, it
>> >> >> >>> >> shows the new value, so the tr:inputText and tr:outputText
>> >> >> >>> >> (of
>> >> >> >>> >> the
>> >> >> >>> >> subform
>> >> >> >>> >> 2) shows differente values...
>> >> >> >>> >>
>> >> >> >>> >> To reproduce using the trinidad-blank example:
>> >> >> >>> >> 1 - change HelloWorldBacking.send to:
>> >> >> >>> >> public String send()
>> >> >> >>> >> {
>> >> >> >>> >> _name = _name.toUpperCase();
>> >> >> >>> >>
>> >> >> >>> >> return null;
>> >> >> >>> >> }
>> >> >> >>> >>
>> >> >> >>> >> 2 - add the file two_subforms.jspx with the content:
>> >> >> >>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> >> >> >>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
>> >> >> >>> >> version="2.0"
>> >> >> >>> >> xmlns:f="http://java.sun.com/jsf/core"
>> >> >> >>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >> >> >>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> >> >> >>> >> <f:view>
>> >> >> >>> >> <tr:document title="Apache Trinidad Blank Demo">
>> >> >> >>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
>> >> >> >>> >> <tr:subform id="sub1">
>> >> >> >>> >> <tr:panelPage>
>> >> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> >>> >> <tr:inputText label="Your name" id="input1"
>> >> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >>> >> <tr:commandButton id="button1" text="press me"
>> >> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >> >> >>> >> </tr:panelPage>
>> >> >> >>> >> </tr:subform>
>> >> >> >>> >> <tr:subform id="sub2">
>> >> >> >>> >> <tr:panelPage>
>> >> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> >>> >> <tr:inputText label="Your name" id="input1"
>> >> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> >>> >> <tr:commandButton id="button1" text="press me"
>> >> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >> >> >>> >> </tr:panelPage>
>> >> >> >>> >> </tr:subform>
>> >> >> >>> >> </tr:form>
>> >> >> >>> >> </tr:document>
>> >> >> >>> >> </f:view>
>> >> >> >>> >> </jsp:root>
>> >> >> >>> >>
>> >> >> >>> >> 3 - start the application, go to /faces/two_subforms.jspx,
>> >> >> >>> >> add a
>> >> >> >>> >> text
>> >> >> >>> >> in
>> >> >> >>> >> one of the inputs and click "press me".
>> >> >> >>> >>
>> >> >> >>> >> This behavior happens with partialSubmit="false" too.
>> >> >> >>> >>
>> >> >> >>> >> Please confirm if it is a bug (and I file a jira issue) and
>> >> >> >>> >> if
>> >> >> >>> >> it
>> >> >> >>> >> has
>> >> >> >>> >> an
>> >> >> >>> >> workaround.
>> >> >> >>> >>
>> >> >> >>> >> Thanks in advance,
>> >> >> >>> >>
>> >> >> >>> >>
>> >> >> >>> >> Walter Mourão
>> >> >> >>> >> http://waltermourao.com.br
>> >> >> >>> >> http://arcadian.com.br
>> >> >> >>> >> http://oriens.com.br
>> >> >> >>> >>
>> >> >> >>> >
>> >> >> >>> >
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> inexso - information exchange solutions GmbH
>> >> >> Bismarckstraße 13 | 26122 Oldenburg
>> >> >> Tel.: +49 441 4082 356 |
>> >> >> FAX: +49 441 4082 355 | www.inexso.de
>> >> >
>> >> >
>> >
>> >
>
>
Re: [Trinidad] Strange subform behavior
Posted by Walter Mourão <wa...@gmail.com>.
Hi Andrew,
Is there a way to force all components (editable or not) to be "refreshed"
from the bean values ?
Thanks in advance,
Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br
On Wed, Sep 10, 2008 at 4:04 PM, Andrew Robinson <
andrew.rw.robinson@gmail.com> wrote:
> I wonder if a better idea is to address this from JSF or from the
> Input behavior. This is not restricted to the subform. The problem is
> that a component with a submitted value will not display a model value
> if the model value changes.
>
> This could be addressed by something like:
>
> <tr:inputText value="#{bean.value}">
> <trs:modelChangeBehavior />
> </tr:inputText>
>
> The modelChangeBehavior would be a component that would clear the
> submitted value & local value when the value of the
> EditableValueHolder parent (requirement) changes between the end of
> the APPLY_REQUEST_VALUES phase and the end of the INVOKE_APPLICATION
> phase.
>
> Note that this can be done in JSF 1.2 without a custom component by
> using the <f:phaseListener /> tag. This may be the best solution.
>
> How to implement:
> 1) Add <f:phaseListener />
> 2) Have that bound to a managed bean (request scope)
> 3) Have that managed bean implement PhaseListener
> 4) Use ANY_PHASE for the PhaseId
> 5) on APPLY_REQUEST_VALUES get the component (use component binding is
> the best solution I guess)
> 6) get the value attribute & store it somewhere (in the bean probably best)
> 7) in INVOKE_APPLICATION, check the value and see if it changed. If
> so, then clear the component
>
> -Andrew
>
>
> On Wed, Sep 10, 2008 at 12:25 PM, Walter Mourão <wa...@gmail.com>
> wrote:
> > I will try the Andrew's workaround and/or try another way to accomplish
> what
> > I want.
> >
> > I will defend my point of view because:
> > 1 - PPR already allows perfectly one to avoid refresh some of the view,
> so
> > it is possible to have control when it is not desired to refresh a
> subform;
> > 2 - tr:outputText and tr:inputText should have a similar behavior when
> > showing the property value.
> >
> > Thank you very much, guys.
> >
> > Walter Mourão
> > http://waltermourao.com.br
> > http://arcadian.com.br
> > http://oriens.com.br
> >
> >
> >
> > On Wed, Sep 10, 2008 at 3:12 PM, Andrew Robinson
> > <an...@gmail.com> wrote:
> >>
> >> IMO, the user is submitting the subform, not the entire page,
> >> therefore only the subform values should be sent & everything else
> >> lost right? Perhaps a toggle option would be desired. I can see the
> >> value of both approaches.
> >>
> >> Using two different tr:forms would theoretically work, but that is not
> >> always easy to visually use. I would think that this would be
> >> discussed before any thought of a fix could be made. It just seems
> >> that there is no support for Walter's use case. I would think that it
> >> would be possible to come up with both use cases of (1) preserving
> >> current input components values that the client entered and (2) losing
> >> the values to reflect changes to the model.
> >>
> >> Right now, JSF treats use case #2 very poorly and the standard
> >> work-around is to clear the submitted value and local values from
> >> EditableValueHolders when it is desired to reset their rendered state
> >> to their model values.
> >>
> >> Maybe the subform is not the best place to fix this, I am not sure.
> >>
> >> -Andrew
> >>
> >> On Wed, Sep 10, 2008 at 11:58 AM, Walter Mourão <
> walter.mourao@gmail.com>
> >> wrote:
> >> > Hi Volker,
> >> >
> >> > I think the question is not if it was submitted or not but if all the
> >> > visible references (inputText, outputText or everything else) of a
> >> > property
> >> > instance show its current value when the view is rendered.
> >> >
> >> > Regards,
> >> >
> >> > Walter Mourão
> >> > http://waltermourao.com.br
> >> > http://arcadian.com.br
> >> > http://oriens.com.br
> >> >
> >> >
> >> >
> >> > On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <v....@inexso.de>
> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> why would you expect a not submited subform should loose changes made
> >> >> on the client (the submitted value)?
> >> >>
> >> >> This is exact the behavior i would expect. And BTW how the tobago
> >> >> subform
> >> >> works.
> >> >>
> >> >>
> >> >> Regards,
> >> >> Volker
> >> >>
> >> >> 2008/9/10 Andrew Robinson <an...@gmail.com>:
> >> >> > Okay, I know the problem:
> >> >> >
> >> >> > The Subform allows the decode phase of all the children, regardless
> >> >> > of
> >> >> > what was clicked on. If an event was queued inside of the subform,
> >> >> > but
> >> >> > not during the apply phase, the form is considered "submitted".
> Only
> >> >> > the submitted form will be validated & updated.
> >> >> >
> >> >> > Now, UIXInput (and UIInput) render the submitted value as the
> current
> >> >> > value if it is set. Therefore:
> >> >> >
> >> >> > 1) subform 1 is submitted
> >> >> > 2) subform 1 & 2 are decoded, storing the submitted value ("" for
> the
> >> >> > inputText in the 2nd subform)
> >> >> > 3) subform 1 is validated
> >> >> > 4) subform 1 is updated
> >> >> > 5) render subform 1, inputText renders the "value" attribute
> >> >> > 6) render subform 2, inputText renders the "submittedValue"
> attribute
> >> >> > (blank string - "")
> >> >> >
> >> >> > So to me this looks like a design flaw of the subform component.
> IMO,
> >> >> > I would file a bug. Fixing it based on looking at the current
> design
> >> >> > could be a pain in the rear. I wonder how the Tomahawk subform
> >> >> > handles
> >> >> > the same situation?
> >> >> >
> >> >> > As a workaround, you would have to find all components under
> >> >> > non-submitted subforms that implement EditableValueHolder and set
> >> >> > their submitted value to null.
> >> >> >
> >> >> > -Andrew
> >> >> >
> >> >> > On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão
> >> >> > <wa...@gmail.com>
> >> >> > wrote:
> >> >> >> Actually it looks like the issue isn't related with PPR. I just
> >> >> >> tested
> >> >> >> without PPR (see code below) and had the same result:
> >> >> >>
> >> >> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
> >> >> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
> >> >> >> xmlns:f="http://java.sun.com/jsf/core"
> >> >> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
> >> >> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
> >> >> >> <f:view>
> >> >> >> <tr:document title="Apache Trinidad Blank Demo">
> >> >> >> <tr:form>
> >> >> >> <tr:subform id="sub1">
> >> >> >> <tr:panelPage>
> >> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> >> >> <tr:inputText label="Your name" id="input1"
> >> >> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >> >> <tr:commandButton id="button1" text="press me"
> >> >> >> action="#{helloWorldBacking.send}"/>
> >> >> >> </tr:panelPage>
> >> >> >> </tr:subform>
> >> >> >> <tr:subform id="sub2">
> >> >> >> <tr:panelPage>
> >> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> >> >> <tr:inputText label="Your name" id="input1"
> >> >> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >> >> <tr:commandButton id="button1" text="press me"
> >> >> >> action="#{helloWorldBacking.send}"/>
> >> >> >> </tr:panelPage>
> >> >> >> </tr:subform>
> >> >> >> </tr:form>
> >> >> >> </tr:document>
> >> >> >> </f:view>
> >> >> >> </jsp:root>
> >> >> >>
> >> >> >>
> >> >> >> Walter Mourão
> >> >> >> http://waltermourao.com.br
> >> >> >> http://arcadian.com.br
> >> >> >> http://oriens.com.br
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
> >> >> >> <an...@gmail.com> wrote:
> >> >> >>>
> >> >> >>> Looks like you need to add partialTriggers to the components you
> >> >> >>> want
> >> >> >>> to update / refresh
> >> >> >>>
> >> >> >>> -A
> >> >> >>>
> >> >> >>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão
> >> >> >>> <wa...@gmail.com>
> >> >> >>> wrote:
> >> >> >>> > Sorry the bump, but I'm in a dead end... Does anybody know a
> >> >> >>> > workaround
> >> >> >>> > ?
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > Walter Mourão
> >> >> >>> > http://waltermourao.com.br
> >> >> >>> > http://arcadian.com.br
> >> >> >>> > http://oriens.com.br
> >> >> >>> >
> >> >> >>> >
> >> >> >>> >
> >> >> >>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão
> >> >> >>> > <wa...@gmail.com>
> >> >> >>> > wrote:
> >> >> >>> >>
> >> >> >>> >> Hi folks,
> >> >> >>> >> I'm dealing with a strange behavior when using subforms and I
> >> >> >>> >> reproduced
> >> >> >>> >> it using the trinidad-blank example (from 1.0.9, but I found
> the
> >> >> >>> >> problem
> >> >> >>> >> first with 1.0.5).
> >> >> >>> >> When executing an action from subform 1, only the inputs of
> the
> >> >> >>> >> subform
> >> >> >>> >> 1
> >> >> >>> >> are refreshed and show the new value. Besides that, when I
> added
> >> >> >>> >> a
> >> >> >>> >> tr:outputText to the subform, pointing to the same backing
> bean
> >> >> >>> >> property, it
> >> >> >>> >> shows the new value, so the tr:inputText and tr:outputText (of
> >> >> >>> >> the
> >> >> >>> >> subform
> >> >> >>> >> 2) shows differente values...
> >> >> >>> >>
> >> >> >>> >> To reproduce using the trinidad-blank example:
> >> >> >>> >> 1 - change HelloWorldBacking.send to:
> >> >> >>> >> public String send()
> >> >> >>> >> {
> >> >> >>> >> _name = _name.toUpperCase();
> >> >> >>> >>
> >> >> >>> >> return null;
> >> >> >>> >> }
> >> >> >>> >>
> >> >> >>> >> 2 - add the file two_subforms.jspx with the content:
> >> >> >>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
> >> >> >>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page"
> version="2.0"
> >> >> >>> >> xmlns:f="http://java.sun.com/jsf/core"
> >> >> >>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
> >> >> >>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
> >> >> >>> >> <f:view>
> >> >> >>> >> <tr:document title="Apache Trinidad Blank Demo">
> >> >> >>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
> >> >> >>> >> <tr:subform id="sub1">
> >> >> >>> >> <tr:panelPage>
> >> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> >> >>> >> <tr:inputText label="Your name" id="input1"
> >> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >> >>> >> <tr:commandButton id="button1" text="press me"
> >> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> >> >> >>> >> </tr:panelPage>
> >> >> >>> >> </tr:subform>
> >> >> >>> >> <tr:subform id="sub2">
> >> >> >>> >> <tr:panelPage>
> >> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> >> >>> >> <tr:inputText label="Your name" id="input1"
> >> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >> >>> >> <tr:commandButton id="button1" text="press me"
> >> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> >> >> >>> >> </tr:panelPage>
> >> >> >>> >> </tr:subform>
> >> >> >>> >> </tr:form>
> >> >> >>> >> </tr:document>
> >> >> >>> >> </f:view>
> >> >> >>> >> </jsp:root>
> >> >> >>> >>
> >> >> >>> >> 3 - start the application, go to /faces/two_subforms.jspx, add
> a
> >> >> >>> >> text
> >> >> >>> >> in
> >> >> >>> >> one of the inputs and click "press me".
> >> >> >>> >>
> >> >> >>> >> This behavior happens with partialSubmit="false" too.
> >> >> >>> >>
> >> >> >>> >> Please confirm if it is a bug (and I file a jira issue) and if
> >> >> >>> >> it
> >> >> >>> >> has
> >> >> >>> >> an
> >> >> >>> >> workaround.
> >> >> >>> >>
> >> >> >>> >> Thanks in advance,
> >> >> >>> >>
> >> >> >>> >>
> >> >> >>> >> Walter Mourão
> >> >> >>> >> http://waltermourao.com.br
> >> >> >>> >> http://arcadian.com.br
> >> >> >>> >> http://oriens.com.br
> >> >> >>> >>
> >> >> >>> >
> >> >> >>> >
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> inexso - information exchange solutions GmbH
> >> >> Bismarckstraße 13 | 26122 Oldenburg
> >> >> Tel.: +49 441 4082 356 |
> >> >> FAX: +49 441 4082 355 | www.inexso.de
> >> >
> >> >
> >
> >
>
Re: [Trinidad] Strange subform behavior
Posted by Andrew Robinson <an...@gmail.com>.
I wonder if a better idea is to address this from JSF or from the
Input behavior. This is not restricted to the subform. The problem is
that a component with a submitted value will not display a model value
if the model value changes.
This could be addressed by something like:
<tr:inputText value="#{bean.value}">
<trs:modelChangeBehavior />
</tr:inputText>
The modelChangeBehavior would be a component that would clear the
submitted value & local value when the value of the
EditableValueHolder parent (requirement) changes between the end of
the APPLY_REQUEST_VALUES phase and the end of the INVOKE_APPLICATION
phase.
Note that this can be done in JSF 1.2 without a custom component by
using the <f:phaseListener /> tag. This may be the best solution.
How to implement:
1) Add <f:phaseListener />
2) Have that bound to a managed bean (request scope)
3) Have that managed bean implement PhaseListener
4) Use ANY_PHASE for the PhaseId
5) on APPLY_REQUEST_VALUES get the component (use component binding is
the best solution I guess)
6) get the value attribute & store it somewhere (in the bean probably best)
7) in INVOKE_APPLICATION, check the value and see if it changed. If
so, then clear the component
-Andrew
On Wed, Sep 10, 2008 at 12:25 PM, Walter Mourão <wa...@gmail.com> wrote:
> I will try the Andrew's workaround and/or try another way to accomplish what
> I want.
>
> I will defend my point of view because:
> 1 - PPR already allows perfectly one to avoid refresh some of the view, so
> it is possible to have control when it is not desired to refresh a subform;
> 2 - tr:outputText and tr:inputText should have a similar behavior when
> showing the property value.
>
> Thank you very much, guys.
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>
>
> On Wed, Sep 10, 2008 at 3:12 PM, Andrew Robinson
> <an...@gmail.com> wrote:
>>
>> IMO, the user is submitting the subform, not the entire page,
>> therefore only the subform values should be sent & everything else
>> lost right? Perhaps a toggle option would be desired. I can see the
>> value of both approaches.
>>
>> Using two different tr:forms would theoretically work, but that is not
>> always easy to visually use. I would think that this would be
>> discussed before any thought of a fix could be made. It just seems
>> that there is no support for Walter's use case. I would think that it
>> would be possible to come up with both use cases of (1) preserving
>> current input components values that the client entered and (2) losing
>> the values to reflect changes to the model.
>>
>> Right now, JSF treats use case #2 very poorly and the standard
>> work-around is to clear the submitted value and local values from
>> EditableValueHolders when it is desired to reset their rendered state
>> to their model values.
>>
>> Maybe the subform is not the best place to fix this, I am not sure.
>>
>> -Andrew
>>
>> On Wed, Sep 10, 2008 at 11:58 AM, Walter Mourão <wa...@gmail.com>
>> wrote:
>> > Hi Volker,
>> >
>> > I think the question is not if it was submitted or not but if all the
>> > visible references (inputText, outputText or everything else) of a
>> > property
>> > instance show its current value when the view is rendered.
>> >
>> > Regards,
>> >
>> > Walter Mourão
>> > http://waltermourao.com.br
>> > http://arcadian.com.br
>> > http://oriens.com.br
>> >
>> >
>> >
>> > On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <v....@inexso.de> wrote:
>> >>
>> >> Hi,
>> >>
>> >> why would you expect a not submited subform should loose changes made
>> >> on the client (the submitted value)?
>> >>
>> >> This is exact the behavior i would expect. And BTW how the tobago
>> >> subform
>> >> works.
>> >>
>> >>
>> >> Regards,
>> >> Volker
>> >>
>> >> 2008/9/10 Andrew Robinson <an...@gmail.com>:
>> >> > Okay, I know the problem:
>> >> >
>> >> > The Subform allows the decode phase of all the children, regardless
>> >> > of
>> >> > what was clicked on. If an event was queued inside of the subform,
>> >> > but
>> >> > not during the apply phase, the form is considered "submitted". Only
>> >> > the submitted form will be validated & updated.
>> >> >
>> >> > Now, UIXInput (and UIInput) render the submitted value as the current
>> >> > value if it is set. Therefore:
>> >> >
>> >> > 1) subform 1 is submitted
>> >> > 2) subform 1 & 2 are decoded, storing the submitted value ("" for the
>> >> > inputText in the 2nd subform)
>> >> > 3) subform 1 is validated
>> >> > 4) subform 1 is updated
>> >> > 5) render subform 1, inputText renders the "value" attribute
>> >> > 6) render subform 2, inputText renders the "submittedValue" attribute
>> >> > (blank string - "")
>> >> >
>> >> > So to me this looks like a design flaw of the subform component. IMO,
>> >> > I would file a bug. Fixing it based on looking at the current design
>> >> > could be a pain in the rear. I wonder how the Tomahawk subform
>> >> > handles
>> >> > the same situation?
>> >> >
>> >> > As a workaround, you would have to find all components under
>> >> > non-submitted subforms that implement EditableValueHolder and set
>> >> > their submitted value to null.
>> >> >
>> >> > -Andrew
>> >> >
>> >> > On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão
>> >> > <wa...@gmail.com>
>> >> > wrote:
>> >> >> Actually it looks like the issue isn't related with PPR. I just
>> >> >> tested
>> >> >> without PPR (see code below) and had the same result:
>> >> >>
>> >> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> >> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>> >> >> xmlns:f="http://java.sun.com/jsf/core"
>> >> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> >> >> <f:view>
>> >> >> <tr:document title="Apache Trinidad Blank Demo">
>> >> >> <tr:form>
>> >> >> <tr:subform id="sub1">
>> >> >> <tr:panelPage>
>> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> <tr:inputText label="Your name" id="input1"
>> >> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> <tr:commandButton id="button1" text="press me"
>> >> >> action="#{helloWorldBacking.send}"/>
>> >> >> </tr:panelPage>
>> >> >> </tr:subform>
>> >> >> <tr:subform id="sub2">
>> >> >> <tr:panelPage>
>> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >> <tr:inputText label="Your name" id="input1"
>> >> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >> <tr:commandButton id="button1" text="press me"
>> >> >> action="#{helloWorldBacking.send}"/>
>> >> >> </tr:panelPage>
>> >> >> </tr:subform>
>> >> >> </tr:form>
>> >> >> </tr:document>
>> >> >> </f:view>
>> >> >> </jsp:root>
>> >> >>
>> >> >>
>> >> >> Walter Mourão
>> >> >> http://waltermourao.com.br
>> >> >> http://arcadian.com.br
>> >> >> http://oriens.com.br
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
>> >> >> <an...@gmail.com> wrote:
>> >> >>>
>> >> >>> Looks like you need to add partialTriggers to the components you
>> >> >>> want
>> >> >>> to update / refresh
>> >> >>>
>> >> >>> -A
>> >> >>>
>> >> >>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão
>> >> >>> <wa...@gmail.com>
>> >> >>> wrote:
>> >> >>> > Sorry the bump, but I'm in a dead end... Does anybody know a
>> >> >>> > workaround
>> >> >>> > ?
>> >> >>> >
>> >> >>> >
>> >> >>> > Walter Mourão
>> >> >>> > http://waltermourao.com.br
>> >> >>> > http://arcadian.com.br
>> >> >>> > http://oriens.com.br
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão
>> >> >>> > <wa...@gmail.com>
>> >> >>> > wrote:
>> >> >>> >>
>> >> >>> >> Hi folks,
>> >> >>> >> I'm dealing with a strange behavior when using subforms and I
>> >> >>> >> reproduced
>> >> >>> >> it using the trinidad-blank example (from 1.0.9, but I found the
>> >> >>> >> problem
>> >> >>> >> first with 1.0.5).
>> >> >>> >> When executing an action from subform 1, only the inputs of the
>> >> >>> >> subform
>> >> >>> >> 1
>> >> >>> >> are refreshed and show the new value. Besides that, when I added
>> >> >>> >> a
>> >> >>> >> tr:outputText to the subform, pointing to the same backing bean
>> >> >>> >> property, it
>> >> >>> >> shows the new value, so the tr:inputText and tr:outputText (of
>> >> >>> >> the
>> >> >>> >> subform
>> >> >>> >> 2) shows differente values...
>> >> >>> >>
>> >> >>> >> To reproduce using the trinidad-blank example:
>> >> >>> >> 1 - change HelloWorldBacking.send to:
>> >> >>> >> public String send()
>> >> >>> >> {
>> >> >>> >> _name = _name.toUpperCase();
>> >> >>> >>
>> >> >>> >> return null;
>> >> >>> >> }
>> >> >>> >>
>> >> >>> >> 2 - add the file two_subforms.jspx with the content:
>> >> >>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> >> >>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>> >> >>> >> xmlns:f="http://java.sun.com/jsf/core"
>> >> >>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >> >>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> >> >>> >> <f:view>
>> >> >>> >> <tr:document title="Apache Trinidad Blank Demo">
>> >> >>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
>> >> >>> >> <tr:subform id="sub1">
>> >> >>> >> <tr:panelPage>
>> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >>> >> <tr:inputText label="Your name" id="input1"
>> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >>> >> <tr:commandButton id="button1" text="press me"
>> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >> >>> >> </tr:panelPage>
>> >> >>> >> </tr:subform>
>> >> >>> >> <tr:subform id="sub2">
>> >> >>> >> <tr:panelPage>
>> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> >>> >> <tr:inputText label="Your name" id="input1"
>> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> >>> >> <tr:commandButton id="button1" text="press me"
>> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >> >>> >> </tr:panelPage>
>> >> >>> >> </tr:subform>
>> >> >>> >> </tr:form>
>> >> >>> >> </tr:document>
>> >> >>> >> </f:view>
>> >> >>> >> </jsp:root>
>> >> >>> >>
>> >> >>> >> 3 - start the application, go to /faces/two_subforms.jspx, add a
>> >> >>> >> text
>> >> >>> >> in
>> >> >>> >> one of the inputs and click "press me".
>> >> >>> >>
>> >> >>> >> This behavior happens with partialSubmit="false" too.
>> >> >>> >>
>> >> >>> >> Please confirm if it is a bug (and I file a jira issue) and if
>> >> >>> >> it
>> >> >>> >> has
>> >> >>> >> an
>> >> >>> >> workaround.
>> >> >>> >>
>> >> >>> >> Thanks in advance,
>> >> >>> >>
>> >> >>> >>
>> >> >>> >> Walter Mourão
>> >> >>> >> http://waltermourao.com.br
>> >> >>> >> http://arcadian.com.br
>> >> >>> >> http://oriens.com.br
>> >> >>> >>
>> >> >>> >
>> >> >>> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> inexso - information exchange solutions GmbH
>> >> Bismarckstraße 13 | 26122 Oldenburg
>> >> Tel.: +49 441 4082 356 |
>> >> FAX: +49 441 4082 355 | www.inexso.de
>> >
>> >
>
>
Re: [Trinidad] Strange subform behavior
Posted by Walter Mourão <wa...@gmail.com>.
I will try the Andrew's workaround and/or try another way to accomplish what
I want.
I will defend my point of view because:
1 - PPR already allows perfectly one to avoid refresh some of the view, so
it is possible to have control when it is *not* desired to refresh a
subform;
2 - tr:outputText and tr:inputText should have a similar behavior when
showing the property value.
Thank you very much, guys.
Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br
On Wed, Sep 10, 2008 at 3:12 PM, Andrew Robinson <
andrew.rw.robinson@gmail.com> wrote:
> IMO, the user is submitting the subform, not the entire page,
> therefore only the subform values should be sent & everything else
> lost right? Perhaps a toggle option would be desired. I can see the
> value of both approaches.
>
> Using two different tr:forms would theoretically work, but that is not
> always easy to visually use. I would think that this would be
> discussed before any thought of a fix could be made. It just seems
> that there is no support for Walter's use case. I would think that it
> would be possible to come up with both use cases of (1) preserving
> current input components values that the client entered and (2) losing
> the values to reflect changes to the model.
>
> Right now, JSF treats use case #2 very poorly and the standard
> work-around is to clear the submitted value and local values from
> EditableValueHolders when it is desired to reset their rendered state
> to their model values.
>
> Maybe the subform is not the best place to fix this, I am not sure.
>
> -Andrew
>
> On Wed, Sep 10, 2008 at 11:58 AM, Walter Mourão <wa...@gmail.com>
> wrote:
> > Hi Volker,
> >
> > I think the question is not if it was submitted or not but if all the
> > visible references (inputText, outputText or everything else) of a
> property
> > instance show its current value when the view is rendered.
> >
> > Regards,
> >
> > Walter Mourão
> > http://waltermourao.com.br
> > http://arcadian.com.br
> > http://oriens.com.br
> >
> >
> >
> > On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <v....@inexso.de> wrote:
> >>
> >> Hi,
> >>
> >> why would you expect a not submited subform should loose changes made
> >> on the client (the submitted value)?
> >>
> >> This is exact the behavior i would expect. And BTW how the tobago
> subform
> >> works.
> >>
> >>
> >> Regards,
> >> Volker
> >>
> >> 2008/9/10 Andrew Robinson <an...@gmail.com>:
> >> > Okay, I know the problem:
> >> >
> >> > The Subform allows the decode phase of all the children, regardless of
> >> > what was clicked on. If an event was queued inside of the subform, but
> >> > not during the apply phase, the form is considered "submitted". Only
> >> > the submitted form will be validated & updated.
> >> >
> >> > Now, UIXInput (and UIInput) render the submitted value as the current
> >> > value if it is set. Therefore:
> >> >
> >> > 1) subform 1 is submitted
> >> > 2) subform 1 & 2 are decoded, storing the submitted value ("" for the
> >> > inputText in the 2nd subform)
> >> > 3) subform 1 is validated
> >> > 4) subform 1 is updated
> >> > 5) render subform 1, inputText renders the "value" attribute
> >> > 6) render subform 2, inputText renders the "submittedValue" attribute
> >> > (blank string - "")
> >> >
> >> > So to me this looks like a design flaw of the subform component. IMO,
> >> > I would file a bug. Fixing it based on looking at the current design
> >> > could be a pain in the rear. I wonder how the Tomahawk subform handles
> >> > the same situation?
> >> >
> >> > As a workaround, you would have to find all components under
> >> > non-submitted subforms that implement EditableValueHolder and set
> >> > their submitted value to null.
> >> >
> >> > -Andrew
> >> >
> >> > On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão <
> walter.mourao@gmail.com>
> >> > wrote:
> >> >> Actually it looks like the issue isn't related with PPR. I just
> tested
> >> >> without PPR (see code below) and had the same result:
> >> >>
> >> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
> >> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
> >> >> xmlns:f="http://java.sun.com/jsf/core"
> >> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
> >> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
> >> >> <f:view>
> >> >> <tr:document title="Apache Trinidad Blank Demo">
> >> >> <tr:form>
> >> >> <tr:subform id="sub1">
> >> >> <tr:panelPage>
> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> >> <tr:inputText label="Your name" id="input1"
> >> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >> <tr:commandButton id="button1" text="press me"
> >> >> action="#{helloWorldBacking.send}"/>
> >> >> </tr:panelPage>
> >> >> </tr:subform>
> >> >> <tr:subform id="sub2">
> >> >> <tr:panelPage>
> >> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> >> <tr:inputText label="Your name" id="input1"
> >> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >> <tr:commandButton id="button1" text="press me"
> >> >> action="#{helloWorldBacking.send}"/>
> >> >> </tr:panelPage>
> >> >> </tr:subform>
> >> >> </tr:form>
> >> >> </tr:document>
> >> >> </f:view>
> >> >> </jsp:root>
> >> >>
> >> >>
> >> >> Walter Mourão
> >> >> http://waltermourao.com.br
> >> >> http://arcadian.com.br
> >> >> http://oriens.com.br
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
> >> >> <an...@gmail.com> wrote:
> >> >>>
> >> >>> Looks like you need to add partialTriggers to the components you
> want
> >> >>> to update / refresh
> >> >>>
> >> >>> -A
> >> >>>
> >> >>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão
> >> >>> <wa...@gmail.com>
> >> >>> wrote:
> >> >>> > Sorry the bump, but I'm in a dead end... Does anybody know a
> >> >>> > workaround
> >> >>> > ?
> >> >>> >
> >> >>> >
> >> >>> > Walter Mourão
> >> >>> > http://waltermourao.com.br
> >> >>> > http://arcadian.com.br
> >> >>> > http://oriens.com.br
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão
> >> >>> > <wa...@gmail.com>
> >> >>> > wrote:
> >> >>> >>
> >> >>> >> Hi folks,
> >> >>> >> I'm dealing with a strange behavior when using subforms and I
> >> >>> >> reproduced
> >> >>> >> it using the trinidad-blank example (from 1.0.9, but I found the
> >> >>> >> problem
> >> >>> >> first with 1.0.5).
> >> >>> >> When executing an action from subform 1, only the inputs of the
> >> >>> >> subform
> >> >>> >> 1
> >> >>> >> are refreshed and show the new value. Besides that, when I added
> a
> >> >>> >> tr:outputText to the subform, pointing to the same backing bean
> >> >>> >> property, it
> >> >>> >> shows the new value, so the tr:inputText and tr:outputText (of
> the
> >> >>> >> subform
> >> >>> >> 2) shows differente values...
> >> >>> >>
> >> >>> >> To reproduce using the trinidad-blank example:
> >> >>> >> 1 - change HelloWorldBacking.send to:
> >> >>> >> public String send()
> >> >>> >> {
> >> >>> >> _name = _name.toUpperCase();
> >> >>> >>
> >> >>> >> return null;
> >> >>> >> }
> >> >>> >>
> >> >>> >> 2 - add the file two_subforms.jspx with the content:
> >> >>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
> >> >>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
> >> >>> >> xmlns:f="http://java.sun.com/jsf/core"
> >> >>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
> >> >>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
> >> >>> >> <f:view>
> >> >>> >> <tr:document title="Apache Trinidad Blank Demo">
> >> >>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
> >> >>> >> <tr:subform id="sub1">
> >> >>> >> <tr:panelPage>
> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> >>> >> <tr:inputText label="Your name" id="input1"
> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >>> >> <tr:commandButton id="button1" text="press me"
> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> >> >>> >> </tr:panelPage>
> >> >>> >> </tr:subform>
> >> >>> >> <tr:subform id="sub2">
> >> >>> >> <tr:panelPage>
> >> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> >>> >> <tr:inputText label="Your name" id="input1"
> >> >>> >> value="#{helloWorldBacking.name}" required="true"/>
> >> >>> >> <tr:commandButton id="button1" text="press me"
> >> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> >> >>> >> </tr:panelPage>
> >> >>> >> </tr:subform>
> >> >>> >> </tr:form>
> >> >>> >> </tr:document>
> >> >>> >> </f:view>
> >> >>> >> </jsp:root>
> >> >>> >>
> >> >>> >> 3 - start the application, go to /faces/two_subforms.jspx, add a
> >> >>> >> text
> >> >>> >> in
> >> >>> >> one of the inputs and click "press me".
> >> >>> >>
> >> >>> >> This behavior happens with partialSubmit="false" too.
> >> >>> >>
> >> >>> >> Please confirm if it is a bug (and I file a jira issue) and if it
> >> >>> >> has
> >> >>> >> an
> >> >>> >> workaround.
> >> >>> >>
> >> >>> >> Thanks in advance,
> >> >>> >>
> >> >>> >>
> >> >>> >> Walter Mourão
> >> >>> >> http://waltermourao.com.br
> >> >>> >> http://arcadian.com.br
> >> >>> >> http://oriens.com.br
> >> >>> >>
> >> >>> >
> >> >>> >
> >> >>
> >> >>
> >> >
> >>
> >>
> >>
> >> --
> >> inexso - information exchange solutions GmbH
> >> Bismarckstraße 13 | 26122 Oldenburg
> >> Tel.: +49 441 4082 356 |
> >> FAX: +49 441 4082 355 | www.inexso.de
> >
> >
>
Re: [Trinidad] Strange subform behavior
Posted by Andrew Robinson <an...@gmail.com>.
IMO, the user is submitting the subform, not the entire page,
therefore only the subform values should be sent & everything else
lost right? Perhaps a toggle option would be desired. I can see the
value of both approaches.
Using two different tr:forms would theoretically work, but that is not
always easy to visually use. I would think that this would be
discussed before any thought of a fix could be made. It just seems
that there is no support for Walter's use case. I would think that it
would be possible to come up with both use cases of (1) preserving
current input components values that the client entered and (2) losing
the values to reflect changes to the model.
Right now, JSF treats use case #2 very poorly and the standard
work-around is to clear the submitted value and local values from
EditableValueHolders when it is desired to reset their rendered state
to their model values.
Maybe the subform is not the best place to fix this, I am not sure.
-Andrew
On Wed, Sep 10, 2008 at 11:58 AM, Walter Mourão <wa...@gmail.com> wrote:
> Hi Volker,
>
> I think the question is not if it was submitted or not but if all the
> visible references (inputText, outputText or everything else) of a property
> instance show its current value when the view is rendered.
>
> Regards,
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>
>
> On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <v....@inexso.de> wrote:
>>
>> Hi,
>>
>> why would you expect a not submited subform should loose changes made
>> on the client (the submitted value)?
>>
>> This is exact the behavior i would expect. And BTW how the tobago subform
>> works.
>>
>>
>> Regards,
>> Volker
>>
>> 2008/9/10 Andrew Robinson <an...@gmail.com>:
>> > Okay, I know the problem:
>> >
>> > The Subform allows the decode phase of all the children, regardless of
>> > what was clicked on. If an event was queued inside of the subform, but
>> > not during the apply phase, the form is considered "submitted". Only
>> > the submitted form will be validated & updated.
>> >
>> > Now, UIXInput (and UIInput) render the submitted value as the current
>> > value if it is set. Therefore:
>> >
>> > 1) subform 1 is submitted
>> > 2) subform 1 & 2 are decoded, storing the submitted value ("" for the
>> > inputText in the 2nd subform)
>> > 3) subform 1 is validated
>> > 4) subform 1 is updated
>> > 5) render subform 1, inputText renders the "value" attribute
>> > 6) render subform 2, inputText renders the "submittedValue" attribute
>> > (blank string - "")
>> >
>> > So to me this looks like a design flaw of the subform component. IMO,
>> > I would file a bug. Fixing it based on looking at the current design
>> > could be a pain in the rear. I wonder how the Tomahawk subform handles
>> > the same situation?
>> >
>> > As a workaround, you would have to find all components under
>> > non-submitted subforms that implement EditableValueHolder and set
>> > their submitted value to null.
>> >
>> > -Andrew
>> >
>> > On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão <wa...@gmail.com>
>> > wrote:
>> >> Actually it looks like the issue isn't related with PPR. I just tested
>> >> without PPR (see code below) and had the same result:
>> >>
>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>> >> xmlns:f="http://java.sun.com/jsf/core"
>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> >> <f:view>
>> >> <tr:document title="Apache Trinidad Blank Demo">
>> >> <tr:form>
>> >> <tr:subform id="sub1">
>> >> <tr:panelPage>
>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> <tr:inputText label="Your name" id="input1"
>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> <tr:commandButton id="button1" text="press me"
>> >> action="#{helloWorldBacking.send}"/>
>> >> </tr:panelPage>
>> >> </tr:subform>
>> >> <tr:subform id="sub2">
>> >> <tr:panelPage>
>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> <tr:inputText label="Your name" id="input1"
>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> <tr:commandButton id="button1" text="press me"
>> >> action="#{helloWorldBacking.send}"/>
>> >> </tr:panelPage>
>> >> </tr:subform>
>> >> </tr:form>
>> >> </tr:document>
>> >> </f:view>
>> >> </jsp:root>
>> >>
>> >>
>> >> Walter Mourão
>> >> http://waltermourao.com.br
>> >> http://arcadian.com.br
>> >> http://oriens.com.br
>> >>
>> >>
>> >>
>> >> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
>> >> <an...@gmail.com> wrote:
>> >>>
>> >>> Looks like you need to add partialTriggers to the components you want
>> >>> to update / refresh
>> >>>
>> >>> -A
>> >>>
>> >>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão
>> >>> <wa...@gmail.com>
>> >>> wrote:
>> >>> > Sorry the bump, but I'm in a dead end... Does anybody know a
>> >>> > workaround
>> >>> > ?
>> >>> >
>> >>> >
>> >>> > Walter Mourão
>> >>> > http://waltermourao.com.br
>> >>> > http://arcadian.com.br
>> >>> > http://oriens.com.br
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão
>> >>> > <wa...@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> Hi folks,
>> >>> >> I'm dealing with a strange behavior when using subforms and I
>> >>> >> reproduced
>> >>> >> it using the trinidad-blank example (from 1.0.9, but I found the
>> >>> >> problem
>> >>> >> first with 1.0.5).
>> >>> >> When executing an action from subform 1, only the inputs of the
>> >>> >> subform
>> >>> >> 1
>> >>> >> are refreshed and show the new value. Besides that, when I added a
>> >>> >> tr:outputText to the subform, pointing to the same backing bean
>> >>> >> property, it
>> >>> >> shows the new value, so the tr:inputText and tr:outputText (of the
>> >>> >> subform
>> >>> >> 2) shows differente values...
>> >>> >>
>> >>> >> To reproduce using the trinidad-blank example:
>> >>> >> 1 - change HelloWorldBacking.send to:
>> >>> >> public String send()
>> >>> >> {
>> >>> >> _name = _name.toUpperCase();
>> >>> >>
>> >>> >> return null;
>> >>> >> }
>> >>> >>
>> >>> >> 2 - add the file two_subforms.jspx with the content:
>> >>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> >>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>> >>> >> xmlns:f="http://java.sun.com/jsf/core"
>> >>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> >>> >> <f:view>
>> >>> >> <tr:document title="Apache Trinidad Blank Demo">
>> >>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
>> >>> >> <tr:subform id="sub1">
>> >>> >> <tr:panelPage>
>> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >>> >> <tr:inputText label="Your name" id="input1"
>> >>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >>> >> <tr:commandButton id="button1" text="press me"
>> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >>> >> </tr:panelPage>
>> >>> >> </tr:subform>
>> >>> >> <tr:subform id="sub2">
>> >>> >> <tr:panelPage>
>> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >>> >> <tr:inputText label="Your name" id="input1"
>> >>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >>> >> <tr:commandButton id="button1" text="press me"
>> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >>> >> </tr:panelPage>
>> >>> >> </tr:subform>
>> >>> >> </tr:form>
>> >>> >> </tr:document>
>> >>> >> </f:view>
>> >>> >> </jsp:root>
>> >>> >>
>> >>> >> 3 - start the application, go to /faces/two_subforms.jspx, add a
>> >>> >> text
>> >>> >> in
>> >>> >> one of the inputs and click "press me".
>> >>> >>
>> >>> >> This behavior happens with partialSubmit="false" too.
>> >>> >>
>> >>> >> Please confirm if it is a bug (and I file a jira issue) and if it
>> >>> >> has
>> >>> >> an
>> >>> >> workaround.
>> >>> >>
>> >>> >> Thanks in advance,
>> >>> >>
>> >>> >>
>> >>> >> Walter Mourão
>> >>> >> http://waltermourao.com.br
>> >>> >> http://arcadian.com.br
>> >>> >> http://oriens.com.br
>> >>> >>
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>>
>>
>>
>> --
>> inexso - information exchange solutions GmbH
>> Bismarckstraße 13 | 26122 Oldenburg
>> Tel.: +49 441 4082 356 |
>> FAX: +49 441 4082 355 | www.inexso.de
>
>
Re: [Trinidad] Strange subform behavior
Posted by Bernd Bohmann <be...@atanion.com>.
Hello Walter,
only the submitted form invokes the PROCESS_VALIDATIONS Phase and
UPDATE_MODEL_VALUES Phase for his childs. If you want to display the new
values from the ValueBindings for all components you should return an
outcome. If you don't return an outcome the current view is displayed again.
Regards
Bernd
Walter Mourão schrieb:
> Hi Volker,
>
> I think the question is not if it was submitted or not but if all the
> visible references (inputText, outputText or everything else) of a property
> instance show its current value when the view is rendered.
>
> Regards,
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>
>
> On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <v....@inexso.de> wrote:
>
>> Hi,
>>
>> why would you expect a not submited subform should loose changes made
>> on the client (the submitted value)?
>>
>> This is exact the behavior i would expect. And BTW how the tobago subform
>> works.
>>
>>
>> Regards,
>> Volker
>>
>> 2008/9/10 Andrew Robinson <an...@gmail.com>:
>>> Okay, I know the problem:
>>>
>>> The Subform allows the decode phase of all the children, regardless of
>>> what was clicked on. If an event was queued inside of the subform, but
>>> not during the apply phase, the form is considered "submitted". Only
>>> the submitted form will be validated & updated.
>>>
>>> Now, UIXInput (and UIInput) render the submitted value as the current
>>> value if it is set. Therefore:
>>>
>>> 1) subform 1 is submitted
>>> 2) subform 1 & 2 are decoded, storing the submitted value ("" for the
>>> inputText in the 2nd subform)
>>> 3) subform 1 is validated
>>> 4) subform 1 is updated
>>> 5) render subform 1, inputText renders the "value" attribute
>>> 6) render subform 2, inputText renders the "submittedValue" attribute
>>> (blank string - "")
>>>
>>> So to me this looks like a design flaw of the subform component. IMO,
>>> I would file a bug. Fixing it based on looking at the current design
>>> could be a pain in the rear. I wonder how the Tomahawk subform handles
>>> the same situation?
>>>
>>> As a workaround, you would have to find all components under
>>> non-submitted subforms that implement EditableValueHolder and set
>>> their submitted value to null.
>>>
>>> -Andrew
>>>
>>> On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão <wa...@gmail.com>
>> wrote:
>>>> Actually it looks like the issue isn't related with PPR. I just tested
>>>> without PPR (see code below) and had the same result:
>>>>
>>>> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>>>> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>>>> xmlns:f="http://java.sun.com/jsf/core"
>>>> xmlns:tr="http://myfaces.apache.org/trinidad" >
>>>> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>>>> <f:view>
>>>> <tr:document title="Apache Trinidad Blank Demo">
>>>> <tr:form>
>>>> <tr:subform id="sub1">
>>>> <tr:panelPage>
>>>> <tr:outputText value="#{helloWorldBacking.name}" />
>>>> <tr:inputText label="Your name" id="input1"
>>>> value="#{helloWorldBacking.name}" required="true"/>
>>>> <tr:commandButton id="button1" text="press me"
>>>> action="#{helloWorldBacking.send}"/>
>>>> </tr:panelPage>
>>>> </tr:subform>
>>>> <tr:subform id="sub2">
>>>> <tr:panelPage>
>>>> <tr:outputText value="#{helloWorldBacking.name}" />
>>>> <tr:inputText label="Your name" id="input1"
>>>> value="#{helloWorldBacking.name}" required="true"/>
>>>> <tr:commandButton id="button1" text="press me"
>>>> action="#{helloWorldBacking.send}"/>
>>>> </tr:panelPage>
>>>> </tr:subform>
>>>> </tr:form>
>>>> </tr:document>
>>>> </f:view>
>>>> </jsp:root>
>>>>
>>>>
>>>> Walter Mourão
>>>> http://waltermourao.com.br
>>>> http://arcadian.com.br
>>>> http://oriens.com.br
>>>>
>>>>
>>>>
>>>> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
>>>> <an...@gmail.com> wrote:
>>>>> Looks like you need to add partialTriggers to the components you want
>>>>> to update / refresh
>>>>>
>>>>> -A
>>>>>
>>>>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão <
>> walter.mourao@gmail.com>
>>>>> wrote:
>>>>>> Sorry the bump, but I'm in a dead end... Does anybody know a
>> workaround
>>>>>> ?
>>>>>>
>>>>>>
>>>>>> Walter Mourão
>>>>>> http://waltermourao.com.br
>>>>>> http://arcadian.com.br
>>>>>> http://oriens.com.br
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão <
>> walter.mourao@gmail.com>
>>>>>> wrote:
>>>>>>> Hi folks,
>>>>>>> I'm dealing with a strange behavior when using subforms and I
>>>>>>> reproduced
>>>>>>> it using the trinidad-blank example (from 1.0.9, but I found the
>>>>>>> problem
>>>>>>> first with 1.0.5).
>>>>>>> When executing an action from subform 1, only the inputs of the
>> subform
>>>>>>> 1
>>>>>>> are refreshed and show the new value. Besides that, when I added a
>>>>>>> tr:outputText to the subform, pointing to the same backing bean
>>>>>>> property, it
>>>>>>> shows the new value, so the tr:inputText and tr:outputText (of the
>>>>>>> subform
>>>>>>> 2) shows differente values...
>>>>>>>
>>>>>>> To reproduce using the trinidad-blank example:
>>>>>>> 1 - change HelloWorldBacking.send to:
>>>>>>> public String send()
>>>>>>> {
>>>>>>> _name = _name.toUpperCase();
>>>>>>>
>>>>>>> return null;
>>>>>>> }
>>>>>>>
>>>>>>> 2 - add the file two_subforms.jspx with the content:
>>>>>>> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>>>>>>> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>>>>>>> xmlns:f="http://java.sun.com/jsf/core"
>>>>>>> xmlns:tr="http://myfaces.apache.org/trinidad" >
>>>>>>> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>>>>>>> <f:view>
>>>>>>> <tr:document title="Apache Trinidad Blank Demo">
>>>>>>> <tr:form partialTriggers="sub1:button1 sub2:button1">
>>>>>>> <tr:subform id="sub1">
>>>>>>> <tr:panelPage>
>>>>>>> <tr:outputText value="#{helloWorldBacking.name}" />
>>>>>>> <tr:inputText label="Your name" id="input1"
>>>>>>> value="#{helloWorldBacking.name}" required="true"/>
>>>>>>> <tr:commandButton id="button1" text="press me"
>>>>>>> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>>>>>>> </tr:panelPage>
>>>>>>> </tr:subform>
>>>>>>> <tr:subform id="sub2">
>>>>>>> <tr:panelPage>
>>>>>>> <tr:outputText value="#{helloWorldBacking.name}" />
>>>>>>> <tr:inputText label="Your name" id="input1"
>>>>>>> value="#{helloWorldBacking.name}" required="true"/>
>>>>>>> <tr:commandButton id="button1" text="press me"
>>>>>>> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>>>>>>> </tr:panelPage>
>>>>>>> </tr:subform>
>>>>>>> </tr:form>
>>>>>>> </tr:document>
>>>>>>> </f:view>
>>>>>>> </jsp:root>
>>>>>>>
>>>>>>> 3 - start the application, go to /faces/two_subforms.jspx, add a
>> text
>>>>>>> in
>>>>>>> one of the inputs and click "press me".
>>>>>>>
>>>>>>> This behavior happens with partialSubmit="false" too.
>>>>>>>
>>>>>>> Please confirm if it is a bug (and I file a jira issue) and if it
>> has
>>>>>>> an
>>>>>>> workaround.
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>>
>>>>>>>
>>>>>>> Walter Mourão
>>>>>>> http://waltermourao.com.br
>>>>>>> http://arcadian.com.br
>>>>>>> http://oriens.com.br
>>>>>>>
>>>>>>
>>>>
>>
>>
>> --
>> inexso - information exchange solutions GmbH
>> Bismarckstraße 13 | 26122 Oldenburg
>> Tel.: +49 441 4082 356 |
>> FAX: +49 441 4082 355 | www.inexso.de
>>
Re: [Trinidad] Strange subform behavior
Posted by Walter Mourão <wa...@gmail.com>.
Hi Volker,
I think the question is not if it was submitted or not but if all the
visible references (inputText, outputText or everything else) of a property
instance show its current value when the view is rendered.
Regards,
Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br
On Wed, Sep 10, 2008 at 2:12 PM, Volker Weber <v....@inexso.de> wrote:
> Hi,
>
> why would you expect a not submited subform should loose changes made
> on the client (the submitted value)?
>
> This is exact the behavior i would expect. And BTW how the tobago subform
> works.
>
>
> Regards,
> Volker
>
> 2008/9/10 Andrew Robinson <an...@gmail.com>:
> > Okay, I know the problem:
> >
> > The Subform allows the decode phase of all the children, regardless of
> > what was clicked on. If an event was queued inside of the subform, but
> > not during the apply phase, the form is considered "submitted". Only
> > the submitted form will be validated & updated.
> >
> > Now, UIXInput (and UIInput) render the submitted value as the current
> > value if it is set. Therefore:
> >
> > 1) subform 1 is submitted
> > 2) subform 1 & 2 are decoded, storing the submitted value ("" for the
> > inputText in the 2nd subform)
> > 3) subform 1 is validated
> > 4) subform 1 is updated
> > 5) render subform 1, inputText renders the "value" attribute
> > 6) render subform 2, inputText renders the "submittedValue" attribute
> > (blank string - "")
> >
> > So to me this looks like a design flaw of the subform component. IMO,
> > I would file a bug. Fixing it based on looking at the current design
> > could be a pain in the rear. I wonder how the Tomahawk subform handles
> > the same situation?
> >
> > As a workaround, you would have to find all components under
> > non-submitted subforms that implement EditableValueHolder and set
> > their submitted value to null.
> >
> > -Andrew
> >
> > On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão <wa...@gmail.com>
> wrote:
> >> Actually it looks like the issue isn't related with PPR. I just tested
> >> without PPR (see code below) and had the same result:
> >>
> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
> >> xmlns:f="http://java.sun.com/jsf/core"
> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
> >> <f:view>
> >> <tr:document title="Apache Trinidad Blank Demo">
> >> <tr:form>
> >> <tr:subform id="sub1">
> >> <tr:panelPage>
> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> <tr:inputText label="Your name" id="input1"
> >> value="#{helloWorldBacking.name}" required="true"/>
> >> <tr:commandButton id="button1" text="press me"
> >> action="#{helloWorldBacking.send}"/>
> >> </tr:panelPage>
> >> </tr:subform>
> >> <tr:subform id="sub2">
> >> <tr:panelPage>
> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> <tr:inputText label="Your name" id="input1"
> >> value="#{helloWorldBacking.name}" required="true"/>
> >> <tr:commandButton id="button1" text="press me"
> >> action="#{helloWorldBacking.send}"/>
> >> </tr:panelPage>
> >> </tr:subform>
> >> </tr:form>
> >> </tr:document>
> >> </f:view>
> >> </jsp:root>
> >>
> >>
> >> Walter Mourão
> >> http://waltermourao.com.br
> >> http://arcadian.com.br
> >> http://oriens.com.br
> >>
> >>
> >>
> >> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
> >> <an...@gmail.com> wrote:
> >>>
> >>> Looks like you need to add partialTriggers to the components you want
> >>> to update / refresh
> >>>
> >>> -A
> >>>
> >>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão <
> walter.mourao@gmail.com>
> >>> wrote:
> >>> > Sorry the bump, but I'm in a dead end... Does anybody know a
> workaround
> >>> > ?
> >>> >
> >>> >
> >>> > Walter Mourão
> >>> > http://waltermourao.com.br
> >>> > http://arcadian.com.br
> >>> > http://oriens.com.br
> >>> >
> >>> >
> >>> >
> >>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão <
> walter.mourao@gmail.com>
> >>> > wrote:
> >>> >>
> >>> >> Hi folks,
> >>> >> I'm dealing with a strange behavior when using subforms and I
> >>> >> reproduced
> >>> >> it using the trinidad-blank example (from 1.0.9, but I found the
> >>> >> problem
> >>> >> first with 1.0.5).
> >>> >> When executing an action from subform 1, only the inputs of the
> subform
> >>> >> 1
> >>> >> are refreshed and show the new value. Besides that, when I added a
> >>> >> tr:outputText to the subform, pointing to the same backing bean
> >>> >> property, it
> >>> >> shows the new value, so the tr:inputText and tr:outputText (of the
> >>> >> subform
> >>> >> 2) shows differente values...
> >>> >>
> >>> >> To reproduce using the trinidad-blank example:
> >>> >> 1 - change HelloWorldBacking.send to:
> >>> >> public String send()
> >>> >> {
> >>> >> _name = _name.toUpperCase();
> >>> >>
> >>> >> return null;
> >>> >> }
> >>> >>
> >>> >> 2 - add the file two_subforms.jspx with the content:
> >>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
> >>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
> >>> >> xmlns:f="http://java.sun.com/jsf/core"
> >>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
> >>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
> >>> >> <f:view>
> >>> >> <tr:document title="Apache Trinidad Blank Demo">
> >>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
> >>> >> <tr:subform id="sub1">
> >>> >> <tr:panelPage>
> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >>> >> <tr:inputText label="Your name" id="input1"
> >>> >> value="#{helloWorldBacking.name}" required="true"/>
> >>> >> <tr:commandButton id="button1" text="press me"
> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> >>> >> </tr:panelPage>
> >>> >> </tr:subform>
> >>> >> <tr:subform id="sub2">
> >>> >> <tr:panelPage>
> >>> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >>> >> <tr:inputText label="Your name" id="input1"
> >>> >> value="#{helloWorldBacking.name}" required="true"/>
> >>> >> <tr:commandButton id="button1" text="press me"
> >>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> >>> >> </tr:panelPage>
> >>> >> </tr:subform>
> >>> >> </tr:form>
> >>> >> </tr:document>
> >>> >> </f:view>
> >>> >> </jsp:root>
> >>> >>
> >>> >> 3 - start the application, go to /faces/two_subforms.jspx, add a
> text
> >>> >> in
> >>> >> one of the inputs and click "press me".
> >>> >>
> >>> >> This behavior happens with partialSubmit="false" too.
> >>> >>
> >>> >> Please confirm if it is a bug (and I file a jira issue) and if it
> has
> >>> >> an
> >>> >> workaround.
> >>> >>
> >>> >> Thanks in advance,
> >>> >>
> >>> >>
> >>> >> Walter Mourão
> >>> >> http://waltermourao.com.br
> >>> >> http://arcadian.com.br
> >>> >> http://oriens.com.br
> >>> >>
> >>> >
> >>> >
> >>
> >>
> >
>
>
>
> --
> inexso - information exchange solutions GmbH
> Bismarckstraße 13 | 26122 Oldenburg
> Tel.: +49 441 4082 356 |
> FAX: +49 441 4082 355 | www.inexso.de
>
Re: [Trinidad] Strange subform behavior
Posted by Volker Weber <v....@inexso.de>.
Hi,
why would you expect a not submited subform should loose changes made
on the client (the submitted value)?
This is exact the behavior i would expect. And BTW how the tobago subform works.
Regards,
Volker
2008/9/10 Andrew Robinson <an...@gmail.com>:
> Okay, I know the problem:
>
> The Subform allows the decode phase of all the children, regardless of
> what was clicked on. If an event was queued inside of the subform, but
> not during the apply phase, the form is considered "submitted". Only
> the submitted form will be validated & updated.
>
> Now, UIXInput (and UIInput) render the submitted value as the current
> value if it is set. Therefore:
>
> 1) subform 1 is submitted
> 2) subform 1 & 2 are decoded, storing the submitted value ("" for the
> inputText in the 2nd subform)
> 3) subform 1 is validated
> 4) subform 1 is updated
> 5) render subform 1, inputText renders the "value" attribute
> 6) render subform 2, inputText renders the "submittedValue" attribute
> (blank string - "")
>
> So to me this looks like a design flaw of the subform component. IMO,
> I would file a bug. Fixing it based on looking at the current design
> could be a pain in the rear. I wonder how the Tomahawk subform handles
> the same situation?
>
> As a workaround, you would have to find all components under
> non-submitted subforms that implement EditableValueHolder and set
> their submitted value to null.
>
> -Andrew
>
> On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão <wa...@gmail.com> wrote:
>> Actually it looks like the issue isn't related with PPR. I just tested
>> without PPR (see code below) and had the same result:
>>
>> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>> xmlns:f="http://java.sun.com/jsf/core"
>> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> <f:view>
>> <tr:document title="Apache Trinidad Blank Demo">
>> <tr:form>
>> <tr:subform id="sub1">
>> <tr:panelPage>
>> <tr:outputText value="#{helloWorldBacking.name}" />
>> <tr:inputText label="Your name" id="input1"
>> value="#{helloWorldBacking.name}" required="true"/>
>> <tr:commandButton id="button1" text="press me"
>> action="#{helloWorldBacking.send}"/>
>> </tr:panelPage>
>> </tr:subform>
>> <tr:subform id="sub2">
>> <tr:panelPage>
>> <tr:outputText value="#{helloWorldBacking.name}" />
>> <tr:inputText label="Your name" id="input1"
>> value="#{helloWorldBacking.name}" required="true"/>
>> <tr:commandButton id="button1" text="press me"
>> action="#{helloWorldBacking.send}"/>
>> </tr:panelPage>
>> </tr:subform>
>> </tr:form>
>> </tr:document>
>> </f:view>
>> </jsp:root>
>>
>>
>> Walter Mourão
>> http://waltermourao.com.br
>> http://arcadian.com.br
>> http://oriens.com.br
>>
>>
>>
>> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
>> <an...@gmail.com> wrote:
>>>
>>> Looks like you need to add partialTriggers to the components you want
>>> to update / refresh
>>>
>>> -A
>>>
>>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão <wa...@gmail.com>
>>> wrote:
>>> > Sorry the bump, but I'm in a dead end... Does anybody know a workaround
>>> > ?
>>> >
>>> >
>>> > Walter Mourão
>>> > http://waltermourao.com.br
>>> > http://arcadian.com.br
>>> > http://oriens.com.br
>>> >
>>> >
>>> >
>>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão <wa...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Hi folks,
>>> >> I'm dealing with a strange behavior when using subforms and I
>>> >> reproduced
>>> >> it using the trinidad-blank example (from 1.0.9, but I found the
>>> >> problem
>>> >> first with 1.0.5).
>>> >> When executing an action from subform 1, only the inputs of the subform
>>> >> 1
>>> >> are refreshed and show the new value. Besides that, when I added a
>>> >> tr:outputText to the subform, pointing to the same backing bean
>>> >> property, it
>>> >> shows the new value, so the tr:inputText and tr:outputText (of the
>>> >> subform
>>> >> 2) shows differente values...
>>> >>
>>> >> To reproduce using the trinidad-blank example:
>>> >> 1 - change HelloWorldBacking.send to:
>>> >> public String send()
>>> >> {
>>> >> _name = _name.toUpperCase();
>>> >>
>>> >> return null;
>>> >> }
>>> >>
>>> >> 2 - add the file two_subforms.jspx with the content:
>>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>>> >> xmlns:f="http://java.sun.com/jsf/core"
>>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>>> >> <f:view>
>>> >> <tr:document title="Apache Trinidad Blank Demo">
>>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
>>> >> <tr:subform id="sub1">
>>> >> <tr:panelPage>
>>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>>> >> <tr:inputText label="Your name" id="input1"
>>> >> value="#{helloWorldBacking.name}" required="true"/>
>>> >> <tr:commandButton id="button1" text="press me"
>>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>>> >> </tr:panelPage>
>>> >> </tr:subform>
>>> >> <tr:subform id="sub2">
>>> >> <tr:panelPage>
>>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>>> >> <tr:inputText label="Your name" id="input1"
>>> >> value="#{helloWorldBacking.name}" required="true"/>
>>> >> <tr:commandButton id="button1" text="press me"
>>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>>> >> </tr:panelPage>
>>> >> </tr:subform>
>>> >> </tr:form>
>>> >> </tr:document>
>>> >> </f:view>
>>> >> </jsp:root>
>>> >>
>>> >> 3 - start the application, go to /faces/two_subforms.jspx, add a text
>>> >> in
>>> >> one of the inputs and click "press me".
>>> >>
>>> >> This behavior happens with partialSubmit="false" too.
>>> >>
>>> >> Please confirm if it is a bug (and I file a jira issue) and if it has
>>> >> an
>>> >> workaround.
>>> >>
>>> >> Thanks in advance,
>>> >>
>>> >>
>>> >> Walter Mourão
>>> >> http://waltermourao.com.br
>>> >> http://arcadian.com.br
>>> >> http://oriens.com.br
>>> >>
>>> >
>>> >
>>
>>
>
--
inexso - information exchange solutions GmbH
Bismarckstraße 13 | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX: +49 441 4082 355 | www.inexso.de
Re: [Trinidad] Strange subform behavior
Posted by Andrew Robinson <an...@gmail.com>.
https://issues.apache.org/jira/browse/TRINIDAD-1223
On Wed, Sep 10, 2008 at 11:03 AM, Andrew Robinson
<an...@gmail.com> wrote:
> I'll create the bug...
>
> On Wed, Sep 10, 2008 at 10:41 AM, Andrew Robinson
> <an...@gmail.com> wrote:
>> Okay, I know the problem:
>>
>> The Subform allows the decode phase of all the children, regardless of
>> what was clicked on. If an event was queued inside of the subform, but
>> not during the apply phase, the form is considered "submitted". Only
>> the submitted form will be validated & updated.
>>
>> Now, UIXInput (and UIInput) render the submitted value as the current
>> value if it is set. Therefore:
>>
>> 1) subform 1 is submitted
>> 2) subform 1 & 2 are decoded, storing the submitted value ("" for the
>> inputText in the 2nd subform)
>> 3) subform 1 is validated
>> 4) subform 1 is updated
>> 5) render subform 1, inputText renders the "value" attribute
>> 6) render subform 2, inputText renders the "submittedValue" attribute
>> (blank string - "")
>>
>> So to me this looks like a design flaw of the subform component. IMO,
>> I would file a bug. Fixing it based on looking at the current design
>> could be a pain in the rear. I wonder how the Tomahawk subform handles
>> the same situation?
>>
>> As a workaround, you would have to find all components under
>> non-submitted subforms that implement EditableValueHolder and set
>> their submitted value to null.
>>
>> -Andrew
>>
>> On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão <wa...@gmail.com> wrote:
>>> Actually it looks like the issue isn't related with PPR. I just tested
>>> without PPR (see code below) and had the same result:
>>>
>>> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>>> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>>> xmlns:f="http://java.sun.com/jsf/core"
>>> xmlns:tr="http://myfaces.apache.org/trinidad" >
>>> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>>> <f:view>
>>> <tr:document title="Apache Trinidad Blank Demo">
>>> <tr:form>
>>> <tr:subform id="sub1">
>>> <tr:panelPage>
>>> <tr:outputText value="#{helloWorldBacking.name}" />
>>> <tr:inputText label="Your name" id="input1"
>>> value="#{helloWorldBacking.name}" required="true"/>
>>> <tr:commandButton id="button1" text="press me"
>>> action="#{helloWorldBacking.send}"/>
>>> </tr:panelPage>
>>> </tr:subform>
>>> <tr:subform id="sub2">
>>> <tr:panelPage>
>>> <tr:outputText value="#{helloWorldBacking.name}" />
>>> <tr:inputText label="Your name" id="input1"
>>> value="#{helloWorldBacking.name}" required="true"/>
>>> <tr:commandButton id="button1" text="press me"
>>> action="#{helloWorldBacking.send}"/>
>>> </tr:panelPage>
>>> </tr:subform>
>>> </tr:form>
>>> </tr:document>
>>> </f:view>
>>> </jsp:root>
>>>
>>>
>>> Walter Mourão
>>> http://waltermourao.com.br
>>> http://arcadian.com.br
>>> http://oriens.com.br
>>>
>>>
>>>
>>> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
>>> <an...@gmail.com> wrote:
>>>>
>>>> Looks like you need to add partialTriggers to the components you want
>>>> to update / refresh
>>>>
>>>> -A
>>>>
>>>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão <wa...@gmail.com>
>>>> wrote:
>>>> > Sorry the bump, but I'm in a dead end... Does anybody know a workaround
>>>> > ?
>>>> >
>>>> >
>>>> > Walter Mourão
>>>> > http://waltermourao.com.br
>>>> > http://arcadian.com.br
>>>> > http://oriens.com.br
>>>> >
>>>> >
>>>> >
>>>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão <wa...@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Hi folks,
>>>> >> I'm dealing with a strange behavior when using subforms and I
>>>> >> reproduced
>>>> >> it using the trinidad-blank example (from 1.0.9, but I found the
>>>> >> problem
>>>> >> first with 1.0.5).
>>>> >> When executing an action from subform 1, only the inputs of the subform
>>>> >> 1
>>>> >> are refreshed and show the new value. Besides that, when I added a
>>>> >> tr:outputText to the subform, pointing to the same backing bean
>>>> >> property, it
>>>> >> shows the new value, so the tr:inputText and tr:outputText (of the
>>>> >> subform
>>>> >> 2) shows differente values...
>>>> >>
>>>> >> To reproduce using the trinidad-blank example:
>>>> >> 1 - change HelloWorldBacking.send to:
>>>> >> public String send()
>>>> >> {
>>>> >> _name = _name.toUpperCase();
>>>> >>
>>>> >> return null;
>>>> >> }
>>>> >>
>>>> >> 2 - add the file two_subforms.jspx with the content:
>>>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>>>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>>>> >> xmlns:f="http://java.sun.com/jsf/core"
>>>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>>>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>>>> >> <f:view>
>>>> >> <tr:document title="Apache Trinidad Blank Demo">
>>>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
>>>> >> <tr:subform id="sub1">
>>>> >> <tr:panelPage>
>>>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>>>> >> <tr:inputText label="Your name" id="input1"
>>>> >> value="#{helloWorldBacking.name}" required="true"/>
>>>> >> <tr:commandButton id="button1" text="press me"
>>>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>>>> >> </tr:panelPage>
>>>> >> </tr:subform>
>>>> >> <tr:subform id="sub2">
>>>> >> <tr:panelPage>
>>>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>>>> >> <tr:inputText label="Your name" id="input1"
>>>> >> value="#{helloWorldBacking.name}" required="true"/>
>>>> >> <tr:commandButton id="button1" text="press me"
>>>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>>>> >> </tr:panelPage>
>>>> >> </tr:subform>
>>>> >> </tr:form>
>>>> >> </tr:document>
>>>> >> </f:view>
>>>> >> </jsp:root>
>>>> >>
>>>> >> 3 - start the application, go to /faces/two_subforms.jspx, add a text
>>>> >> in
>>>> >> one of the inputs and click "press me".
>>>> >>
>>>> >> This behavior happens with partialSubmit="false" too.
>>>> >>
>>>> >> Please confirm if it is a bug (and I file a jira issue) and if it has
>>>> >> an
>>>> >> workaround.
>>>> >>
>>>> >> Thanks in advance,
>>>> >>
>>>> >>
>>>> >> Walter Mourão
>>>> >> http://waltermourao.com.br
>>>> >> http://arcadian.com.br
>>>> >> http://oriens.com.br
>>>> >>
>>>> >
>>>> >
>>>
>>>
>>
>
Re: [Trinidad] Strange subform behavior
Posted by Andrew Robinson <an...@gmail.com>.
I'll create the bug...
On Wed, Sep 10, 2008 at 10:41 AM, Andrew Robinson
<an...@gmail.com> wrote:
> Okay, I know the problem:
>
> The Subform allows the decode phase of all the children, regardless of
> what was clicked on. If an event was queued inside of the subform, but
> not during the apply phase, the form is considered "submitted". Only
> the submitted form will be validated & updated.
>
> Now, UIXInput (and UIInput) render the submitted value as the current
> value if it is set. Therefore:
>
> 1) subform 1 is submitted
> 2) subform 1 & 2 are decoded, storing the submitted value ("" for the
> inputText in the 2nd subform)
> 3) subform 1 is validated
> 4) subform 1 is updated
> 5) render subform 1, inputText renders the "value" attribute
> 6) render subform 2, inputText renders the "submittedValue" attribute
> (blank string - "")
>
> So to me this looks like a design flaw of the subform component. IMO,
> I would file a bug. Fixing it based on looking at the current design
> could be a pain in the rear. I wonder how the Tomahawk subform handles
> the same situation?
>
> As a workaround, you would have to find all components under
> non-submitted subforms that implement EditableValueHolder and set
> their submitted value to null.
>
> -Andrew
>
> On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão <wa...@gmail.com> wrote:
>> Actually it looks like the issue isn't related with PPR. I just tested
>> without PPR (see code below) and had the same result:
>>
>> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>> xmlns:f="http://java.sun.com/jsf/core"
>> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> <f:view>
>> <tr:document title="Apache Trinidad Blank Demo">
>> <tr:form>
>> <tr:subform id="sub1">
>> <tr:panelPage>
>> <tr:outputText value="#{helloWorldBacking.name}" />
>> <tr:inputText label="Your name" id="input1"
>> value="#{helloWorldBacking.name}" required="true"/>
>> <tr:commandButton id="button1" text="press me"
>> action="#{helloWorldBacking.send}"/>
>> </tr:panelPage>
>> </tr:subform>
>> <tr:subform id="sub2">
>> <tr:panelPage>
>> <tr:outputText value="#{helloWorldBacking.name}" />
>> <tr:inputText label="Your name" id="input1"
>> value="#{helloWorldBacking.name}" required="true"/>
>> <tr:commandButton id="button1" text="press me"
>> action="#{helloWorldBacking.send}"/>
>> </tr:panelPage>
>> </tr:subform>
>> </tr:form>
>> </tr:document>
>> </f:view>
>> </jsp:root>
>>
>>
>> Walter Mourão
>> http://waltermourao.com.br
>> http://arcadian.com.br
>> http://oriens.com.br
>>
>>
>>
>> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
>> <an...@gmail.com> wrote:
>>>
>>> Looks like you need to add partialTriggers to the components you want
>>> to update / refresh
>>>
>>> -A
>>>
>>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão <wa...@gmail.com>
>>> wrote:
>>> > Sorry the bump, but I'm in a dead end... Does anybody know a workaround
>>> > ?
>>> >
>>> >
>>> > Walter Mourão
>>> > http://waltermourao.com.br
>>> > http://arcadian.com.br
>>> > http://oriens.com.br
>>> >
>>> >
>>> >
>>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão <wa...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Hi folks,
>>> >> I'm dealing with a strange behavior when using subforms and I
>>> >> reproduced
>>> >> it using the trinidad-blank example (from 1.0.9, but I found the
>>> >> problem
>>> >> first with 1.0.5).
>>> >> When executing an action from subform 1, only the inputs of the subform
>>> >> 1
>>> >> are refreshed and show the new value. Besides that, when I added a
>>> >> tr:outputText to the subform, pointing to the same backing bean
>>> >> property, it
>>> >> shows the new value, so the tr:inputText and tr:outputText (of the
>>> >> subform
>>> >> 2) shows differente values...
>>> >>
>>> >> To reproduce using the trinidad-blank example:
>>> >> 1 - change HelloWorldBacking.send to:
>>> >> public String send()
>>> >> {
>>> >> _name = _name.toUpperCase();
>>> >>
>>> >> return null;
>>> >> }
>>> >>
>>> >> 2 - add the file two_subforms.jspx with the content:
>>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>>> >> xmlns:f="http://java.sun.com/jsf/core"
>>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>>> >> <f:view>
>>> >> <tr:document title="Apache Trinidad Blank Demo">
>>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
>>> >> <tr:subform id="sub1">
>>> >> <tr:panelPage>
>>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>>> >> <tr:inputText label="Your name" id="input1"
>>> >> value="#{helloWorldBacking.name}" required="true"/>
>>> >> <tr:commandButton id="button1" text="press me"
>>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>>> >> </tr:panelPage>
>>> >> </tr:subform>
>>> >> <tr:subform id="sub2">
>>> >> <tr:panelPage>
>>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>>> >> <tr:inputText label="Your name" id="input1"
>>> >> value="#{helloWorldBacking.name}" required="true"/>
>>> >> <tr:commandButton id="button1" text="press me"
>>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>>> >> </tr:panelPage>
>>> >> </tr:subform>
>>> >> </tr:form>
>>> >> </tr:document>
>>> >> </f:view>
>>> >> </jsp:root>
>>> >>
>>> >> 3 - start the application, go to /faces/two_subforms.jspx, add a text
>>> >> in
>>> >> one of the inputs and click "press me".
>>> >>
>>> >> This behavior happens with partialSubmit="false" too.
>>> >>
>>> >> Please confirm if it is a bug (and I file a jira issue) and if it has
>>> >> an
>>> >> workaround.
>>> >>
>>> >> Thanks in advance,
>>> >>
>>> >>
>>> >> Walter Mourão
>>> >> http://waltermourao.com.br
>>> >> http://arcadian.com.br
>>> >> http://oriens.com.br
>>> >>
>>> >
>>> >
>>
>>
>
Re: [Trinidad] Strange subform behavior
Posted by Andrew Robinson <an...@gmail.com>.
Okay, I know the problem:
The Subform allows the decode phase of all the children, regardless of
what was clicked on. If an event was queued inside of the subform, but
not during the apply phase, the form is considered "submitted". Only
the submitted form will be validated & updated.
Now, UIXInput (and UIInput) render the submitted value as the current
value if it is set. Therefore:
1) subform 1 is submitted
2) subform 1 & 2 are decoded, storing the submitted value ("" for the
inputText in the 2nd subform)
3) subform 1 is validated
4) subform 1 is updated
5) render subform 1, inputText renders the "value" attribute
6) render subform 2, inputText renders the "submittedValue" attribute
(blank string - "")
So to me this looks like a design flaw of the subform component. IMO,
I would file a bug. Fixing it based on looking at the current design
could be a pain in the rear. I wonder how the Tomahawk subform handles
the same situation?
As a workaround, you would have to find all components under
non-submitted subforms that implement EditableValueHolder and set
their submitted value to null.
-Andrew
On Wed, Sep 10, 2008 at 8:03 AM, Walter Mourão <wa...@gmail.com> wrote:
> Actually it looks like the issue isn't related with PPR. I just tested
> without PPR (see code below) and had the same result:
>
> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:tr="http://myfaces.apache.org/trinidad" >
> <jsp:directive.page contentType="text/html;charset=utf-8"/>
> <f:view>
> <tr:document title="Apache Trinidad Blank Demo">
> <tr:form>
> <tr:subform id="sub1">
> <tr:panelPage>
> <tr:outputText value="#{helloWorldBacking.name}" />
> <tr:inputText label="Your name" id="input1"
> value="#{helloWorldBacking.name}" required="true"/>
> <tr:commandButton id="button1" text="press me"
> action="#{helloWorldBacking.send}"/>
> </tr:panelPage>
> </tr:subform>
> <tr:subform id="sub2">
> <tr:panelPage>
> <tr:outputText value="#{helloWorldBacking.name}" />
> <tr:inputText label="Your name" id="input1"
> value="#{helloWorldBacking.name}" required="true"/>
> <tr:commandButton id="button1" text="press me"
> action="#{helloWorldBacking.send}"/>
> </tr:panelPage>
> </tr:subform>
> </tr:form>
> </tr:document>
> </f:view>
> </jsp:root>
>
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>
>
> On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson
> <an...@gmail.com> wrote:
>>
>> Looks like you need to add partialTriggers to the components you want
>> to update / refresh
>>
>> -A
>>
>> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão <wa...@gmail.com>
>> wrote:
>> > Sorry the bump, but I'm in a dead end... Does anybody know a workaround
>> > ?
>> >
>> >
>> > Walter Mourão
>> > http://waltermourao.com.br
>> > http://arcadian.com.br
>> > http://oriens.com.br
>> >
>> >
>> >
>> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão <wa...@gmail.com>
>> > wrote:
>> >>
>> >> Hi folks,
>> >> I'm dealing with a strange behavior when using subforms and I
>> >> reproduced
>> >> it using the trinidad-blank example (from 1.0.9, but I found the
>> >> problem
>> >> first with 1.0.5).
>> >> When executing an action from subform 1, only the inputs of the subform
>> >> 1
>> >> are refreshed and show the new value. Besides that, when I added a
>> >> tr:outputText to the subform, pointing to the same backing bean
>> >> property, it
>> >> shows the new value, so the tr:inputText and tr:outputText (of the
>> >> subform
>> >> 2) shows differente values...
>> >>
>> >> To reproduce using the trinidad-blank example:
>> >> 1 - change HelloWorldBacking.send to:
>> >> public String send()
>> >> {
>> >> _name = _name.toUpperCase();
>> >>
>> >> return null;
>> >> }
>> >>
>> >> 2 - add the file two_subforms.jspx with the content:
>> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>> >> xmlns:f="http://java.sun.com/jsf/core"
>> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> >> <f:view>
>> >> <tr:document title="Apache Trinidad Blank Demo">
>> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
>> >> <tr:subform id="sub1">
>> >> <tr:panelPage>
>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> <tr:inputText label="Your name" id="input1"
>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> <tr:commandButton id="button1" text="press me"
>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >> </tr:panelPage>
>> >> </tr:subform>
>> >> <tr:subform id="sub2">
>> >> <tr:panelPage>
>> >> <tr:outputText value="#{helloWorldBacking.name}" />
>> >> <tr:inputText label="Your name" id="input1"
>> >> value="#{helloWorldBacking.name}" required="true"/>
>> >> <tr:commandButton id="button1" text="press me"
>> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> >> </tr:panelPage>
>> >> </tr:subform>
>> >> </tr:form>
>> >> </tr:document>
>> >> </f:view>
>> >> </jsp:root>
>> >>
>> >> 3 - start the application, go to /faces/two_subforms.jspx, add a text
>> >> in
>> >> one of the inputs and click "press me".
>> >>
>> >> This behavior happens with partialSubmit="false" too.
>> >>
>> >> Please confirm if it is a bug (and I file a jira issue) and if it has
>> >> an
>> >> workaround.
>> >>
>> >> Thanks in advance,
>> >>
>> >>
>> >> Walter Mourão
>> >> http://waltermourao.com.br
>> >> http://arcadian.com.br
>> >> http://oriens.com.br
>> >>
>> >
>> >
>
>
Re: [Trinidad] Strange subform behavior
Posted by Walter Mourão <wa...@gmail.com>.
Actually it looks like the issue isn't related with PPR. I just tested
without PPR (see code below) and had the same result:
<?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:tr="http://myfaces.apache.org/trinidad" >
<jsp:directive.page contentType="text/html;charset=utf-8"/>
<f:view>
<tr:document title="Apache Trinidad Blank Demo">
<tr:form>
<tr:subform id="sub1">
<tr:panelPage>
<tr:outputText value="#{helloWorldBacking.name}" />
<tr:inputText label="Your name" id="input1"
value="#{helloWorldBacking.name}" required="true"/>
<tr:commandButton id="button1" text="press me"
action="#{helloWorldBacking.send}"/>
</tr:panelPage>
</tr:subform>
<tr:subform id="sub2">
<tr:panelPage>
<tr:outputText value="#{helloWorldBacking.name}" />
<tr:inputText label="Your name" id="input1"
value="#{helloWorldBacking.name}" required="true"/>
<tr:commandButton id="button1" text="press me"
action="#{helloWorldBacking.send}"/>
</tr:panelPage>
</tr:subform>
</tr:form>
</tr:document>
</f:view>
</jsp:root>
Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br
On Wed, Sep 10, 2008 at 10:13 AM, Andrew Robinson <
andrew.rw.robinson@gmail.com> wrote:
> Looks like you need to add partialTriggers to the components you want
> to update / refresh
>
> -A
>
> On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão <wa...@gmail.com>
> wrote:
> > Sorry the bump, but I'm in a dead end... Does anybody know a workaround ?
> >
> >
> > Walter Mourão
> > http://waltermourao.com.br
> > http://arcadian.com.br
> > http://oriens.com.br
> >
> >
> >
> > On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão <wa...@gmail.com>
> > wrote:
> >>
> >> Hi folks,
> >> I'm dealing with a strange behavior when using subforms and I reproduced
> >> it using the trinidad-blank example (from 1.0.9, but I found the problem
> >> first with 1.0.5).
> >> When executing an action from subform 1, only the inputs of the subform
> 1
> >> are refreshed and show the new value. Besides that, when I added a
> >> tr:outputText to the subform, pointing to the same backing bean
> property, it
> >> shows the new value, so the tr:inputText and tr:outputText (of the
> subform
> >> 2) shows differente values...
> >>
> >> To reproduce using the trinidad-blank example:
> >> 1 - change HelloWorldBacking.send to:
> >> public String send()
> >> {
> >> _name = _name.toUpperCase();
> >>
> >> return null;
> >> }
> >>
> >> 2 - add the file two_subforms.jspx with the content:
> >> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
> >> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
> >> xmlns:f="http://java.sun.com/jsf/core"
> >> xmlns:tr="http://myfaces.apache.org/trinidad" >
> >> <jsp:directive.page contentType="text/html;charset=utf-8"/>
> >> <f:view>
> >> <tr:document title="Apache Trinidad Blank Demo">
> >> <tr:form partialTriggers="sub1:button1 sub2:button1">
> >> <tr:subform id="sub1">
> >> <tr:panelPage>
> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> <tr:inputText label="Your name" id="input1"
> >> value="#{helloWorldBacking.name}" required="true"/>
> >> <tr:commandButton id="button1" text="press me"
> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> >> </tr:panelPage>
> >> </tr:subform>
> >> <tr:subform id="sub2">
> >> <tr:panelPage>
> >> <tr:outputText value="#{helloWorldBacking.name}" />
> >> <tr:inputText label="Your name" id="input1"
> >> value="#{helloWorldBacking.name}" required="true"/>
> >> <tr:commandButton id="button1" text="press me"
> >> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> >> </tr:panelPage>
> >> </tr:subform>
> >> </tr:form>
> >> </tr:document>
> >> </f:view>
> >> </jsp:root>
> >>
> >> 3 - start the application, go to /faces/two_subforms.jspx, add a text in
> >> one of the inputs and click "press me".
> >>
> >> This behavior happens with partialSubmit="false" too.
> >>
> >> Please confirm if it is a bug (and I file a jira issue) and if it has an
> >> workaround.
> >>
> >> Thanks in advance,
> >>
> >>
> >> Walter Mourão
> >> http://waltermourao.com.br
> >> http://arcadian.com.br
> >> http://oriens.com.br
> >>
> >
> >
>
Re: [Trinidad] Strange subform behavior
Posted by Andrew Robinson <an...@gmail.com>.
Looks like you need to add partialTriggers to the components you want
to update / refresh
-A
On Wed, Sep 10, 2008 at 4:50 AM, Walter Mourão <wa...@gmail.com> wrote:
> Sorry the bump, but I'm in a dead end... Does anybody know a workaround ?
>
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>
>
> On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão <wa...@gmail.com>
> wrote:
>>
>> Hi folks,
>> I'm dealing with a strange behavior when using subforms and I reproduced
>> it using the trinidad-blank example (from 1.0.9, but I found the problem
>> first with 1.0.5).
>> When executing an action from subform 1, only the inputs of the subform 1
>> are refreshed and show the new value. Besides that, when I added a
>> tr:outputText to the subform, pointing to the same backing bean property, it
>> shows the new value, so the tr:inputText and tr:outputText (of the subform
>> 2) shows differente values...
>>
>> To reproduce using the trinidad-blank example:
>> 1 - change HelloWorldBacking.send to:
>> public String send()
>> {
>> _name = _name.toUpperCase();
>>
>> return null;
>> }
>>
>> 2 - add the file two_subforms.jspx with the content:
>> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
>> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
>> xmlns:f="http://java.sun.com/jsf/core"
>> xmlns:tr="http://myfaces.apache.org/trinidad" >
>> <jsp:directive.page contentType="text/html;charset=utf-8"/>
>> <f:view>
>> <tr:document title="Apache Trinidad Blank Demo">
>> <tr:form partialTriggers="sub1:button1 sub2:button1">
>> <tr:subform id="sub1">
>> <tr:panelPage>
>> <tr:outputText value="#{helloWorldBacking.name}" />
>> <tr:inputText label="Your name" id="input1"
>> value="#{helloWorldBacking.name}" required="true"/>
>> <tr:commandButton id="button1" text="press me"
>> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> </tr:panelPage>
>> </tr:subform>
>> <tr:subform id="sub2">
>> <tr:panelPage>
>> <tr:outputText value="#{helloWorldBacking.name}" />
>> <tr:inputText label="Your name" id="input1"
>> value="#{helloWorldBacking.name}" required="true"/>
>> <tr:commandButton id="button1" text="press me"
>> action="#{helloWorldBacking.send}" partialSubmit="true"/>
>> </tr:panelPage>
>> </tr:subform>
>> </tr:form>
>> </tr:document>
>> </f:view>
>> </jsp:root>
>>
>> 3 - start the application, go to /faces/two_subforms.jspx, add a text in
>> one of the inputs and click "press me".
>>
>> This behavior happens with partialSubmit="false" too.
>>
>> Please confirm if it is a bug (and I file a jira issue) and if it has an
>> workaround.
>>
>> Thanks in advance,
>>
>>
>> Walter Mourão
>> http://waltermourao.com.br
>> http://arcadian.com.br
>> http://oriens.com.br
>>
>
>
Re: [Trinidad] Strange subform behavior
Posted by Walter Mourão <wa...@gmail.com>.
Sorry the bump, but I'm in a dead end... Does anybody know a workaround ?
Walter Mourão
http://waltermourao.com.br
http://arcadian.com.br
http://oriens.com.br
On Sun, Sep 7, 2008 at 8:22 AM, Walter Mourão <wa...@gmail.com>wrote:
> Hi folks,
> I'm dealing with a strange behavior when using subforms and I reproduced it
> using the trinidad-blank example (from 1.0.9, but I found the problem first
> with 1.0.5).
> When executing an action from subform 1, only the inputs of the subform 1
> are refreshed and show the new value. Besides that, when I added a
> tr:outputText to the subform, pointing to the same backing bean property, it
> shows the new value, so the tr:inputText and tr:outputText (of the subform
> 2) shows differente values...
>
> To reproduce using the trinidad-blank example:
> 1 - change HelloWorldBacking.send to:
> public String send()
> {
> _name = _name.toUpperCase();
>
> return null;
> }
>
> 2 - add the file two_subforms.jspx with the content:
> <?xml version="1.0" encoding="iso-8859-1" standalone="yes" ?>
> <jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.0"
> xmlns:f="http://java.sun.com/jsf/core"
> xmlns:tr="http://myfaces.apache.org/trinidad" >
> <jsp:directive.page contentType="text/html;charset=utf-8"/>
> <f:view>
> <tr:document title="Apache Trinidad Blank Demo">
> <tr:form partialTriggers="sub1:button1 sub2:button1">
> <tr:subform id="sub1">
> <tr:panelPage>
> <tr:outputText value="#{helloWorldBacking.name}" />
> <tr:inputText label="Your name" id="input1"
> value="#{helloWorldBacking.name}" required="true"/>
> <tr:commandButton id="button1" text="press me"
> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> </tr:panelPage>
> </tr:subform>
> <tr:subform id="sub2">
> <tr:panelPage>
> <tr:outputText value="#{helloWorldBacking.name}" />
> <tr:inputText label="Your name" id="input1"
> value="#{helloWorldBacking.name}" required="true"/>
> <tr:commandButton id="button1" text="press me"
> action="#{helloWorldBacking.send}" partialSubmit="true"/>
> </tr:panelPage>
> </tr:subform>
> </tr:form>
> </tr:document>
> </f:view>
> </jsp:root>
>
> 3 - start the application, go to /faces/two_subforms.jspx, add a text in
> one of the inputs and click "press me".
>
> This behavior happens with partialSubmit="false" too.
>
> Please confirm if it is a bug (and I file a jira issue) and if it has an
> workaround.
>
> Thanks in advance,
>
>
> Walter Mourão
> http://waltermourao.com.br
> http://arcadian.com.br
> http://oriens.com.br
>
>