HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

I am having some strange navigation problems (once again...) and the 
only clue I have is the warning below.

HtmlRendererUtils - There should always be a submitted value for an 
input if it is rendered, its form is submitted, and it is not disabled 
or read-only.

In Googling the error message, it seems that the problem should be 
related to using Javascript to disable a control which my-faces expects 
to get a value from. The warning goes on to name the component in 
question, but there isn't any Javascript which touches these text areas, 
in fact there isn't any Javascript which disables anything. The 
components which are (in theory) causing the warning are certainly not 
disabled visually and for the most part they all contain text. They also 
happen to be created in Java code, so there is no jsp to post here.

Can anyone give me a more detailed interpretation of what the warning 
means and when it arises?

-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Shane Petroff wrote:
> At the point where the warning is logged, 
> component.getClientId(FacesContext) doesn't return a value contained 
> in the request parameter map. 

I think the warning is a big red herring. I don't even have the capacity 
to change the ClientID, so the fact that there is a mismatch only 
indicates that something has gone wrong earlier. I've tried messing 
around with the page structure a little. I swapped a text field in for 
the text area, but had the same result. I tried removing a set of tabs 
to reduce the overall complexity somewhat, but that had no effect 
either. Something has gone wrong and failed silently long before the 
warning is logged, but at the moment, I don't know how to figure out 
what has died. The most annoying part about this is that I don't have 
effective UI tests, so I also have no idea when this problem was 
introduced...

Shane

>
>>
>> On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> Thanks for the suggestions,
>>>
>>> In reviewing the potential problems you listed below, I'm still 
>>> stuck. I
>>> don't use ajax, so 1) shouldn't be an issue. I don't disable 
>>> anything in
>>> javascript, so 2) shouldn't affect me. I only use a single form with
>>> everything inside it, so 3) shouldn't be an issue either. And I don't
>>> tie any EL to the disabled/rendered properties (only the value is
>>> mutated via EL expression).
>>>
>>> What do you think would be the best way to diagnose what is going 
>>> wrong?
>>> I guess I could attach a PhaseListener and set a breakpoint in there to
>>> try to dissect what JSF thinks is wrong. I'm at a real loss here 
>>> since I
>>> can't see anything wrong and the components which are causing the
>>> problem are used to capture the most important data I deal with. Thanks
>>> for the help
>>>
>>> Shane
>>>
>>>
>>> Andrew Robinson wrote:
>>> > That error occurs if there is no submitted value (I know - obvious
>>> > statement). Several things can cause it though. Here are the ones 
>>> that
>>> > are most common IMO (P -> problem, S->Work-around/Solution)
>>> >
>>> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
>>> > a4j:region around any component with ajaxSingle set to true to make
>>> > sure only that component is decoded and updated
>>> >
>>> > 2) (P) Element is removed from the client DOM or is disabled *and* 
>>> the
>>> > JSF component is not disabled. (S) The client side enabled/rendered
>>> > should map to the server-side enabled/rendered. Therefore, if you are
>>> > disabling/removing components on the client, you need to make sure 
>>> you
>>> > change the value on the server *before* the apply request values 
>>> phase
>>> > (I think that is the correct phase of the error).
>>> >
>>> > 3) (P) Component is not inside of the form that was submitted. 
>>> (S1) Do
>>> > not use multiple forms if doing so, instead use the subForm component
>>> > in the sandbox with one form or use one or multiple forms with
>>> > a4j:region if using A4J. (S2) make sure all components that implement
>>> > EditableValueHolder are placed inside of a UIForm component.
>>> >
>>> > 4) (P) The EL expression tied to the rendered or disabled property of
>>> > the component is not view specific and has been changed by another
>>> > view or is changed before the apply request values phase. (S) Make
>>> > sure the rendered and/or disabled properties of components do not
>>> > change after rendering and before the apply request values.
>>> >
>>> > -Andrew
>>> >
>>> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> >> Mike Kienenberger wrote:
>>> >> > I've also had it happen if the page changes and the facelets 
>>> component
>>> >> > tree (or jsp page) is still cached somewhere.
>>> >> I'm almost completely certain it is not a caching issue (although it
>>> >> would be good to know if one could configure Tomcat not to cache
>>> >> anything, ever...) I've hand nuked caches several times and tried
>>> >> executing on a different machine (Tomcat running on the localhost in
>>> >> both cases).
>>> >>
>>> >> Shane
>>> >> >   Same idea -- the
>>> >> > expected submitted page elements do not match the actual submitted
>>> >> > page elements.
>>> >> >
>>> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> >> >>
>>> >> >> I am having some strange navigation problems (once again...) 
>>> and the
>>> >> >> only clue I have is the warning below.
>>> >> >>
>>> >> >> HtmlRendererUtils - There should always be a submitted value 
>>> for an
>>> >> >> input if it is rendered, its form is submitted, and it is not
>>> >> disabled
>>> >> >> or read-only.
>>> >> >>
>>> >> >> In Googling the error message, it seems that the problem 
>>> should be
>>> >> >> related to using Javascript to disable a control which my-faces
>>> >> expects
>>> >> >> to get a value from. The warning goes on to name the component in
>>> >> >> question, but there isn't any Javascript which touches these text
>>> >> areas,
>>> >> >> in fact there isn't any Javascript which disables anything. The
>>> >> >> components which are (in theory) causing the warning are 
>>> certainly
>>> >> not
>>> >> >> disabled visually and for the most part they all contain text.
>>> >> They also
>>> >> >> happen to be created in Java code, so there is no jsp to post 
>>> here.
>>> >> >>
>>> >> >> Can anyone give me a more detailed interpretation of what the 
>>> warning
>>> >> >> means and when it arises?
>>> >> >>
>>> >> >> --
>>> >> >> Shane
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >> --
>>> >> Shane
>>> >>
>>> >>
>>> >
>>>
>>>
>>> -- 
>>> Shane
>>>
>>>
>>
>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Andrew Robinson wrote:
> I would suggest debugging using an IDE at this point. Check out the
> request header variables and then debug through the decode phase. I'd
> recommend putting a break point on the warning.
At the point where the warning is logged, 
component.getClientId(FacesContext) doesn't return a value contained in 
the request parameter map. While that's good for me to know, I'm 
guessing you guys already knew that :) What could cause the mismatch? 
Thanks in advance.

Shane
>
> On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> Thanks for the suggestions,
>>
>> In reviewing the potential problems you listed below, I'm still stuck. I
>> don't use ajax, so 1) shouldn't be an issue. I don't disable anything in
>> javascript, so 2) shouldn't affect me. I only use a single form with
>> everything inside it, so 3) shouldn't be an issue either. And I don't
>> tie any EL to the disabled/rendered properties (only the value is
>> mutated via EL expression).
>>
>> What do you think would be the best way to diagnose what is going wrong?
>> I guess I could attach a PhaseListener and set a breakpoint in there to
>> try to dissect what JSF thinks is wrong. I'm at a real loss here since I
>> can't see anything wrong and the components which are causing the
>> problem are used to capture the most important data I deal with. Thanks
>> for the help
>>
>> Shane
>>
>>
>> Andrew Robinson wrote:
>> > That error occurs if there is no submitted value (I know - obvious
>> > statement). Several things can cause it though. Here are the ones that
>> > are most common IMO (P -> problem, S->Work-around/Solution)
>> >
>> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
>> > a4j:region around any component with ajaxSingle set to true to make
>> > sure only that component is decoded and updated
>> >
>> > 2) (P) Element is removed from the client DOM or is disabled *and* the
>> > JSF component is not disabled. (S) The client side enabled/rendered
>> > should map to the server-side enabled/rendered. Therefore, if you are
>> > disabling/removing components on the client, you need to make sure you
>> > change the value on the server *before* the apply request values phase
>> > (I think that is the correct phase of the error).
>> >
>> > 3) (P) Component is not inside of the form that was submitted. (S1) Do
>> > not use multiple forms if doing so, instead use the subForm component
>> > in the sandbox with one form or use one or multiple forms with
>> > a4j:region if using A4J. (S2) make sure all components that implement
>> > EditableValueHolder are placed inside of a UIForm component.
>> >
>> > 4) (P) The EL expression tied to the rendered or disabled property of
>> > the component is not view specific and has been changed by another
>> > view or is changed before the apply request values phase. (S) Make
>> > sure the rendered and/or disabled properties of components do not
>> > change after rendering and before the apply request values.
>> >
>> > -Andrew
>> >
>> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> Mike Kienenberger wrote:
>> >> > I've also had it happen if the page changes and the facelets 
>> component
>> >> > tree (or jsp page) is still cached somewhere.
>> >> I'm almost completely certain it is not a caching issue (although it
>> >> would be good to know if one could configure Tomcat not to cache
>> >> anything, ever...) I've hand nuked caches several times and tried
>> >> executing on a different machine (Tomcat running on the localhost in
>> >> both cases).
>> >>
>> >> Shane
>> >> >   Same idea -- the
>> >> > expected submitted page elements do not match the actual submitted
>> >> > page elements.
>> >> >
>> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >>
>> >> >> I am having some strange navigation problems (once again...) 
>> and the
>> >> >> only clue I have is the warning below.
>> >> >>
>> >> >> HtmlRendererUtils - There should always be a submitted value 
>> for an
>> >> >> input if it is rendered, its form is submitted, and it is not
>> >> disabled
>> >> >> or read-only.
>> >> >>
>> >> >> In Googling the error message, it seems that the problem should be
>> >> >> related to using Javascript to disable a control which my-faces
>> >> expects
>> >> >> to get a value from. The warning goes on to name the component in
>> >> >> question, but there isn't any Javascript which touches these text
>> >> areas,
>> >> >> in fact there isn't any Javascript which disables anything. The
>> >> >> components which are (in theory) causing the warning are certainly
>> >> not
>> >> >> disabled visually and for the most part they all contain text.
>> >> They also
>> >> >> happen to be created in Java code, so there is no jsp to post 
>> here.
>> >> >>
>> >> >> Can anyone give me a more detailed interpretation of what the 
>> warning
>> >> >> means and when it arises?
>> >> >>
>> >> >> --
>> >> >> Shane
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> Shane
>> >>
>> >>
>> >
>>
>>
>> -- 
>> Shane
>>
>>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Andrew Robinson <an...@gmail.com>]

I would suggest debugging using an IDE at this point. Check out the
request header variables and then debug through the decode phase. I'd
recommend putting a break point on the warning.

On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> Thanks for the suggestions,
>
> In reviewing the potential problems you listed below, I'm still stuck. I
> don't use ajax, so 1) shouldn't be an issue. I don't disable anything in
> javascript, so 2) shouldn't affect me. I only use a single form with
> everything inside it, so 3) shouldn't be an issue either. And I don't
> tie any EL to the disabled/rendered properties (only the value is
> mutated via EL expression).
>
> What do you think would be the best way to diagnose what is going wrong?
> I guess I could attach a PhaseListener and set a breakpoint in there to
> try to dissect what JSF thinks is wrong. I'm at a real loss here since I
> can't see anything wrong and the components which are causing the
> problem are used to capture the most important data I deal with. Thanks
> for the help
>
> Shane
>
>
> Andrew Robinson wrote:
> > That error occurs if there is no submitted value (I know - obvious
> > statement). Several things can cause it though. Here are the ones that
> > are most common IMO (P -> problem, S->Work-around/Solution)
> >
> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
> > a4j:region around any component with ajaxSingle set to true to make
> > sure only that component is decoded and updated
> >
> > 2) (P) Element is removed from the client DOM or is disabled *and* the
> > JSF component is not disabled. (S) The client side enabled/rendered
> > should map to the server-side enabled/rendered. Therefore, if you are
> > disabling/removing components on the client, you need to make sure you
> > change the value on the server *before* the apply request values phase
> > (I think that is the correct phase of the error).
> >
> > 3) (P) Component is not inside of the form that was submitted. (S1) Do
> > not use multiple forms if doing so, instead use the subForm component
> > in the sandbox with one form or use one or multiple forms with
> > a4j:region if using A4J. (S2) make sure all components that implement
> > EditableValueHolder are placed inside of a UIForm component.
> >
> > 4) (P) The EL expression tied to the rendered or disabled property of
> > the component is not view specific and has been changed by another
> > view or is changed before the apply request values phase. (S) Make
> > sure the rendered and/or disabled properties of components do not
> > change after rendering and before the apply request values.
> >
> > -Andrew
> >
> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> Mike Kienenberger wrote:
> >> > I've also had it happen if the page changes and the facelets component
> >> > tree (or jsp page) is still cached somewhere.
> >> I'm almost completely certain it is not a caching issue (although it
> >> would be good to know if one could configure Tomcat not to cache
> >> anything, ever...) I've hand nuked caches several times and tried
> >> executing on a different machine (Tomcat running on the localhost in
> >> both cases).
> >>
> >> Shane
> >> >   Same idea -- the
> >> > expected submitted page elements do not match the actual submitted
> >> > page elements.
> >> >
> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >>
> >> >> I am having some strange navigation problems (once again...) and the
> >> >> only clue I have is the warning below.
> >> >>
> >> >> HtmlRendererUtils - There should always be a submitted value for an
> >> >> input if it is rendered, its form is submitted, and it is not
> >> disabled
> >> >> or read-only.
> >> >>
> >> >> In Googling the error message, it seems that the problem should be
> >> >> related to using Javascript to disable a control which my-faces
> >> expects
> >> >> to get a value from. The warning goes on to name the component in
> >> >> question, but there isn't any Javascript which touches these text
> >> areas,
> >> >> in fact there isn't any Javascript which disables anything. The
> >> >> components which are (in theory) causing the warning are certainly
> >> not
> >> >> disabled visually and for the most part they all contain text.
> >> They also
> >> >> happen to be created in Java code, so there is no jsp to post here.
> >> >>
> >> >> Can anyone give me a more detailed interpretation of what the warning
> >> >> means and when it arises?
> >> >>
> >> >> --
> >> >> Shane
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Shane
> >>
> >>
> >
>
>
> --
> Shane
>
>

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Shane Petroff wrote:
> Mike Kienenberger wrote:
>> A) First request -- generated html created
>> B) modify form, hit submit.   Form values created.
>> C) second request - component tree restored, form values matched with
>> component tree ids.
>>
>> Please double and triple-check that the form values created in B are
>> different than the names/ids generated in A.   I can think of no
>> reason why this would happen.
>
> You are correct; there is no difference from A to B. Evidently I 
> copied the component names I sent earlier from a page which had been 
> re-rendered. Sorry about that. The component names in the originally 
> generated page source match the names logged by my filter eg:
>
> mainForm:contentPanel_209:contentPanel_314:editableAnecdotalComment548806167 
>

Forgot to point out that when the warning is generated, the clientId 
which cannot be found is:

mainForm:_id6:_id9:editableAnecdotalComment548806167

This value comes from a separate session, so the generated id's won't 
necessarily match, but the point is that the warning is generated for 
the same reason: this clientId doesn't match any request parameters.

Shane

>
> One additional thing that seems odd. When I described the containment 
> previously, I forgot about a couple of layers. The component path that 
> the warning generates doesn't seem to jive with the component name. I 
> don't know if this is an issue at all, but I expected there to be more 
> correspondence. I also didn't expect to see something with a null id 
> in the mix.
>
> 2007-06-11 15:41:57,140 WARN  - There should always be a submitted 
> value ...
> [Class: javax.faces.component.UIViewRoot,ViewId: /pages/reportCard.jsp]
> [Class: javax.faces.component.html.HtmlForm,Id: mainForm]
> [Class: javax.faces.component.html.HtmlPanelGrid,Id: detailPanel]
> [Class: javax.faces.component.html.HtmlPanelGrid,Id: contentPanel]
> [Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: 
> _id0]
> [Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id6]
> [Class: javax.faces.component.html.HtmlPanelGrid,Id: null]
> [Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: 
> _id7]
> [Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id9]
> [Class: javax.faces.component.html.HtmlPanelGrid,Id: 
> anecdotalCommentPanelGrid5488061672]
> [Class: javax.faces.component.html.HtmlInputTextarea,Id: 
> editableAnecdotalComment548806167]
>
>
>>
>> If the difference is not until C, I can think of a possibility.
>>
>> binding="#{reportCardBean.mainPanel}"
>>
>> What scope is reportCardBean?
>
> Request. Since it is so easy to change, I naively tried out a session 
> scoped version, but it had the same problems. It's been request scoped 
> for it's whole life though, including versions that worked (IIRC 
> request scope is recommended).
>
>> If the original component is lost, and you bind it to a new component
>> (probably completely auto-generated, giving the _id* values that we
>> saw before), then this would explain why the submitted form values can
>> no longer be matched up to the newly-created component paths in C.
>
> I'm not sure I follow. Despite my previous misleading mail, subsequent 
> versions of the page (I can't navigate away from it once it's been 
> opened) also have a correspondence between component names and request 
> parameters albeit with generated names like:
>
> mainForm:_id6:_id9:editableAnecdotalComment548806167
>
> The component path though seems very consistent with the previous 
> rendering: (only generated id's differ)
>
> [Class: javax.faces.component.UIViewRoot,ViewId: /pages/reportCard.jsp]
> [Class: javax.faces.component.html.HtmlForm,Id: mainForm]
> [Class: javax.faces.component.html.HtmlPanelGrid,Id: detailPanel]
> [Class: javax.faces.component.html.HtmlPanelGrid,Id: contentPanel]
> [Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: 
> _id51]
> [Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id57]
> [Class: javax.faces.component.html.HtmlPanelGrid,Id: null]
> [Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: 
> _id58]
> [Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id60]
> [Class: javax.faces.component.html.HtmlPanelGrid,Id: 
> anecdotalCommentPanelGrid5488061672]
> [Class: javax.faces.component.html.HtmlInputTextarea,Id: 
> editableAnecdotalComment548806167]
>
> Thanks for sticking with me, I owe you a case of virtual beer!
>
> Shane
>>
>>
>> On 6/11/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> Mike Kienenberger wrote:
>>> > I'm confused.
>>>
>>> That's good, at least I have some company!  :)
>>>
>>> > Clearly, something has changed from the time it was sent to the
>>> > browser (generated html) and the time it was received from the 
>>> browser
>>> > (submitted values).
>>>
>>> That's what seems to be the case.
>>>
>>> > Also, if the generated html has _id30, clearly there is no explicit
>>> > name for contentPanel.
>>> This particular panel is one of the few things named in the jsp
>>>
>>>       <h:panelGrid id="contentPanel" 
>>> binding="#{reportCardBean.mainPanel}"
>>>                    columns="1" border="1" width="100%" cellspacing="0"
>>> styleClass="panel"/>
>>>
>>> (It's name used to be 'mainPanel' to better match the binding, but 
>>> it an
>>> effort to ensure that caching wasn't an issue, I renamed it)
>>>
>>> > a) create a simplified example showing the problem, or
>>>
>>> If only I'd looked into Selenium earlier, I might have become aware of
>>> the time at which the problem was introduced... I only see the issue
>>> once things are large.
>>>
>>> > b) post your page code, the generated html, and the form-value pairs
>>> > submitted afterward.
>>> I don't know how much good the creation code would be, since execution
>>> paths through it all depend on the metadata coming out of the database
>>> (the components added to the page depend on context like the user
>>> viewing the page and the attributes of the person being represented on
>>> the page). I'll send a copy of the generated html shortly (I have reams
>>> of stuff commented out right now to try to isolate the issue).
>>>
>>> Is there any upper limit to the number of components which can reliably
>>> be rendered? One of the things that my users have requested is lots of
>>> contextual information, as a result, this page has grown huge. The
>>> reason I ask is that the discrepancy between id and request params is
>>> not the only problem. I commented out the code which creates the text
>>> areas which the warnings complain about, but my navigation issues were
>>> still not fixed. I can successively comment things out to get back to a
>>> point where navigation functions again, but I haven't yet tracked down
>>> the code which kills things (it seems to be in 2 areas). For now, I'm
>>> working under the rather baseless assumption that the 2 problems are
>>> interrelated.
>>>
>>> Thanks for your efforts so far.
>>>
>>> Shane
>>>
>>> >
>>> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> >> Mike Kienenberger wrote:
>>> >> > So the question is why does _id30 get translated to 
>>> contentPanel_1153
>>> >> > and _id33 get translated to contentPanel_1344 on submit?
>>> >> >
>>> >> That would be the question alright... It seems as though the problem
>>> >> actually happens before/during html generation. On submit, it's too
>>> >> late.
>>> >>
>>> >> > It looks like you've went from automatically generated ids for 
>>> these
>>> >> > components to explicitly-set (plus some random number) ids for 
>>> these
>>> >> > components.
>>> >> The parameter map seems like it is the correct one. The text 
>>> areas in
>>> >> question sit in tabs located on 'mainForm'. Specifically the 
>>> containment
>>> >> looks like:
>>> >>
>>> >> mainForm (explicitly named)
>>> >>     contentPanel (explicitly named)
>>> >>         Tab_1 (generated id)
>>> >>                 Panel_1 (generated id)
>>> >>                     editableAnecdotalComment548806536 (explicitly 
>>> named
>>> >> - the numbers at the end refer to a db id)
>>> >>
>>> >> Shane
>>> >> >
>>> >> >
>>> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> >> >> At the point where the warning is logged,
>>> >> >> component.getClientId(FacesContext) doesn't return a value
>>> >> contained in
>>> >> >> the request parameter map. While that's good for me to know, I'm
>>> >> >> guessing you guys already knew that :) What could cause the 
>>> mismatch?
>>> >> >> Thanks in advance.
>>> >> >
>>> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> >> >> Mike Kienenberger wrote:
>>> >> >> > Another way would be to set a breakpoint somewhere and
>>> >> >> > check what's in the request parameter map for the current 
>>> request.
>>> >> >> OK, what I've done is to add a Servlet Filter to the mix (in
>>> >> looking at
>>> >> >> example code, it seems that the filter may come in handy down the
>>> >> line).
>>> >> >> What I figured was that the filter will get processed early, 
>>> and is
>>> >> >> therefore a good place to set a breakpoint to examine request
>>> >> >> parameters. (Although as I write this I'm wondering about filter
>>> >> >> ordering and the Extensions filter) It seems as though the 
>>> component
>>> >> >> id's do not correspond to the request parameters which make it
>>> >> through
>>> >> >> to the filter. In the generated html I have
>>> >> >>
>>> >> >> id="mainForm:_id30:_id33:editableAnecdotalComment548806536"
>>> >> >>
>>> >> >> and in the request I have
>>> >> >>
>>> >> >> param:
>>> >> >>
>>> >> 
>>> mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536, 
>>>
>>> >>
>>> >> >>
>>> >> >>
>>> >> >> value: [Ljava.lang.String;@1fff293
>>> >> >>
>>> >> >> The "editableAnecdotalComment548806536" portion is the ID that 
>>> I set.
>>> >> >> All of the _idXX components get mapped to different parameter 
>>> names
>>> >> >> (contentPanel happens to be the name I assigned to the main panel
>>> >> on the
>>> >> >> jsp page whose binding attribute I use to build up dynamic 
>>> content).
>>> >> >> Since all component id's get mapped, I don't yet see a problem. I
>>> >> >> haven't tried stepping into anything outside my own code yet, 
>>> but I
>>> >> >> guess that's next on the list.
>>> >> >>
>>> >> >> Shane
>>> >> >>
>>> >> >> > You can save the generated html to a file and manually change
>>> >> the url
>>> >> >> > to something else that will trap and log the values.
>>> >> >> >
>>> >> >> > Lots of different options, but the key is to verify that there
>>> >> is no
>>> >> >> > value being submitted for your component, which is what the 
>>> error
>>> >> >> > message is claming.
>>> >> >> >
>>> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> >> >> >> Mike Kienenberger wrote:
>>> >> >> >>
>>> >> >> >> > If there's no such element, then you need to figure out 
>>> why the
>>> >> >> >> > element wasn't rendered.
>>> >> >> >> I guess I wasn't clear. The components in question are in the
>>> >> >> generated
>>> >> >> >> html. They are enabled and rendered and I can't find anything
>>> >> which
>>> >> >> >> might potentially disable them via javascript. Certainly none
>>> >> of the
>>> >> >> >> javascript that I input will do this and I don't see any in 
>>> the
>>> >> >> >> generated javascript which might either.
>>> >> >> >>
>>> >> >> >> > If so, then you need to figure out why there's no submitted
>>> >> >> value when
>>> >> >> >> > you submit the form -- perhaps submitting the form 
>>> through some
>>> >> >> kind
>>> >> >> >> > of proxy which logs all of the values would help.
>>> >> >> >> OK, can you expand on this a bit? Do you mean some 'off the 
>>> shelf'
>>> >> >> proxy
>>> >> >> >> or something different? This is what I was getting at with the
>>> >> >> >> PhaseListener, if I could see what was actually making it
>>> >> through, I
>>> >> >> >> might be able to make some sense of what's going on.
>>> >> >> >>
>>> >> >> >> Shane
>>> >> >> >>
>>> >> >> >> >
>>> >> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> >> >> >> >> Mike Kienenberger wrote:
>>> >> >> >> >> > Set a breakpoint on the line generating the error.
>>> >> >> >> >> > Your first step is to determine which component value is
>>> >> missing
>>> >> >> >> from
>>> >> >> >> >> > your form submit.
>>> >> >> >> >> According to the warning message, I can see that there are
>>> >> several
>>> >> >> >> text
>>> >> >> >> >> area components which are the problem (I assign the id's
>>> >> myself,
>>> >> >> >> so it
>>> >> >> >> >> is easy to verify which components it is complaining 
>>> about).
>>> >> Most
>>> >> >> >> of the
>>> >> >> >> >> components in this page are generated in java code, and
>>> >> everything
>>> >> >> >> looks
>>> >> >> >> >> fine inside the factory method responsible for creating the
>>> >> text
>>> >> >> >> >> components (isDisabled()==false and isRendered()==true).
>>> >> Visually,
>>> >> >> >> >> immediately preceding an attempt to navigate away from this
>>> >> >> page via
>>> >> >> >> >> CommandLink, the fields in question are rendered and 
>>> enabled.
>>> >> >> After
>>> >> >> >> >> that, I can see my request scoped backing bean get 
>>> created once
>>> >> >> >> the link
>>> >> >> >> >> is clicked, but then the warnings are thrown and no 
>>> navigation
>>> >> >> takes
>>> >> >> >> >> place. In terms of the generated html, it is a 
>>> monsterous form
>>> >> >> with
>>> >> >> >> >> scads of disabled components, so it is not terribly easy to
>>> >> verify
>>> >> >> >> >> anything (my javascript skills suck as well, and that 
>>> doesn't
>>> >> >> help).
>>> >> >> >> >> However, everything which gets disabled is set inside 
>>> the java
>>> >> >> code
>>> >> >> >> >> which generates all of the content for the main panel so 
>>> there
>>> >> >> >> ought not
>>> >> >> >> >> to be any issues with client side disables.
>>> >> >> >> >>
>>> >> >> >> >> > Once you know that, look at the generated html before the
>>> >> submit
>>> >> >> >> and
>>> >> >> >> >> > see if you can determine why the input for that component
>>> >> didn't
>>> >> >> >> >> > submit a value.
>>> >> >> >> >> OK, what do I look for? I know the component id a 
>>> priori, so
>>> >> I can
>>> >> >> >> >> isolate the 3 times which it occurs in the generated 
>>> html. Once
>>> >> >> >> for the
>>> >> >> >> >> component name, once for the id, and once in some 
>>> javascript
>>> >> tied
>>> >> >> >> to a
>>> >> >> >> >> sepeate button which does a spell check on the component in
>>> >> >> question
>>> >> >> >> >> (fwiw, the spell check function does not alter either the
>>> >> >> rendered or
>>> >> >> >> >> disabled state of the component and this issue crops up
>>> >> >> regardless of
>>> >> >> >> >> whether or not the spell check function is actually 
>>> invoked)
>>> >> >> >> >>
>>> >> >> >> >> I don't see anything in the html which suggests a problem,
>>> >> but I'm
>>> >> >> >> not
>>> >> >> >> >> altogether sure what to look for.
>>> >> >> >> >>
>>> >> >> >> >> Shane
>>> >> >> >> >>
>>> >> >> >> >> >
>>> >> >> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> >> >> >> >> >> Thanks for the suggestions,
>>> >> >> >> >> >>
>>> >> >> >> >> >> In reviewing the potential problems you listed below, 
>>> I'm
>>> >> still
>>> >> >> >> >> stuck. I
>>> >> >> >> >> >> don't use ajax, so 1) shouldn't be an issue. I don't 
>>> disable
>>> >> >> >> >> anything in
>>> >> >> >> >> >> javascript, so 2) shouldn't affect me. I only use a
>>> >> single form
>>> >> >> >> with
>>> >> >> >> >> >> everything inside it, so 3) shouldn't be an issue 
>>> either.
>>> >> And I
>>> >> >> >> don't
>>> >> >> >> >> >> tie any EL to the disabled/rendered properties (only the
>>> >> >> value is
>>> >> >> >> >> >> mutated via EL expression).
>>> >> >> >> >> >>
>>> >> >> >> >> >> What do you think would be the best way to diagnose 
>>> what is
>>> >> >> going
>>> >> >> >> >> wrong?
>>> >> >> >> >> >> I guess I could attach a PhaseListener and set a
>>> >> breakpoint in
>>> >> >> >> >> there to
>>> >> >> >> >> >> try to dissect what JSF thinks is wrong. I'm at a 
>>> real loss
>>> >> >> here
>>> >> >> >> >> since I
>>> >> >> >> >> >> can't see anything wrong and the components which are
>>> >> >> causing the
>>> >> >> >> >> >> problem are used to capture the most important data I 
>>> deal
>>> >> >> with.
>>> >> >> >> >> Thanks
>>> >> >> >> >> >> for the help
>>> >> >> >> >> >>
>>> >> >> >> >> >> Shane
>>> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >> >> Andrew Robinson wrote:
>>> >> >> >> >> >> > That error occurs if there is no submitted value (I 
>>> know -
>>> >> >> >> obvious
>>> >> >> >> >> >> > statement). Several things can cause it though. Here
>>> >> are the
>>> >> >> >> >> ones that
>>> >> >> >> >> >> > are most common IMO (P -> problem,
>>> >> S->Work-around/Solution)
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > 1) (P) A4J and the ajaxSingle attribute set to true.
>>> >> (S) Use
>>> >> >> >> >> >> > a4j:region around any component with ajaxSingle set to
>>> >> true
>>> >> >> >> to make
>>> >> >> >> >> >> > sure only that component is decoded and updated
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > 2) (P) Element is removed from the client DOM or is
>>> >> disabled
>>> >> >> >> >> *and* the
>>> >> >> >> >> >> > JSF component is not disabled. (S) The client side
>>> >> >> >> enabled/rendered
>>> >> >> >> >> >> > should map to the server-side enabled/rendered.
>>> >> Therefore, if
>>> >> >> >> >> you are
>>> >> >> >> >> >> > disabling/removing components on the client, you need
>>> >> to make
>>> >> >> >> >> sure you
>>> >> >> >> >> >> > change the value on the server *before* the apply 
>>> request
>>> >> >> values
>>> >> >> >> >> phase
>>> >> >> >> >> >> > (I think that is the correct phase of the error).
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > 3) (P) Component is not inside of the form that was
>>> >> >> submitted.
>>> >> >> >> >> (S1) Do
>>> >> >> >> >> >> > not use multiple forms if doing so, instead use the
>>> >> subForm
>>> >> >> >> >> component
>>> >> >> >> >> >> > in the sandbox with one form or use one or multiple 
>>> forms
>>> >> >> with
>>> >> >> >> >> >> > a4j:region if using A4J. (S2) make sure all components
>>> >> that
>>> >> >> >> >> implement
>>> >> >> >> >> >> > EditableValueHolder are placed inside of a UIForm
>>> >> component.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > 4) (P) The EL expression tied to the rendered or 
>>> disabled
>>> >> >> >> >> property of
>>> >> >> >> >> >> > the component is not view specific and has been 
>>> changed by
>>> >> >> >> another
>>> >> >> >> >> >> > view or is changed before the apply request values
>>> >> phase. (S)
>>> >> >> >> Make
>>> >> >> >> >> >> > sure the rendered and/or disabled properties of
>>> >> components do
>>> >> >> >> not
>>> >> >> >> >> >> > change after rendering and before the apply request
>>> >> values.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > -Andrew
>>> >> >> >> >> >> >
>>> >> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> >> >> >> >> >> >> Mike Kienenberger wrote:
>>> >> >> >> >> >> >> > I've also had it happen if the page changes and the
>>> >> >> facelets
>>> >> >> >> >> >> component
>>> >> >> >> >> >> >> > tree (or jsp page) is still cached somewhere.
>>> >> >> >> >> >> >> I'm almost completely certain it is not a caching 
>>> issue
>>> >> >> >> >> (although it
>>> >> >> >> >> >> >> would be good to know if one could configure Tomcat
>>> >> not to
>>> >> >> >> cache
>>> >> >> >> >> >> >> anything, ever...) I've hand nuked caches several
>>> >> times and
>>> >> >> >> tried
>>> >> >> >> >> >> >> executing on a different machine (Tomcat running 
>>> on the
>>> >> >> >> >> localhost in
>>> >> >> >> >> >> >> both cases).
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> Shane
>>> >> >> >> >> >> >> >   Same idea -- the
>>> >> >> >> >> >> >> > expected submitted page elements do not match the
>>> >> actual
>>> >> >> >> >> submitted
>>> >> >> >> >> >> >> > page elements.
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> I am having some strange navigation problems (once
>>> >> >> again...)
>>> >> >> >> >> >> and the
>>> >> >> >> >> >> >> >> only clue I have is the warning below.
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> HtmlRendererUtils - There should always be a 
>>> submitted
>>> >> >> value
>>> >> >> >> >> >> for an
>>> >> >> >> >> >> >> >> input if it is rendered, its form is submitted, 
>>> and
>>> >> it is
>>> >> >> >> not
>>> >> >> >> >> >> >> disabled
>>> >> >> >> >> >> >> >> or read-only.
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> In Googling the error message, it seems that the
>>> >> problem
>>> >> >> >> >> should be
>>> >> >> >> >> >> >> >> related to using Javascript to disable a 
>>> control which
>>> >> >> >> my-faces
>>> >> >> >> >> >> >> expects
>>> >> >> >> >> >> >> >> to get a value from. The warning goes on to 
>>> name the
>>> >> >> >> >> component in
>>> >> >> >> >> >> >> >> question, but there isn't any Javascript which 
>>> touches
>>> >> >> these
>>> >> >> >> >> text
>>> >> >> >> >> >> >> areas,
>>> >> >> >> >> >> >> >> in fact there isn't any Javascript which disables
>>> >> >> >> anything. The
>>> >> >> >> >> >> >> >> components which are (in theory) causing the
>>> >> warning are
>>> >> >> >> >> certainly
>>> >> >> >> >> >> >> not
>>> >> >> >> >> >> >> >> disabled visually and for the most part they all
>>> >> contain
>>> >> >> >> text.
>>> >> >> >> >> >> >> They also
>>> >> >> >> >> >> >> >> happen to be created in Java code, so there is no
>>> >> jsp to
>>> >> >> >> post
>>> >> >> >> >> >> here.
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> Can anyone give me a more detailed interpretation
>>> >> of what
>>> >> >> >> the
>>> >> >> >> >> >> warning
>>> >> >> >> >> >> >> >> means and when it arises?
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >> --
>>> >> >> >> >> >> >> >> Shane
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >>
>>> >> >> >> >> >> >> >
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> --
>>> >> >> >> >> >> >> Shane
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >
>>> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >> >> --
>>> >> >> >> >> >> Shane
>>> >> >> >> >> >>
>>> >> >> >> >> >>
>>> >> >> >> >> >
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >> --
>>> >> >> >> >> Shane
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> Shane
>>> >> >> >>
>>> >> >> >>
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Shane
>>> >> >>
>>> >> >>
>>> >> >
>>> >>
>>> >>
>>> >> --
>>> >> Shane
>>> >>
>>> >>
>>> >
>>>
>>>
>>> -- 
>>> Shane
>>>
>>>
>>
>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Mike Kienenberger wrote:
> A) First request -- generated html created
> B) modify form, hit submit.   Form values created.
> C) second request - component tree restored, form values matched with
> component tree ids.
>
> Please double and triple-check that the form values created in B are
> different than the names/ids generated in A.   I can think of no
> reason why this would happen.

You are correct; there is no difference from A to B. Evidently I copied 
the component names I sent earlier from a page which had been 
re-rendered. Sorry about that. The component names in the originally 
generated page source match the names logged by my filter eg:

mainForm:contentPanel_209:contentPanel_314:editableAnecdotalComment548806167

One additional thing that seems odd. When I described the containment 
previously, I forgot about a couple of layers. The component path that 
the warning generates doesn't seem to jive with the component name. I 
don't know if this is an issue at all, but I expected there to be more 
correspondence. I also didn't expect to see something with a null id in 
the mix.

2007-06-11 15:41:57,140 WARN  - There should always be a submitted value ...
[Class: javax.faces.component.UIViewRoot,ViewId: /pages/reportCard.jsp]
[Class: javax.faces.component.html.HtmlForm,Id: mainForm]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: detailPanel]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: contentPanel]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: _id0]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id6]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: null]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: _id7]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id9]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: 
anecdotalCommentPanelGrid5488061672]
[Class: javax.faces.component.html.HtmlInputTextarea,Id: 
editableAnecdotalComment548806167]


>
> If the difference is not until C, I can think of a possibility.
>
> binding="#{reportCardBean.mainPanel}"
>
> What scope is reportCardBean?

Request. Since it is so easy to change, I naively tried out a session 
scoped version, but it had the same problems. It's been request scoped 
for it's whole life though, including versions that worked (IIRC request 
scope is recommended).

> If the original component is lost, and you bind it to a new component
> (probably completely auto-generated, giving the _id* values that we
> saw before), then this would explain why the submitted form values can
> no longer be matched up to the newly-created component paths in C.

I'm not sure I follow. Despite my previous misleading mail, subsequent 
versions of the page (I can't navigate away from it once it's been 
opened) also have a correspondence between component names and request 
parameters albeit with generated names like:

mainForm:_id6:_id9:editableAnecdotalComment548806167

The component path though seems very consistent with the previous 
rendering: (only generated id's differ)

[Class: javax.faces.component.UIViewRoot,ViewId: /pages/reportCard.jsp]
[Class: javax.faces.component.html.HtmlForm,Id: mainForm]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: detailPanel]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: contentPanel]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: _id51]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id57]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: null]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTabbedPane,Id: _id58]
[Class: org.apache.myfaces.custom.tabbedpane.HtmlPanelTab,Id: _id60]
[Class: javax.faces.component.html.HtmlPanelGrid,Id: 
anecdotalCommentPanelGrid5488061672]
[Class: javax.faces.component.html.HtmlInputTextarea,Id: 
editableAnecdotalComment548806167]

Thanks for sticking with me, I owe you a case of virtual beer!

Shane
>
>
> On 6/11/07, Shane Petroff <sh...@mayet.ca> wrote:
>> Mike Kienenberger wrote:
>> > I'm confused.
>>
>> That's good, at least I have some company!  :)
>>
>> > Clearly, something has changed from the time it was sent to the
>> > browser (generated html) and the time it was received from the browser
>> > (submitted values).
>>
>> That's what seems to be the case.
>>
>> > Also, if the generated html has _id30, clearly there is no explicit
>> > name for contentPanel.
>> This particular panel is one of the few things named in the jsp
>>
>>       <h:panelGrid id="contentPanel" 
>> binding="#{reportCardBean.mainPanel}"
>>                    columns="1" border="1" width="100%" cellspacing="0"
>> styleClass="panel"/>
>>
>> (It's name used to be 'mainPanel' to better match the binding, but it an
>> effort to ensure that caching wasn't an issue, I renamed it)
>>
>> > a) create a simplified example showing the problem, or
>>
>> If only I'd looked into Selenium earlier, I might have become aware of
>> the time at which the problem was introduced... I only see the issue
>> once things are large.
>>
>> > b) post your page code, the generated html, and the form-value pairs
>> > submitted afterward.
>> I don't know how much good the creation code would be, since execution
>> paths through it all depend on the metadata coming out of the database
>> (the components added to the page depend on context like the user
>> viewing the page and the attributes of the person being represented on
>> the page). I'll send a copy of the generated html shortly (I have reams
>> of stuff commented out right now to try to isolate the issue).
>>
>> Is there any upper limit to the number of components which can reliably
>> be rendered? One of the things that my users have requested is lots of
>> contextual information, as a result, this page has grown huge. The
>> reason I ask is that the discrepancy between id and request params is
>> not the only problem. I commented out the code which creates the text
>> areas which the warnings complain about, but my navigation issues were
>> still not fixed. I can successively comment things out to get back to a
>> point where navigation functions again, but I haven't yet tracked down
>> the code which kills things (it seems to be in 2 areas). For now, I'm
>> working under the rather baseless assumption that the 2 problems are
>> interrelated.
>>
>> Thanks for your efforts so far.
>>
>> Shane
>>
>> >
>> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> Mike Kienenberger wrote:
>> >> > So the question is why does _id30 get translated to 
>> contentPanel_1153
>> >> > and _id33 get translated to contentPanel_1344 on submit?
>> >> >
>> >> That would be the question alright... It seems as though the problem
>> >> actually happens before/during html generation. On submit, it's too
>> >> late.
>> >>
>> >> > It looks like you've went from automatically generated ids for 
>> these
>> >> > components to explicitly-set (plus some random number) ids for 
>> these
>> >> > components.
>> >> The parameter map seems like it is the correct one. The text areas in
>> >> question sit in tabs located on 'mainForm'. Specifically the 
>> containment
>> >> looks like:
>> >>
>> >> mainForm (explicitly named)
>> >>     contentPanel (explicitly named)
>> >>         Tab_1 (generated id)
>> >>                 Panel_1 (generated id)
>> >>                     editableAnecdotalComment548806536 (explicitly 
>> named
>> >> - the numbers at the end refer to a db id)
>> >>
>> >> Shane
>> >> >
>> >> >
>> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> At the point where the warning is logged,
>> >> >> component.getClientId(FacesContext) doesn't return a value
>> >> contained in
>> >> >> the request parameter map. While that's good for me to know, I'm
>> >> >> guessing you guys already knew that :) What could cause the 
>> mismatch?
>> >> >> Thanks in advance.
>> >> >
>> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> Mike Kienenberger wrote:
>> >> >> > Another way would be to set a breakpoint somewhere and
>> >> >> > check what's in the request parameter map for the current 
>> request.
>> >> >> OK, what I've done is to add a Servlet Filter to the mix (in
>> >> looking at
>> >> >> example code, it seems that the filter may come in handy down the
>> >> line).
>> >> >> What I figured was that the filter will get processed early, 
>> and is
>> >> >> therefore a good place to set a breakpoint to examine request
>> >> >> parameters. (Although as I write this I'm wondering about filter
>> >> >> ordering and the Extensions filter) It seems as though the 
>> component
>> >> >> id's do not correspond to the request parameters which make it
>> >> through
>> >> >> to the filter. In the generated html I have
>> >> >>
>> >> >> id="mainForm:_id30:_id33:editableAnecdotalComment548806536"
>> >> >>
>> >> >> and in the request I have
>> >> >>
>> >> >> param:
>> >> >>
>> >> 
>> mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536, 
>>
>> >>
>> >> >>
>> >> >>
>> >> >> value: [Ljava.lang.String;@1fff293
>> >> >>
>> >> >> The "editableAnecdotalComment548806536" portion is the ID that 
>> I set.
>> >> >> All of the _idXX components get mapped to different parameter 
>> names
>> >> >> (contentPanel happens to be the name I assigned to the main panel
>> >> on the
>> >> >> jsp page whose binding attribute I use to build up dynamic 
>> content).
>> >> >> Since all component id's get mapped, I don't yet see a problem. I
>> >> >> haven't tried stepping into anything outside my own code yet, 
>> but I
>> >> >> guess that's next on the list.
>> >> >>
>> >> >> Shane
>> >> >>
>> >> >> > You can save the generated html to a file and manually change
>> >> the url
>> >> >> > to something else that will trap and log the values.
>> >> >> >
>> >> >> > Lots of different options, but the key is to verify that there
>> >> is no
>> >> >> > value being submitted for your component, which is what the 
>> error
>> >> >> > message is claming.
>> >> >> >
>> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> Mike Kienenberger wrote:
>> >> >> >>
>> >> >> >> > If there's no such element, then you need to figure out 
>> why the
>> >> >> >> > element wasn't rendered.
>> >> >> >> I guess I wasn't clear. The components in question are in the
>> >> >> generated
>> >> >> >> html. They are enabled and rendered and I can't find anything
>> >> which
>> >> >> >> might potentially disable them via javascript. Certainly none
>> >> of the
>> >> >> >> javascript that I input will do this and I don't see any in the
>> >> >> >> generated javascript which might either.
>> >> >> >>
>> >> >> >> > If so, then you need to figure out why there's no submitted
>> >> >> value when
>> >> >> >> > you submit the form -- perhaps submitting the form through 
>> some
>> >> >> kind
>> >> >> >> > of proxy which logs all of the values would help.
>> >> >> >> OK, can you expand on this a bit? Do you mean some 'off the 
>> shelf'
>> >> >> proxy
>> >> >> >> or something different? This is what I was getting at with the
>> >> >> >> PhaseListener, if I could see what was actually making it
>> >> through, I
>> >> >> >> might be able to make some sense of what's going on.
>> >> >> >>
>> >> >> >> Shane
>> >> >> >>
>> >> >> >> >
>> >> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> >> Mike Kienenberger wrote:
>> >> >> >> >> > Set a breakpoint on the line generating the error.
>> >> >> >> >> > Your first step is to determine which component value is
>> >> missing
>> >> >> >> from
>> >> >> >> >> > your form submit.
>> >> >> >> >> According to the warning message, I can see that there are
>> >> several
>> >> >> >> text
>> >> >> >> >> area components which are the problem (I assign the id's
>> >> myself,
>> >> >> >> so it
>> >> >> >> >> is easy to verify which components it is complaining about).
>> >> Most
>> >> >> >> of the
>> >> >> >> >> components in this page are generated in java code, and
>> >> everything
>> >> >> >> looks
>> >> >> >> >> fine inside the factory method responsible for creating the
>> >> text
>> >> >> >> >> components (isDisabled()==false and isRendered()==true).
>> >> Visually,
>> >> >> >> >> immediately preceding an attempt to navigate away from this
>> >> >> page via
>> >> >> >> >> CommandLink, the fields in question are rendered and 
>> enabled.
>> >> >> After
>> >> >> >> >> that, I can see my request scoped backing bean get 
>> created once
>> >> >> >> the link
>> >> >> >> >> is clicked, but then the warnings are thrown and no 
>> navigation
>> >> >> takes
>> >> >> >> >> place. In terms of the generated html, it is a monsterous 
>> form
>> >> >> with
>> >> >> >> >> scads of disabled components, so it is not terribly easy to
>> >> verify
>> >> >> >> >> anything (my javascript skills suck as well, and that 
>> doesn't
>> >> >> help).
>> >> >> >> >> However, everything which gets disabled is set inside the 
>> java
>> >> >> code
>> >> >> >> >> which generates all of the content for the main panel so 
>> there
>> >> >> >> ought not
>> >> >> >> >> to be any issues with client side disables.
>> >> >> >> >>
>> >> >> >> >> > Once you know that, look at the generated html before the
>> >> submit
>> >> >> >> and
>> >> >> >> >> > see if you can determine why the input for that component
>> >> didn't
>> >> >> >> >> > submit a value.
>> >> >> >> >> OK, what do I look for? I know the component id a priori, so
>> >> I can
>> >> >> >> >> isolate the 3 times which it occurs in the generated 
>> html. Once
>> >> >> >> for the
>> >> >> >> >> component name, once for the id, and once in some javascript
>> >> tied
>> >> >> >> to a
>> >> >> >> >> sepeate button which does a spell check on the component in
>> >> >> question
>> >> >> >> >> (fwiw, the spell check function does not alter either the
>> >> >> rendered or
>> >> >> >> >> disabled state of the component and this issue crops up
>> >> >> regardless of
>> >> >> >> >> whether or not the spell check function is actually invoked)
>> >> >> >> >>
>> >> >> >> >> I don't see anything in the html which suggests a problem,
>> >> but I'm
>> >> >> >> not
>> >> >> >> >> altogether sure what to look for.
>> >> >> >> >>
>> >> >> >> >> Shane
>> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> >> >> Thanks for the suggestions,
>> >> >> >> >> >>
>> >> >> >> >> >> In reviewing the potential problems you listed below, I'm
>> >> still
>> >> >> >> >> stuck. I
>> >> >> >> >> >> don't use ajax, so 1) shouldn't be an issue. I don't 
>> disable
>> >> >> >> >> anything in
>> >> >> >> >> >> javascript, so 2) shouldn't affect me. I only use a
>> >> single form
>> >> >> >> with
>> >> >> >> >> >> everything inside it, so 3) shouldn't be an issue either.
>> >> And I
>> >> >> >> don't
>> >> >> >> >> >> tie any EL to the disabled/rendered properties (only the
>> >> >> value is
>> >> >> >> >> >> mutated via EL expression).
>> >> >> >> >> >>
>> >> >> >> >> >> What do you think would be the best way to diagnose 
>> what is
>> >> >> going
>> >> >> >> >> wrong?
>> >> >> >> >> >> I guess I could attach a PhaseListener and set a
>> >> breakpoint in
>> >> >> >> >> there to
>> >> >> >> >> >> try to dissect what JSF thinks is wrong. I'm at a real 
>> loss
>> >> >> here
>> >> >> >> >> since I
>> >> >> >> >> >> can't see anything wrong and the components which are
>> >> >> causing the
>> >> >> >> >> >> problem are used to capture the most important data I 
>> deal
>> >> >> with.
>> >> >> >> >> Thanks
>> >> >> >> >> >> for the help
>> >> >> >> >> >>
>> >> >> >> >> >> Shane
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> Andrew Robinson wrote:
>> >> >> >> >> >> > That error occurs if there is no submitted value (I 
>> know -
>> >> >> >> obvious
>> >> >> >> >> >> > statement). Several things can cause it though. Here
>> >> are the
>> >> >> >> >> ones that
>> >> >> >> >> >> > are most common IMO (P -> problem,
>> >> S->Work-around/Solution)
>> >> >> >> >> >> >
>> >> >> >> >> >> > 1) (P) A4J and the ajaxSingle attribute set to true.
>> >> (S) Use
>> >> >> >> >> >> > a4j:region around any component with ajaxSingle set to
>> >> true
>> >> >> >> to make
>> >> >> >> >> >> > sure only that component is decoded and updated
>> >> >> >> >> >> >
>> >> >> >> >> >> > 2) (P) Element is removed from the client DOM or is
>> >> disabled
>> >> >> >> >> *and* the
>> >> >> >> >> >> > JSF component is not disabled. (S) The client side
>> >> >> >> enabled/rendered
>> >> >> >> >> >> > should map to the server-side enabled/rendered.
>> >> Therefore, if
>> >> >> >> >> you are
>> >> >> >> >> >> > disabling/removing components on the client, you need
>> >> to make
>> >> >> >> >> sure you
>> >> >> >> >> >> > change the value on the server *before* the apply 
>> request
>> >> >> values
>> >> >> >> >> phase
>> >> >> >> >> >> > (I think that is the correct phase of the error).
>> >> >> >> >> >> >
>> >> >> >> >> >> > 3) (P) Component is not inside of the form that was
>> >> >> submitted.
>> >> >> >> >> (S1) Do
>> >> >> >> >> >> > not use multiple forms if doing so, instead use the
>> >> subForm
>> >> >> >> >> component
>> >> >> >> >> >> > in the sandbox with one form or use one or multiple 
>> forms
>> >> >> with
>> >> >> >> >> >> > a4j:region if using A4J. (S2) make sure all components
>> >> that
>> >> >> >> >> implement
>> >> >> >> >> >> > EditableValueHolder are placed inside of a UIForm
>> >> component.
>> >> >> >> >> >> >
>> >> >> >> >> >> > 4) (P) The EL expression tied to the rendered or 
>> disabled
>> >> >> >> >> property of
>> >> >> >> >> >> > the component is not view specific and has been 
>> changed by
>> >> >> >> another
>> >> >> >> >> >> > view or is changed before the apply request values
>> >> phase. (S)
>> >> >> >> Make
>> >> >> >> >> >> > sure the rendered and/or disabled properties of
>> >> components do
>> >> >> >> not
>> >> >> >> >> >> > change after rendering and before the apply request
>> >> values.
>> >> >> >> >> >> >
>> >> >> >> >> >> > -Andrew
>> >> >> >> >> >> >
>> >> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> >> >> >> Mike Kienenberger wrote:
>> >> >> >> >> >> >> > I've also had it happen if the page changes and the
>> >> >> facelets
>> >> >> >> >> >> component
>> >> >> >> >> >> >> > tree (or jsp page) is still cached somewhere.
>> >> >> >> >> >> >> I'm almost completely certain it is not a caching 
>> issue
>> >> >> >> >> (although it
>> >> >> >> >> >> >> would be good to know if one could configure Tomcat
>> >> not to
>> >> >> >> cache
>> >> >> >> >> >> >> anything, ever...) I've hand nuked caches several
>> >> times and
>> >> >> >> tried
>> >> >> >> >> >> >> executing on a different machine (Tomcat running on 
>> the
>> >> >> >> >> localhost in
>> >> >> >> >> >> >> both cases).
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Shane
>> >> >> >> >> >> >> >   Same idea -- the
>> >> >> >> >> >> >> > expected submitted page elements do not match the
>> >> actual
>> >> >> >> >> submitted
>> >> >> >> >> >> >> > page elements.
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> I am having some strange navigation problems (once
>> >> >> again...)
>> >> >> >> >> >> and the
>> >> >> >> >> >> >> >> only clue I have is the warning below.
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> HtmlRendererUtils - There should always be a 
>> submitted
>> >> >> value
>> >> >> >> >> >> for an
>> >> >> >> >> >> >> >> input if it is rendered, its form is submitted, and
>> >> it is
>> >> >> >> not
>> >> >> >> >> >> >> disabled
>> >> >> >> >> >> >> >> or read-only.
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> In Googling the error message, it seems that the
>> >> problem
>> >> >> >> >> should be
>> >> >> >> >> >> >> >> related to using Javascript to disable a control 
>> which
>> >> >> >> my-faces
>> >> >> >> >> >> >> expects
>> >> >> >> >> >> >> >> to get a value from. The warning goes on to name 
>> the
>> >> >> >> >> component in
>> >> >> >> >> >> >> >> question, but there isn't any Javascript which 
>> touches
>> >> >> these
>> >> >> >> >> text
>> >> >> >> >> >> >> areas,
>> >> >> >> >> >> >> >> in fact there isn't any Javascript which disables
>> >> >> >> anything. The
>> >> >> >> >> >> >> >> components which are (in theory) causing the
>> >> warning are
>> >> >> >> >> certainly
>> >> >> >> >> >> >> not
>> >> >> >> >> >> >> >> disabled visually and for the most part they all
>> >> contain
>> >> >> >> text.
>> >> >> >> >> >> >> They also
>> >> >> >> >> >> >> >> happen to be created in Java code, so there is no
>> >> jsp to
>> >> >> >> post
>> >> >> >> >> >> here.
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> Can anyone give me a more detailed interpretation
>> >> of what
>> >> >> >> the
>> >> >> >> >> >> warning
>> >> >> >> >> >> >> >> means and when it arises?
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >> --
>> >> >> >> >> >> >> >> Shane
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >>
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> --
>> >> >> >> >> >> >> Shane
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> --
>> >> >> >> >> >> Shane
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> Shane
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Shane
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Shane
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> Shane
>> >>
>> >>
>> >
>>
>>
>> -- 
>> Shane
>>
>>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Shane Petroff wrote:
>
> I actually have 2 classes of problems I can't figure out. The first is 
> the one outlined in this email's subject.... MyFaces will complain 
> about no submitted values. ... With the new UI, every *second* click 
> of the student commandLink works. During the submits where nothing 
> happens, the appropriate backing bean is created, but none of it's 
> methods are called and the page refreshes. 
FWIW, I can eliminate both problems by reverting to old myfaces 
versions. If I back-date to an old tomahawk-1.1.5-SNAPSHOT.jar I can 
eliminate the warnings. If I back-date the core to 
mayfaces-api-1.1.4.jar and mayfaces-impl-1.1.4.jar then the weird 
navigation issues go away too. I'll try to pare the example code down 
further before submitting the bugs.

-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Mike Kienenberger wrote:
>
> binding="#{reportCardBean.mainPanel}"
>
> What scope is reportCardBean?
>
> If the original component is lost, and you bind it to a new component
> (probably completely auto-generated, giving the _id* values that we
> saw before), then this would explain why the submitted form values can
> no longer be matched up to the newly-created component paths in C.
I'm a little confused by this. I was under the impression that one was 
supposed to use request scoped beans when binding to the UI, but you 
seem to be suggesting that this causes the problem.

In any case, to clarify the situation (I hope), I've included a link 
below which points to a zip file containing a stripped down project. 
I've deleted gobs of stuff from there so hopefully the remaining 
classes/files retain some cohesion to an external audience. The zip 
contains java, jsp and config files. In spite of the maven style 
directory structure, I haven't actually migrated yet, so dependencies 
could be a problem. (I'm assuming that most of you will already have 
everything, and including them in the zip would needlessly create a 
larger download). I've also included my Intellij IDEA project files in 
the off chance that someone else uses it. I've mocked out the data 
access layer (no comments on how awful the mocked code is), so it should 
be self contained. I've also included a single Selenium IDE test. It's 
not really a 'test' per se, rather it is a convenient way to navigate to 
the problem page without my having to describe it. Most of the paths 
through this stripped down version are broken, so letting Selenium 
handle the navigation seemed easiest. The test is in src\test\selenium.

I actually have 2 classes of problems I can't figure out. The first is 
the one outlined in this email's subject. If you navigate to the detail 
page via Selenium, then click on one of the other Student command links 
at the left, MyFaces will complain about no submitted values. 
Annoyingly, if you continue selecting different students, the problem 
partially self-corrects in that at least it complains about fewer 
cases... The other problem can be seen by editing application.properties 
and changing the second entry ViewAptitudes to true, then restarting 
Tomcat. This 'enables' some additional gui building code which somehow 
messes with navigating through students via the same command links. With 
the new UI, every *second* click of the student commandLink works. 
During the submits where nothing happens, the appropriate backing bean 
is created, but none of it's methods are called and the page refreshes. 
Any help is greatly appreciated.

http://www.mayet.ca/downloads/


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Mike Kienenberger <mk...@gmail.com>]

A) First request -- generated html created
B) modify form, hit submit.   Form values created.
C) second request - component tree restored, form values matched with
component tree ids.

Please double and triple-check that the form values created in B are
different than the names/ids generated in A.   I can think of no
reason why this would happen.

If the difference is not until C, I can think of a possibility.

binding="#{reportCardBean.mainPanel}"

What scope is reportCardBean?

If the original component is lost, and you bind it to a new component
(probably completely auto-generated, giving the _id* values that we
saw before), then this would explain why the submitted form values can
no longer be matched up to the newly-created component paths in C.


On 6/11/07, Shane Petroff <sh...@mayet.ca> wrote:
> Mike Kienenberger wrote:
> > I'm confused.
>
> That's good, at least I have some company!  :)
>
> > Clearly, something has changed from the time it was sent to the
> > browser (generated html) and the time it was received from the browser
> > (submitted values).
>
> That's what seems to be the case.
>
> > Also, if the generated html has _id30, clearly there is no explicit
> > name for contentPanel.
> This particular panel is one of the few things named in the jsp
>
>       <h:panelGrid id="contentPanel" binding="#{reportCardBean.mainPanel}"
>                    columns="1" border="1" width="100%" cellspacing="0"
> styleClass="panel"/>
>
> (It's name used to be 'mainPanel' to better match the binding, but it an
> effort to ensure that caching wasn't an issue, I renamed it)
>
> > a) create a simplified example showing the problem, or
>
> If only I'd looked into Selenium earlier, I might have become aware of
> the time at which the problem was introduced... I only see the issue
> once things are large.
>
> > b) post your page code, the generated html, and the form-value pairs
> > submitted afterward.
> I don't know how much good the creation code would be, since execution
> paths through it all depend on the metadata coming out of the database
> (the components added to the page depend on context like the user
> viewing the page and the attributes of the person being represented on
> the page). I'll send a copy of the generated html shortly (I have reams
> of stuff commented out right now to try to isolate the issue).
>
> Is there any upper limit to the number of components which can reliably
> be rendered? One of the things that my users have requested is lots of
> contextual information, as a result, this page has grown huge. The
> reason I ask is that the discrepancy between id and request params is
> not the only problem. I commented out the code which creates the text
> areas which the warnings complain about, but my navigation issues were
> still not fixed. I can successively comment things out to get back to a
> point where navigation functions again, but I haven't yet tracked down
> the code which kills things (it seems to be in 2 areas). For now, I'm
> working under the rather baseless assumption that the 2 problems are
> interrelated.
>
> Thanks for your efforts so far.
>
> Shane
>
> >
> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> Mike Kienenberger wrote:
> >> > So the question is why does _id30 get translated to contentPanel_1153
> >> > and _id33 get translated to contentPanel_1344 on submit?
> >> >
> >> That would be the question alright... It seems as though the problem
> >> actually happens before/during html generation. On submit, it's too
> >> late.
> >>
> >> > It looks like you've went from automatically generated ids for these
> >> > components to explicitly-set (plus some random number) ids for these
> >> > components.
> >> The parameter map seems like it is the correct one. The text areas in
> >> question sit in tabs located on 'mainForm'. Specifically the containment
> >> looks like:
> >>
> >> mainForm (explicitly named)
> >>     contentPanel (explicitly named)
> >>         Tab_1 (generated id)
> >>                 Panel_1 (generated id)
> >>                     editableAnecdotalComment548806536 (explicitly named
> >> - the numbers at the end refer to a db id)
> >>
> >> Shane
> >> >
> >> >
> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> At the point where the warning is logged,
> >> >> component.getClientId(FacesContext) doesn't return a value
> >> contained in
> >> >> the request parameter map. While that's good for me to know, I'm
> >> >> guessing you guys already knew that :) What could cause the mismatch?
> >> >> Thanks in advance.
> >> >
> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> Mike Kienenberger wrote:
> >> >> > Another way would be to set a breakpoint somewhere and
> >> >> > check what's in the request parameter map for the current request.
> >> >> OK, what I've done is to add a Servlet Filter to the mix (in
> >> looking at
> >> >> example code, it seems that the filter may come in handy down the
> >> line).
> >> >> What I figured was that the filter will get processed early, and is
> >> >> therefore a good place to set a breakpoint to examine request
> >> >> parameters. (Although as I write this I'm wondering about filter
> >> >> ordering and the Extensions filter) It seems as though the component
> >> >> id's do not correspond to the request parameters which make it
> >> through
> >> >> to the filter. In the generated html I have
> >> >>
> >> >> id="mainForm:_id30:_id33:editableAnecdotalComment548806536"
> >> >>
> >> >> and in the request I have
> >> >>
> >> >> param:
> >> >>
> >> mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536,
> >>
> >> >>
> >> >>
> >> >> value: [Ljava.lang.String;@1fff293
> >> >>
> >> >> The "editableAnecdotalComment548806536" portion is the ID that I set.
> >> >> All of the _idXX components get mapped to different parameter names
> >> >> (contentPanel happens to be the name I assigned to the main panel
> >> on the
> >> >> jsp page whose binding attribute I use to build up dynamic content).
> >> >> Since all component id's get mapped, I don't yet see a problem. I
> >> >> haven't tried stepping into anything outside my own code yet, but I
> >> >> guess that's next on the list.
> >> >>
> >> >> Shane
> >> >>
> >> >> > You can save the generated html to a file and manually change
> >> the url
> >> >> > to something else that will trap and log the values.
> >> >> >
> >> >> > Lots of different options, but the key is to verify that there
> >> is no
> >> >> > value being submitted for your component, which is what the error
> >> >> > message is claming.
> >> >> >
> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> Mike Kienenberger wrote:
> >> >> >>
> >> >> >> > If there's no such element, then you need to figure out why the
> >> >> >> > element wasn't rendered.
> >> >> >> I guess I wasn't clear. The components in question are in the
> >> >> generated
> >> >> >> html. They are enabled and rendered and I can't find anything
> >> which
> >> >> >> might potentially disable them via javascript. Certainly none
> >> of the
> >> >> >> javascript that I input will do this and I don't see any in the
> >> >> >> generated javascript which might either.
> >> >> >>
> >> >> >> > If so, then you need to figure out why there's no submitted
> >> >> value when
> >> >> >> > you submit the form -- perhaps submitting the form through some
> >> >> kind
> >> >> >> > of proxy which logs all of the values would help.
> >> >> >> OK, can you expand on this a bit? Do you mean some 'off the shelf'
> >> >> proxy
> >> >> >> or something different? This is what I was getting at with the
> >> >> >> PhaseListener, if I could see what was actually making it
> >> through, I
> >> >> >> might be able to make some sense of what's going on.
> >> >> >>
> >> >> >> Shane
> >> >> >>
> >> >> >> >
> >> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> >> Mike Kienenberger wrote:
> >> >> >> >> > Set a breakpoint on the line generating the error.
> >> >> >> >> > Your first step is to determine which component value is
> >> missing
> >> >> >> from
> >> >> >> >> > your form submit.
> >> >> >> >> According to the warning message, I can see that there are
> >> several
> >> >> >> text
> >> >> >> >> area components which are the problem (I assign the id's
> >> myself,
> >> >> >> so it
> >> >> >> >> is easy to verify which components it is complaining about).
> >> Most
> >> >> >> of the
> >> >> >> >> components in this page are generated in java code, and
> >> everything
> >> >> >> looks
> >> >> >> >> fine inside the factory method responsible for creating the
> >> text
> >> >> >> >> components (isDisabled()==false and isRendered()==true).
> >> Visually,
> >> >> >> >> immediately preceding an attempt to navigate away from this
> >> >> page via
> >> >> >> >> CommandLink, the fields in question are rendered and enabled.
> >> >> After
> >> >> >> >> that, I can see my request scoped backing bean get created once
> >> >> >> the link
> >> >> >> >> is clicked, but then the warnings are thrown and no navigation
> >> >> takes
> >> >> >> >> place. In terms of the generated html, it is a monsterous form
> >> >> with
> >> >> >> >> scads of disabled components, so it is not terribly easy to
> >> verify
> >> >> >> >> anything (my javascript skills suck as well, and that doesn't
> >> >> help).
> >> >> >> >> However, everything which gets disabled is set inside the java
> >> >> code
> >> >> >> >> which generates all of the content for the main panel so there
> >> >> >> ought not
> >> >> >> >> to be any issues with client side disables.
> >> >> >> >>
> >> >> >> >> > Once you know that, look at the generated html before the
> >> submit
> >> >> >> and
> >> >> >> >> > see if you can determine why the input for that component
> >> didn't
> >> >> >> >> > submit a value.
> >> >> >> >> OK, what do I look for? I know the component id a priori, so
> >> I can
> >> >> >> >> isolate the 3 times which it occurs in the generated html. Once
> >> >> >> for the
> >> >> >> >> component name, once for the id, and once in some javascript
> >> tied
> >> >> >> to a
> >> >> >> >> sepeate button which does a spell check on the component in
> >> >> question
> >> >> >> >> (fwiw, the spell check function does not alter either the
> >> >> rendered or
> >> >> >> >> disabled state of the component and this issue crops up
> >> >> regardless of
> >> >> >> >> whether or not the spell check function is actually invoked)
> >> >> >> >>
> >> >> >> >> I don't see anything in the html which suggests a problem,
> >> but I'm
> >> >> >> not
> >> >> >> >> altogether sure what to look for.
> >> >> >> >>
> >> >> >> >> Shane
> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> >> >> Thanks for the suggestions,
> >> >> >> >> >>
> >> >> >> >> >> In reviewing the potential problems you listed below, I'm
> >> still
> >> >> >> >> stuck. I
> >> >> >> >> >> don't use ajax, so 1) shouldn't be an issue. I don't disable
> >> >> >> >> anything in
> >> >> >> >> >> javascript, so 2) shouldn't affect me. I only use a
> >> single form
> >> >> >> with
> >> >> >> >> >> everything inside it, so 3) shouldn't be an issue either.
> >> And I
> >> >> >> don't
> >> >> >> >> >> tie any EL to the disabled/rendered properties (only the
> >> >> value is
> >> >> >> >> >> mutated via EL expression).
> >> >> >> >> >>
> >> >> >> >> >> What do you think would be the best way to diagnose what is
> >> >> going
> >> >> >> >> wrong?
> >> >> >> >> >> I guess I could attach a PhaseListener and set a
> >> breakpoint in
> >> >> >> >> there to
> >> >> >> >> >> try to dissect what JSF thinks is wrong. I'm at a real loss
> >> >> here
> >> >> >> >> since I
> >> >> >> >> >> can't see anything wrong and the components which are
> >> >> causing the
> >> >> >> >> >> problem are used to capture the most important data I deal
> >> >> with.
> >> >> >> >> Thanks
> >> >> >> >> >> for the help
> >> >> >> >> >>
> >> >> >> >> >> Shane
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> Andrew Robinson wrote:
> >> >> >> >> >> > That error occurs if there is no submitted value (I know -
> >> >> >> obvious
> >> >> >> >> >> > statement). Several things can cause it though. Here
> >> are the
> >> >> >> >> ones that
> >> >> >> >> >> > are most common IMO (P -> problem,
> >> S->Work-around/Solution)
> >> >> >> >> >> >
> >> >> >> >> >> > 1) (P) A4J and the ajaxSingle attribute set to true.
> >> (S) Use
> >> >> >> >> >> > a4j:region around any component with ajaxSingle set to
> >> true
> >> >> >> to make
> >> >> >> >> >> > sure only that component is decoded and updated
> >> >> >> >> >> >
> >> >> >> >> >> > 2) (P) Element is removed from the client DOM or is
> >> disabled
> >> >> >> >> *and* the
> >> >> >> >> >> > JSF component is not disabled. (S) The client side
> >> >> >> enabled/rendered
> >> >> >> >> >> > should map to the server-side enabled/rendered.
> >> Therefore, if
> >> >> >> >> you are
> >> >> >> >> >> > disabling/removing components on the client, you need
> >> to make
> >> >> >> >> sure you
> >> >> >> >> >> > change the value on the server *before* the apply request
> >> >> values
> >> >> >> >> phase
> >> >> >> >> >> > (I think that is the correct phase of the error).
> >> >> >> >> >> >
> >> >> >> >> >> > 3) (P) Component is not inside of the form that was
> >> >> submitted.
> >> >> >> >> (S1) Do
> >> >> >> >> >> > not use multiple forms if doing so, instead use the
> >> subForm
> >> >> >> >> component
> >> >> >> >> >> > in the sandbox with one form or use one or multiple forms
> >> >> with
> >> >> >> >> >> > a4j:region if using A4J. (S2) make sure all components
> >> that
> >> >> >> >> implement
> >> >> >> >> >> > EditableValueHolder are placed inside of a UIForm
> >> component.
> >> >> >> >> >> >
> >> >> >> >> >> > 4) (P) The EL expression tied to the rendered or disabled
> >> >> >> >> property of
> >> >> >> >> >> > the component is not view specific and has been changed by
> >> >> >> another
> >> >> >> >> >> > view or is changed before the apply request values
> >> phase. (S)
> >> >> >> Make
> >> >> >> >> >> > sure the rendered and/or disabled properties of
> >> components do
> >> >> >> not
> >> >> >> >> >> > change after rendering and before the apply request
> >> values.
> >> >> >> >> >> >
> >> >> >> >> >> > -Andrew
> >> >> >> >> >> >
> >> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> >> >> >> Mike Kienenberger wrote:
> >> >> >> >> >> >> > I've also had it happen if the page changes and the
> >> >> facelets
> >> >> >> >> >> component
> >> >> >> >> >> >> > tree (or jsp page) is still cached somewhere.
> >> >> >> >> >> >> I'm almost completely certain it is not a caching issue
> >> >> >> >> (although it
> >> >> >> >> >> >> would be good to know if one could configure Tomcat
> >> not to
> >> >> >> cache
> >> >> >> >> >> >> anything, ever...) I've hand nuked caches several
> >> times and
> >> >> >> tried
> >> >> >> >> >> >> executing on a different machine (Tomcat running on the
> >> >> >> >> localhost in
> >> >> >> >> >> >> both cases).
> >> >> >> >> >> >>
> >> >> >> >> >> >> Shane
> >> >> >> >> >> >> >   Same idea -- the
> >> >> >> >> >> >> > expected submitted page elements do not match the
> >> actual
> >> >> >> >> submitted
> >> >> >> >> >> >> > page elements.
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> I am having some strange navigation problems (once
> >> >> again...)
> >> >> >> >> >> and the
> >> >> >> >> >> >> >> only clue I have is the warning below.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> HtmlRendererUtils - There should always be a submitted
> >> >> value
> >> >> >> >> >> for an
> >> >> >> >> >> >> >> input if it is rendered, its form is submitted, and
> >> it is
> >> >> >> not
> >> >> >> >> >> >> disabled
> >> >> >> >> >> >> >> or read-only.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> In Googling the error message, it seems that the
> >> problem
> >> >> >> >> should be
> >> >> >> >> >> >> >> related to using Javascript to disable a control which
> >> >> >> my-faces
> >> >> >> >> >> >> expects
> >> >> >> >> >> >> >> to get a value from. The warning goes on to name the
> >> >> >> >> component in
> >> >> >> >> >> >> >> question, but there isn't any Javascript which touches
> >> >> these
> >> >> >> >> text
> >> >> >> >> >> >> areas,
> >> >> >> >> >> >> >> in fact there isn't any Javascript which disables
> >> >> >> anything. The
> >> >> >> >> >> >> >> components which are (in theory) causing the
> >> warning are
> >> >> >> >> certainly
> >> >> >> >> >> >> not
> >> >> >> >> >> >> >> disabled visually and for the most part they all
> >> contain
> >> >> >> text.
> >> >> >> >> >> >> They also
> >> >> >> >> >> >> >> happen to be created in Java code, so there is no
> >> jsp to
> >> >> >> post
> >> >> >> >> >> here.
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> Can anyone give me a more detailed interpretation
> >> of what
> >> >> >> the
> >> >> >> >> >> warning
> >> >> >> >> >> >> >> means and when it arises?
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >> --
> >> >> >> >> >> >> >> Shane
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >>
> >> >> >> >> >> >> >
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >> --
> >> >> >> >> >> >> Shane
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> Shane
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Shane
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Shane
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Shane
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Shane
> >>
> >>
> >
>
>
> --
> Shane
>
>

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Mike Kienenberger wrote:
> I'm confused.

That's good, at least I have some company!  :)

> Clearly, something has changed from the time it was sent to the
> browser (generated html) and the time it was received from the browser
> (submitted values).

That's what seems to be the case.

> Also, if the generated html has _id30, clearly there is no explicit
> name for contentPanel.
This particular panel is one of the few things named in the jsp

      <h:panelGrid id="contentPanel" binding="#{reportCardBean.mainPanel}"
                   columns="1" border="1" width="100%" cellspacing="0" 
styleClass="panel"/>

(It's name used to be 'mainPanel' to better match the binding, but it an 
effort to ensure that caching wasn't an issue, I renamed it)

> a) create a simplified example showing the problem, or

If only I'd looked into Selenium earlier, I might have become aware of 
the time at which the problem was introduced... I only see the issue 
once things are large.

> b) post your page code, the generated html, and the form-value pairs
> submitted afterward.
I don't know how much good the creation code would be, since execution 
paths through it all depend on the metadata coming out of the database 
(the components added to the page depend on context like the user 
viewing the page and the attributes of the person being represented on 
the page). I'll send a copy of the generated html shortly (I have reams 
of stuff commented out right now to try to isolate the issue).

Is there any upper limit to the number of components which can reliably 
be rendered? One of the things that my users have requested is lots of 
contextual information, as a result, this page has grown huge. The 
reason I ask is that the discrepancy between id and request params is 
not the only problem. I commented out the code which creates the text 
areas which the warnings complain about, but my navigation issues were 
still not fixed. I can successively comment things out to get back to a 
point where navigation functions again, but I haven't yet tracked down 
the code which kills things (it seems to be in 2 areas). For now, I'm 
working under the rather baseless assumption that the 2 problems are 
interrelated.

Thanks for your efforts so far.

Shane

>
> On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> Mike Kienenberger wrote:
>> > So the question is why does _id30 get translated to contentPanel_1153
>> > and _id33 get translated to contentPanel_1344 on submit?
>> >
>> That would be the question alright... It seems as though the problem
>> actually happens before/during html generation. On submit, it's too 
>> late.
>>
>> > It looks like you've went from automatically generated ids for these
>> > components to explicitly-set (plus some random number) ids for these
>> > components.
>> The parameter map seems like it is the correct one. The text areas in
>> question sit in tabs located on 'mainForm'. Specifically the containment
>> looks like:
>>
>> mainForm (explicitly named)
>>     contentPanel (explicitly named)
>>         Tab_1 (generated id)
>>                 Panel_1 (generated id)
>>                     editableAnecdotalComment548806536 (explicitly named
>> - the numbers at the end refer to a db id)
>>
>> Shane
>> >
>> >
>> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> At the point where the warning is logged,
>> >> component.getClientId(FacesContext) doesn't return a value 
>> contained in
>> >> the request parameter map. While that's good for me to know, I'm
>> >> guessing you guys already knew that :) What could cause the mismatch?
>> >> Thanks in advance.
>> >
>> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> Mike Kienenberger wrote:
>> >> > Another way would be to set a breakpoint somewhere and
>> >> > check what's in the request parameter map for the current request.
>> >> OK, what I've done is to add a Servlet Filter to the mix (in 
>> looking at
>> >> example code, it seems that the filter may come in handy down the 
>> line).
>> >> What I figured was that the filter will get processed early, and is
>> >> therefore a good place to set a breakpoint to examine request
>> >> parameters. (Although as I write this I'm wondering about filter
>> >> ordering and the Extensions filter) It seems as though the component
>> >> id's do not correspond to the request parameters which make it 
>> through
>> >> to the filter. In the generated html I have
>> >>
>> >> id="mainForm:_id30:_id33:editableAnecdotalComment548806536"
>> >>
>> >> and in the request I have
>> >>
>> >> param:
>> >> 
>> mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536, 
>>
>> >>
>> >>
>> >> value: [Ljava.lang.String;@1fff293
>> >>
>> >> The "editableAnecdotalComment548806536" portion is the ID that I set.
>> >> All of the _idXX components get mapped to different parameter names
>> >> (contentPanel happens to be the name I assigned to the main panel 
>> on the
>> >> jsp page whose binding attribute I use to build up dynamic content).
>> >> Since all component id's get mapped, I don't yet see a problem. I
>> >> haven't tried stepping into anything outside my own code yet, but I
>> >> guess that's next on the list.
>> >>
>> >> Shane
>> >>
>> >> > You can save the generated html to a file and manually change 
>> the url
>> >> > to something else that will trap and log the values.
>> >> >
>> >> > Lots of different options, but the key is to verify that there 
>> is no
>> >> > value being submitted for your component, which is what the error
>> >> > message is claming.
>> >> >
>> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> Mike Kienenberger wrote:
>> >> >>
>> >> >> > If there's no such element, then you need to figure out why the
>> >> >> > element wasn't rendered.
>> >> >> I guess I wasn't clear. The components in question are in the
>> >> generated
>> >> >> html. They are enabled and rendered and I can't find anything 
>> which
>> >> >> might potentially disable them via javascript. Certainly none 
>> of the
>> >> >> javascript that I input will do this and I don't see any in the
>> >> >> generated javascript which might either.
>> >> >>
>> >> >> > If so, then you need to figure out why there's no submitted
>> >> value when
>> >> >> > you submit the form -- perhaps submitting the form through some
>> >> kind
>> >> >> > of proxy which logs all of the values would help.
>> >> >> OK, can you expand on this a bit? Do you mean some 'off the shelf'
>> >> proxy
>> >> >> or something different? This is what I was getting at with the
>> >> >> PhaseListener, if I could see what was actually making it 
>> through, I
>> >> >> might be able to make some sense of what's going on.
>> >> >>
>> >> >> Shane
>> >> >>
>> >> >> >
>> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> Mike Kienenberger wrote:
>> >> >> >> > Set a breakpoint on the line generating the error.
>> >> >> >> > Your first step is to determine which component value is 
>> missing
>> >> >> from
>> >> >> >> > your form submit.
>> >> >> >> According to the warning message, I can see that there are 
>> several
>> >> >> text
>> >> >> >> area components which are the problem (I assign the id's 
>> myself,
>> >> >> so it
>> >> >> >> is easy to verify which components it is complaining about). 
>> Most
>> >> >> of the
>> >> >> >> components in this page are generated in java code, and 
>> everything
>> >> >> looks
>> >> >> >> fine inside the factory method responsible for creating the 
>> text
>> >> >> >> components (isDisabled()==false and isRendered()==true). 
>> Visually,
>> >> >> >> immediately preceding an attempt to navigate away from this
>> >> page via
>> >> >> >> CommandLink, the fields in question are rendered and enabled.
>> >> After
>> >> >> >> that, I can see my request scoped backing bean get created once
>> >> >> the link
>> >> >> >> is clicked, but then the warnings are thrown and no navigation
>> >> takes
>> >> >> >> place. In terms of the generated html, it is a monsterous form
>> >> with
>> >> >> >> scads of disabled components, so it is not terribly easy to 
>> verify
>> >> >> >> anything (my javascript skills suck as well, and that doesn't
>> >> help).
>> >> >> >> However, everything which gets disabled is set inside the java
>> >> code
>> >> >> >> which generates all of the content for the main panel so there
>> >> >> ought not
>> >> >> >> to be any issues with client side disables.
>> >> >> >>
>> >> >> >> > Once you know that, look at the generated html before the 
>> submit
>> >> >> and
>> >> >> >> > see if you can determine why the input for that component 
>> didn't
>> >> >> >> > submit a value.
>> >> >> >> OK, what do I look for? I know the component id a priori, so 
>> I can
>> >> >> >> isolate the 3 times which it occurs in the generated html. Once
>> >> >> for the
>> >> >> >> component name, once for the id, and once in some javascript 
>> tied
>> >> >> to a
>> >> >> >> sepeate button which does a spell check on the component in
>> >> question
>> >> >> >> (fwiw, the spell check function does not alter either the
>> >> rendered or
>> >> >> >> disabled state of the component and this issue crops up
>> >> regardless of
>> >> >> >> whether or not the spell check function is actually invoked)
>> >> >> >>
>> >> >> >> I don't see anything in the html which suggests a problem, 
>> but I'm
>> >> >> not
>> >> >> >> altogether sure what to look for.
>> >> >> >>
>> >> >> >> Shane
>> >> >> >>
>> >> >> >> >
>> >> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> >> Thanks for the suggestions,
>> >> >> >> >>
>> >> >> >> >> In reviewing the potential problems you listed below, I'm 
>> still
>> >> >> >> stuck. I
>> >> >> >> >> don't use ajax, so 1) shouldn't be an issue. I don't disable
>> >> >> >> anything in
>> >> >> >> >> javascript, so 2) shouldn't affect me. I only use a 
>> single form
>> >> >> with
>> >> >> >> >> everything inside it, so 3) shouldn't be an issue either. 
>> And I
>> >> >> don't
>> >> >> >> >> tie any EL to the disabled/rendered properties (only the
>> >> value is
>> >> >> >> >> mutated via EL expression).
>> >> >> >> >>
>> >> >> >> >> What do you think would be the best way to diagnose what is
>> >> going
>> >> >> >> wrong?
>> >> >> >> >> I guess I could attach a PhaseListener and set a 
>> breakpoint in
>> >> >> >> there to
>> >> >> >> >> try to dissect what JSF thinks is wrong. I'm at a real loss
>> >> here
>> >> >> >> since I
>> >> >> >> >> can't see anything wrong and the components which are
>> >> causing the
>> >> >> >> >> problem are used to capture the most important data I deal
>> >> with.
>> >> >> >> Thanks
>> >> >> >> >> for the help
>> >> >> >> >>
>> >> >> >> >> Shane
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> Andrew Robinson wrote:
>> >> >> >> >> > That error occurs if there is no submitted value (I know -
>> >> >> obvious
>> >> >> >> >> > statement). Several things can cause it though. Here 
>> are the
>> >> >> >> ones that
>> >> >> >> >> > are most common IMO (P -> problem, 
>> S->Work-around/Solution)
>> >> >> >> >> >
>> >> >> >> >> > 1) (P) A4J and the ajaxSingle attribute set to true. 
>> (S) Use
>> >> >> >> >> > a4j:region around any component with ajaxSingle set to 
>> true
>> >> >> to make
>> >> >> >> >> > sure only that component is decoded and updated
>> >> >> >> >> >
>> >> >> >> >> > 2) (P) Element is removed from the client DOM or is 
>> disabled
>> >> >> >> *and* the
>> >> >> >> >> > JSF component is not disabled. (S) The client side
>> >> >> enabled/rendered
>> >> >> >> >> > should map to the server-side enabled/rendered. 
>> Therefore, if
>> >> >> >> you are
>> >> >> >> >> > disabling/removing components on the client, you need 
>> to make
>> >> >> >> sure you
>> >> >> >> >> > change the value on the server *before* the apply request
>> >> values
>> >> >> >> phase
>> >> >> >> >> > (I think that is the correct phase of the error).
>> >> >> >> >> >
>> >> >> >> >> > 3) (P) Component is not inside of the form that was
>> >> submitted.
>> >> >> >> (S1) Do
>> >> >> >> >> > not use multiple forms if doing so, instead use the 
>> subForm
>> >> >> >> component
>> >> >> >> >> > in the sandbox with one form or use one or multiple forms
>> >> with
>> >> >> >> >> > a4j:region if using A4J. (S2) make sure all components 
>> that
>> >> >> >> implement
>> >> >> >> >> > EditableValueHolder are placed inside of a UIForm 
>> component.
>> >> >> >> >> >
>> >> >> >> >> > 4) (P) The EL expression tied to the rendered or disabled
>> >> >> >> property of
>> >> >> >> >> > the component is not view specific and has been changed by
>> >> >> another
>> >> >> >> >> > view or is changed before the apply request values 
>> phase. (S)
>> >> >> Make
>> >> >> >> >> > sure the rendered and/or disabled properties of 
>> components do
>> >> >> not
>> >> >> >> >> > change after rendering and before the apply request 
>> values.
>> >> >> >> >> >
>> >> >> >> >> > -Andrew
>> >> >> >> >> >
>> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> >> >> Mike Kienenberger wrote:
>> >> >> >> >> >> > I've also had it happen if the page changes and the
>> >> facelets
>> >> >> >> >> component
>> >> >> >> >> >> > tree (or jsp page) is still cached somewhere.
>> >> >> >> >> >> I'm almost completely certain it is not a caching issue
>> >> >> >> (although it
>> >> >> >> >> >> would be good to know if one could configure Tomcat 
>> not to
>> >> >> cache
>> >> >> >> >> >> anything, ever...) I've hand nuked caches several 
>> times and
>> >> >> tried
>> >> >> >> >> >> executing on a different machine (Tomcat running on the
>> >> >> >> localhost in
>> >> >> >> >> >> both cases).
>> >> >> >> >> >>
>> >> >> >> >> >> Shane
>> >> >> >> >> >> >   Same idea -- the
>> >> >> >> >> >> > expected submitted page elements do not match the 
>> actual
>> >> >> >> submitted
>> >> >> >> >> >> > page elements.
>> >> >> >> >> >> >
>> >> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> I am having some strange navigation problems (once
>> >> again...)
>> >> >> >> >> and the
>> >> >> >> >> >> >> only clue I have is the warning below.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> HtmlRendererUtils - There should always be a submitted
>> >> value
>> >> >> >> >> for an
>> >> >> >> >> >> >> input if it is rendered, its form is submitted, and 
>> it is
>> >> >> not
>> >> >> >> >> >> disabled
>> >> >> >> >> >> >> or read-only.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> In Googling the error message, it seems that the 
>> problem
>> >> >> >> should be
>> >> >> >> >> >> >> related to using Javascript to disable a control which
>> >> >> my-faces
>> >> >> >> >> >> expects
>> >> >> >> >> >> >> to get a value from. The warning goes on to name the
>> >> >> >> component in
>> >> >> >> >> >> >> question, but there isn't any Javascript which touches
>> >> these
>> >> >> >> text
>> >> >> >> >> >> areas,
>> >> >> >> >> >> >> in fact there isn't any Javascript which disables
>> >> >> anything. The
>> >> >> >> >> >> >> components which are (in theory) causing the 
>> warning are
>> >> >> >> certainly
>> >> >> >> >> >> not
>> >> >> >> >> >> >> disabled visually and for the most part they all 
>> contain
>> >> >> text.
>> >> >> >> >> >> They also
>> >> >> >> >> >> >> happen to be created in Java code, so there is no 
>> jsp to
>> >> >> post
>> >> >> >> >> here.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> Can anyone give me a more detailed interpretation 
>> of what
>> >> >> the
>> >> >> >> >> warning
>> >> >> >> >> >> >> means and when it arises?
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> --
>> >> >> >> >> >> >> Shane
>> >> >> >> >> >> >>
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >> --
>> >> >> >> >> >> Shane
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> Shane
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Shane
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Shane
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> Shane
>> >>
>> >>
>> >
>>
>>
>> -- 
>> Shane
>>
>>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Mike Kienenberger <mk...@gmail.com>]

I'm confused.

You said the generated html has this:

id="mainForm:_id30:_id33:editableAnecdotalComment548806536"

And the name value pairs submitted has this:

mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536,


Clearly, something has changed from the time it was sent to the
browser (generated html) and the time it was received from the browser
(submitted values).

Also, if the generated html has _id30, clearly there is no explicit
name for contentPanel.

Are you sure you're looking at the generated html from BEFORE the submit?

I think the only way you'll be able to get further help on this is to

a) create a simplified example showing the problem, or
b) post your page code, the generated html, and the form-value pairs
submitted afterward.

On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> Mike Kienenberger wrote:
> > So the question is why does _id30 get translated to contentPanel_1153
> > and _id33 get translated to contentPanel_1344 on submit?
> >
> That would be the question alright... It seems as though the problem
> actually happens before/during html generation. On submit, it's too late.
>
> > It looks like you've went from automatically generated ids for these
> > components to explicitly-set (plus some random number) ids for these
> > components.
> The parameter map seems like it is the correct one. The text areas in
> question sit in tabs located on 'mainForm'. Specifically the containment
> looks like:
>
> mainForm (explicitly named)
>     contentPanel (explicitly named)
>         Tab_1 (generated id)
>                 Panel_1 (generated id)
>                     editableAnecdotalComment548806536 (explicitly named
> - the numbers at the end refer to a db id)
>
> Shane
> >
> >
> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> At the point where the warning is logged,
> >> component.getClientId(FacesContext) doesn't return a value contained in
> >> the request parameter map. While that's good for me to know, I'm
> >> guessing you guys already knew that :) What could cause the mismatch?
> >> Thanks in advance.
> >
> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> Mike Kienenberger wrote:
> >> > Another way would be to set a breakpoint somewhere and
> >> > check what's in the request parameter map for the current request.
> >> OK, what I've done is to add a Servlet Filter to the mix (in looking at
> >> example code, it seems that the filter may come in handy down the line).
> >> What I figured was that the filter will get processed early, and is
> >> therefore a good place to set a breakpoint to examine request
> >> parameters. (Although as I write this I'm wondering about filter
> >> ordering and the Extensions filter) It seems as though the component
> >> id's do not correspond to the request parameters which make it through
> >> to the filter. In the generated html I have
> >>
> >> id="mainForm:_id30:_id33:editableAnecdotalComment548806536"
> >>
> >> and in the request I have
> >>
> >> param:
> >> mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536,
> >>
> >>
> >> value: [Ljava.lang.String;@1fff293
> >>
> >> The "editableAnecdotalComment548806536" portion is the ID that I set.
> >> All of the _idXX components get mapped to different parameter names
> >> (contentPanel happens to be the name I assigned to the main panel on the
> >> jsp page whose binding attribute I use to build up dynamic content).
> >> Since all component id's get mapped, I don't yet see a problem. I
> >> haven't tried stepping into anything outside my own code yet, but I
> >> guess that's next on the list.
> >>
> >> Shane
> >>
> >> > You can save the generated html to a file and manually change the url
> >> > to something else that will trap and log the values.
> >> >
> >> > Lots of different options, but the key is to verify that there is no
> >> > value being submitted for your component, which is what the error
> >> > message is claming.
> >> >
> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> Mike Kienenberger wrote:
> >> >>
> >> >> > If there's no such element, then you need to figure out why the
> >> >> > element wasn't rendered.
> >> >> I guess I wasn't clear. The components in question are in the
> >> generated
> >> >> html. They are enabled and rendered and I can't find anything which
> >> >> might potentially disable them via javascript. Certainly none of the
> >> >> javascript that I input will do this and I don't see any in the
> >> >> generated javascript which might either.
> >> >>
> >> >> > If so, then you need to figure out why there's no submitted
> >> value when
> >> >> > you submit the form -- perhaps submitting the form through some
> >> kind
> >> >> > of proxy which logs all of the values would help.
> >> >> OK, can you expand on this a bit? Do you mean some 'off the shelf'
> >> proxy
> >> >> or something different? This is what I was getting at with the
> >> >> PhaseListener, if I could see what was actually making it through, I
> >> >> might be able to make some sense of what's going on.
> >> >>
> >> >> Shane
> >> >>
> >> >> >
> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> Mike Kienenberger wrote:
> >> >> >> > Set a breakpoint on the line generating the error.
> >> >> >> > Your first step is to determine which component value is missing
> >> >> from
> >> >> >> > your form submit.
> >> >> >> According to the warning message, I can see that there are several
> >> >> text
> >> >> >> area components which are the problem (I assign the id's myself,
> >> >> so it
> >> >> >> is easy to verify which components it is complaining about). Most
> >> >> of the
> >> >> >> components in this page are generated in java code, and everything
> >> >> looks
> >> >> >> fine inside the factory method responsible for creating the text
> >> >> >> components (isDisabled()==false and isRendered()==true). Visually,
> >> >> >> immediately preceding an attempt to navigate away from this
> >> page via
> >> >> >> CommandLink, the fields in question are rendered and enabled.
> >> After
> >> >> >> that, I can see my request scoped backing bean get created once
> >> >> the link
> >> >> >> is clicked, but then the warnings are thrown and no navigation
> >> takes
> >> >> >> place. In terms of the generated html, it is a monsterous form
> >> with
> >> >> >> scads of disabled components, so it is not terribly easy to verify
> >> >> >> anything (my javascript skills suck as well, and that doesn't
> >> help).
> >> >> >> However, everything which gets disabled is set inside the java
> >> code
> >> >> >> which generates all of the content for the main panel so there
> >> >> ought not
> >> >> >> to be any issues with client side disables.
> >> >> >>
> >> >> >> > Once you know that, look at the generated html before the submit
> >> >> and
> >> >> >> > see if you can determine why the input for that component didn't
> >> >> >> > submit a value.
> >> >> >> OK, what do I look for? I know the component id a priori, so I can
> >> >> >> isolate the 3 times which it occurs in the generated html. Once
> >> >> for the
> >> >> >> component name, once for the id, and once in some javascript tied
> >> >> to a
> >> >> >> sepeate button which does a spell check on the component in
> >> question
> >> >> >> (fwiw, the spell check function does not alter either the
> >> rendered or
> >> >> >> disabled state of the component and this issue crops up
> >> regardless of
> >> >> >> whether or not the spell check function is actually invoked)
> >> >> >>
> >> >> >> I don't see anything in the html which suggests a problem, but I'm
> >> >> not
> >> >> >> altogether sure what to look for.
> >> >> >>
> >> >> >> Shane
> >> >> >>
> >> >> >> >
> >> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> >> Thanks for the suggestions,
> >> >> >> >>
> >> >> >> >> In reviewing the potential problems you listed below, I'm still
> >> >> >> stuck. I
> >> >> >> >> don't use ajax, so 1) shouldn't be an issue. I don't disable
> >> >> >> anything in
> >> >> >> >> javascript, so 2) shouldn't affect me. I only use a single form
> >> >> with
> >> >> >> >> everything inside it, so 3) shouldn't be an issue either. And I
> >> >> don't
> >> >> >> >> tie any EL to the disabled/rendered properties (only the
> >> value is
> >> >> >> >> mutated via EL expression).
> >> >> >> >>
> >> >> >> >> What do you think would be the best way to diagnose what is
> >> going
> >> >> >> wrong?
> >> >> >> >> I guess I could attach a PhaseListener and set a breakpoint in
> >> >> >> there to
> >> >> >> >> try to dissect what JSF thinks is wrong. I'm at a real loss
> >> here
> >> >> >> since I
> >> >> >> >> can't see anything wrong and the components which are
> >> causing the
> >> >> >> >> problem are used to capture the most important data I deal
> >> with.
> >> >> >> Thanks
> >> >> >> >> for the help
> >> >> >> >>
> >> >> >> >> Shane
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> Andrew Robinson wrote:
> >> >> >> >> > That error occurs if there is no submitted value (I know -
> >> >> obvious
> >> >> >> >> > statement). Several things can cause it though. Here are the
> >> >> >> ones that
> >> >> >> >> > are most common IMO (P -> problem, S->Work-around/Solution)
> >> >> >> >> >
> >> >> >> >> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
> >> >> >> >> > a4j:region around any component with ajaxSingle set to true
> >> >> to make
> >> >> >> >> > sure only that component is decoded and updated
> >> >> >> >> >
> >> >> >> >> > 2) (P) Element is removed from the client DOM or is disabled
> >> >> >> *and* the
> >> >> >> >> > JSF component is not disabled. (S) The client side
> >> >> enabled/rendered
> >> >> >> >> > should map to the server-side enabled/rendered. Therefore, if
> >> >> >> you are
> >> >> >> >> > disabling/removing components on the client, you need to make
> >> >> >> sure you
> >> >> >> >> > change the value on the server *before* the apply request
> >> values
> >> >> >> phase
> >> >> >> >> > (I think that is the correct phase of the error).
> >> >> >> >> >
> >> >> >> >> > 3) (P) Component is not inside of the form that was
> >> submitted.
> >> >> >> (S1) Do
> >> >> >> >> > not use multiple forms if doing so, instead use the subForm
> >> >> >> component
> >> >> >> >> > in the sandbox with one form or use one or multiple forms
> >> with
> >> >> >> >> > a4j:region if using A4J. (S2) make sure all components that
> >> >> >> implement
> >> >> >> >> > EditableValueHolder are placed inside of a UIForm component.
> >> >> >> >> >
> >> >> >> >> > 4) (P) The EL expression tied to the rendered or disabled
> >> >> >> property of
> >> >> >> >> > the component is not view specific and has been changed by
> >> >> another
> >> >> >> >> > view or is changed before the apply request values phase. (S)
> >> >> Make
> >> >> >> >> > sure the rendered and/or disabled properties of components do
> >> >> not
> >> >> >> >> > change after rendering and before the apply request values.
> >> >> >> >> >
> >> >> >> >> > -Andrew
> >> >> >> >> >
> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> >> >> Mike Kienenberger wrote:
> >> >> >> >> >> > I've also had it happen if the page changes and the
> >> facelets
> >> >> >> >> component
> >> >> >> >> >> > tree (or jsp page) is still cached somewhere.
> >> >> >> >> >> I'm almost completely certain it is not a caching issue
> >> >> >> (although it
> >> >> >> >> >> would be good to know if one could configure Tomcat not to
> >> >> cache
> >> >> >> >> >> anything, ever...) I've hand nuked caches several times and
> >> >> tried
> >> >> >> >> >> executing on a different machine (Tomcat running on the
> >> >> >> localhost in
> >> >> >> >> >> both cases).
> >> >> >> >> >>
> >> >> >> >> >> Shane
> >> >> >> >> >> >   Same idea -- the
> >> >> >> >> >> > expected submitted page elements do not match the actual
> >> >> >> submitted
> >> >> >> >> >> > page elements.
> >> >> >> >> >> >
> >> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> >> >> >>
> >> >> >> >> >> >> I am having some strange navigation problems (once
> >> again...)
> >> >> >> >> and the
> >> >> >> >> >> >> only clue I have is the warning below.
> >> >> >> >> >> >>
> >> >> >> >> >> >> HtmlRendererUtils - There should always be a submitted
> >> value
> >> >> >> >> for an
> >> >> >> >> >> >> input if it is rendered, its form is submitted, and it is
> >> >> not
> >> >> >> >> >> disabled
> >> >> >> >> >> >> or read-only.
> >> >> >> >> >> >>
> >> >> >> >> >> >> In Googling the error message, it seems that the problem
> >> >> >> should be
> >> >> >> >> >> >> related to using Javascript to disable a control which
> >> >> my-faces
> >> >> >> >> >> expects
> >> >> >> >> >> >> to get a value from. The warning goes on to name the
> >> >> >> component in
> >> >> >> >> >> >> question, but there isn't any Javascript which touches
> >> these
> >> >> >> text
> >> >> >> >> >> areas,
> >> >> >> >> >> >> in fact there isn't any Javascript which disables
> >> >> anything. The
> >> >> >> >> >> >> components which are (in theory) causing the warning are
> >> >> >> certainly
> >> >> >> >> >> not
> >> >> >> >> >> >> disabled visually and for the most part they all contain
> >> >> text.
> >> >> >> >> >> They also
> >> >> >> >> >> >> happen to be created in Java code, so there is no jsp to
> >> >> post
> >> >> >> >> here.
> >> >> >> >> >> >>
> >> >> >> >> >> >> Can anyone give me a more detailed interpretation of what
> >> >> the
> >> >> >> >> warning
> >> >> >> >> >> >> means and when it arises?
> >> >> >> >> >> >>
> >> >> >> >> >> >> --
> >> >> >> >> >> >> Shane
> >> >> >> >> >> >>
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> Shane
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Shane
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Shane
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Shane
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Shane
> >>
> >>
> >
>
>
> --
> Shane
>
>

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Mike Kienenberger wrote:
> So the question is why does _id30 get translated to contentPanel_1153
> and _id33 get translated to contentPanel_1344 on submit?
>
That would be the question alright... It seems as though the problem 
actually happens before/during html generation. On submit, it's too late.

> It looks like you've went from automatically generated ids for these
> components to explicitly-set (plus some random number) ids for these
> components.
The parameter map seems like it is the correct one. The text areas in 
question sit in tabs located on 'mainForm'. Specifically the containment 
looks like:

mainForm (explicitly named)
    contentPanel (explicitly named)
        Tab_1 (generated id)
                Panel_1 (generated id)
                    editableAnecdotalComment548806536 (explicitly named 
- the numbers at the end refer to a db id)

Shane
>
>
> On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> At the point where the warning is logged,
>> component.getClientId(FacesContext) doesn't return a value contained in
>> the request parameter map. While that's good for me to know, I'm
>> guessing you guys already knew that :) What could cause the mismatch?
>> Thanks in advance.
>
> On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> Mike Kienenberger wrote:
>> > Another way would be to set a breakpoint somewhere and
>> > check what's in the request parameter map for the current request.
>> OK, what I've done is to add a Servlet Filter to the mix (in looking at
>> example code, it seems that the filter may come in handy down the line).
>> What I figured was that the filter will get processed early, and is
>> therefore a good place to set a breakpoint to examine request
>> parameters. (Although as I write this I'm wondering about filter
>> ordering and the Extensions filter) It seems as though the component
>> id's do not correspond to the request parameters which make it through
>> to the filter. In the generated html I have
>>
>> id="mainForm:_id30:_id33:editableAnecdotalComment548806536"
>>
>> and in the request I have
>>
>> param:
>> mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536, 
>>
>>
>> value: [Ljava.lang.String;@1fff293
>>
>> The "editableAnecdotalComment548806536" portion is the ID that I set.
>> All of the _idXX components get mapped to different parameter names
>> (contentPanel happens to be the name I assigned to the main panel on the
>> jsp page whose binding attribute I use to build up dynamic content).
>> Since all component id's get mapped, I don't yet see a problem. I
>> haven't tried stepping into anything outside my own code yet, but I
>> guess that's next on the list.
>>
>> Shane
>>
>> > You can save the generated html to a file and manually change the url
>> > to something else that will trap and log the values.
>> >
>> > Lots of different options, but the key is to verify that there is no
>> > value being submitted for your component, which is what the error
>> > message is claming.
>> >
>> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> Mike Kienenberger wrote:
>> >>
>> >> > If there's no such element, then you need to figure out why the
>> >> > element wasn't rendered.
>> >> I guess I wasn't clear. The components in question are in the 
>> generated
>> >> html. They are enabled and rendered and I can't find anything which
>> >> might potentially disable them via javascript. Certainly none of the
>> >> javascript that I input will do this and I don't see any in the
>> >> generated javascript which might either.
>> >>
>> >> > If so, then you need to figure out why there's no submitted 
>> value when
>> >> > you submit the form -- perhaps submitting the form through some 
>> kind
>> >> > of proxy which logs all of the values would help.
>> >> OK, can you expand on this a bit? Do you mean some 'off the shelf' 
>> proxy
>> >> or something different? This is what I was getting at with the
>> >> PhaseListener, if I could see what was actually making it through, I
>> >> might be able to make some sense of what's going on.
>> >>
>> >> Shane
>> >>
>> >> >
>> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> Mike Kienenberger wrote:
>> >> >> > Set a breakpoint on the line generating the error.
>> >> >> > Your first step is to determine which component value is missing
>> >> from
>> >> >> > your form submit.
>> >> >> According to the warning message, I can see that there are several
>> >> text
>> >> >> area components which are the problem (I assign the id's myself,
>> >> so it
>> >> >> is easy to verify which components it is complaining about). Most
>> >> of the
>> >> >> components in this page are generated in java code, and everything
>> >> looks
>> >> >> fine inside the factory method responsible for creating the text
>> >> >> components (isDisabled()==false and isRendered()==true). Visually,
>> >> >> immediately preceding an attempt to navigate away from this 
>> page via
>> >> >> CommandLink, the fields in question are rendered and enabled. 
>> After
>> >> >> that, I can see my request scoped backing bean get created once
>> >> the link
>> >> >> is clicked, but then the warnings are thrown and no navigation 
>> takes
>> >> >> place. In terms of the generated html, it is a monsterous form 
>> with
>> >> >> scads of disabled components, so it is not terribly easy to verify
>> >> >> anything (my javascript skills suck as well, and that doesn't 
>> help).
>> >> >> However, everything which gets disabled is set inside the java 
>> code
>> >> >> which generates all of the content for the main panel so there
>> >> ought not
>> >> >> to be any issues with client side disables.
>> >> >>
>> >> >> > Once you know that, look at the generated html before the submit
>> >> and
>> >> >> > see if you can determine why the input for that component didn't
>> >> >> > submit a value.
>> >> >> OK, what do I look for? I know the component id a priori, so I can
>> >> >> isolate the 3 times which it occurs in the generated html. Once
>> >> for the
>> >> >> component name, once for the id, and once in some javascript tied
>> >> to a
>> >> >> sepeate button which does a spell check on the component in 
>> question
>> >> >> (fwiw, the spell check function does not alter either the 
>> rendered or
>> >> >> disabled state of the component and this issue crops up 
>> regardless of
>> >> >> whether or not the spell check function is actually invoked)
>> >> >>
>> >> >> I don't see anything in the html which suggests a problem, but I'm
>> >> not
>> >> >> altogether sure what to look for.
>> >> >>
>> >> >> Shane
>> >> >>
>> >> >> >
>> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> Thanks for the suggestions,
>> >> >> >>
>> >> >> >> In reviewing the potential problems you listed below, I'm still
>> >> >> stuck. I
>> >> >> >> don't use ajax, so 1) shouldn't be an issue. I don't disable
>> >> >> anything in
>> >> >> >> javascript, so 2) shouldn't affect me. I only use a single form
>> >> with
>> >> >> >> everything inside it, so 3) shouldn't be an issue either. And I
>> >> don't
>> >> >> >> tie any EL to the disabled/rendered properties (only the 
>> value is
>> >> >> >> mutated via EL expression).
>> >> >> >>
>> >> >> >> What do you think would be the best way to diagnose what is 
>> going
>> >> >> wrong?
>> >> >> >> I guess I could attach a PhaseListener and set a breakpoint in
>> >> >> there to
>> >> >> >> try to dissect what JSF thinks is wrong. I'm at a real loss 
>> here
>> >> >> since I
>> >> >> >> can't see anything wrong and the components which are 
>> causing the
>> >> >> >> problem are used to capture the most important data I deal 
>> with.
>> >> >> Thanks
>> >> >> >> for the help
>> >> >> >>
>> >> >> >> Shane
>> >> >> >>
>> >> >> >>
>> >> >> >> Andrew Robinson wrote:
>> >> >> >> > That error occurs if there is no submitted value (I know -
>> >> obvious
>> >> >> >> > statement). Several things can cause it though. Here are the
>> >> >> ones that
>> >> >> >> > are most common IMO (P -> problem, S->Work-around/Solution)
>> >> >> >> >
>> >> >> >> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
>> >> >> >> > a4j:region around any component with ajaxSingle set to true
>> >> to make
>> >> >> >> > sure only that component is decoded and updated
>> >> >> >> >
>> >> >> >> > 2) (P) Element is removed from the client DOM or is disabled
>> >> >> *and* the
>> >> >> >> > JSF component is not disabled. (S) The client side
>> >> enabled/rendered
>> >> >> >> > should map to the server-side enabled/rendered. Therefore, if
>> >> >> you are
>> >> >> >> > disabling/removing components on the client, you need to make
>> >> >> sure you
>> >> >> >> > change the value on the server *before* the apply request 
>> values
>> >> >> phase
>> >> >> >> > (I think that is the correct phase of the error).
>> >> >> >> >
>> >> >> >> > 3) (P) Component is not inside of the form that was 
>> submitted.
>> >> >> (S1) Do
>> >> >> >> > not use multiple forms if doing so, instead use the subForm
>> >> >> component
>> >> >> >> > in the sandbox with one form or use one or multiple forms 
>> with
>> >> >> >> > a4j:region if using A4J. (S2) make sure all components that
>> >> >> implement
>> >> >> >> > EditableValueHolder are placed inside of a UIForm component.
>> >> >> >> >
>> >> >> >> > 4) (P) The EL expression tied to the rendered or disabled
>> >> >> property of
>> >> >> >> > the component is not view specific and has been changed by
>> >> another
>> >> >> >> > view or is changed before the apply request values phase. (S)
>> >> Make
>> >> >> >> > sure the rendered and/or disabled properties of components do
>> >> not
>> >> >> >> > change after rendering and before the apply request values.
>> >> >> >> >
>> >> >> >> > -Andrew
>> >> >> >> >
>> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> >> Mike Kienenberger wrote:
>> >> >> >> >> > I've also had it happen if the page changes and the 
>> facelets
>> >> >> >> component
>> >> >> >> >> > tree (or jsp page) is still cached somewhere.
>> >> >> >> >> I'm almost completely certain it is not a caching issue
>> >> >> (although it
>> >> >> >> >> would be good to know if one could configure Tomcat not to
>> >> cache
>> >> >> >> >> anything, ever...) I've hand nuked caches several times and
>> >> tried
>> >> >> >> >> executing on a different machine (Tomcat running on the
>> >> >> localhost in
>> >> >> >> >> both cases).
>> >> >> >> >>
>> >> >> >> >> Shane
>> >> >> >> >> >   Same idea -- the
>> >> >> >> >> > expected submitted page elements do not match the actual
>> >> >> submitted
>> >> >> >> >> > page elements.
>> >> >> >> >> >
>> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> >> >>
>> >> >> >> >> >> I am having some strange navigation problems (once 
>> again...)
>> >> >> >> and the
>> >> >> >> >> >> only clue I have is the warning below.
>> >> >> >> >> >>
>> >> >> >> >> >> HtmlRendererUtils - There should always be a submitted 
>> value
>> >> >> >> for an
>> >> >> >> >> >> input if it is rendered, its form is submitted, and it is
>> >> not
>> >> >> >> >> disabled
>> >> >> >> >> >> or read-only.
>> >> >> >> >> >>
>> >> >> >> >> >> In Googling the error message, it seems that the problem
>> >> >> should be
>> >> >> >> >> >> related to using Javascript to disable a control which
>> >> my-faces
>> >> >> >> >> expects
>> >> >> >> >> >> to get a value from. The warning goes on to name the
>> >> >> component in
>> >> >> >> >> >> question, but there isn't any Javascript which touches 
>> these
>> >> >> text
>> >> >> >> >> areas,
>> >> >> >> >> >> in fact there isn't any Javascript which disables
>> >> anything. The
>> >> >> >> >> >> components which are (in theory) causing the warning are
>> >> >> certainly
>> >> >> >> >> not
>> >> >> >> >> >> disabled visually and for the most part they all contain
>> >> text.
>> >> >> >> >> They also
>> >> >> >> >> >> happen to be created in Java code, so there is no jsp to
>> >> post
>> >> >> >> here.
>> >> >> >> >> >>
>> >> >> >> >> >> Can anyone give me a more detailed interpretation of what
>> >> the
>> >> >> >> warning
>> >> >> >> >> >> means and when it arises?
>> >> >> >> >> >>
>> >> >> >> >> >> --
>> >> >> >> >> >> Shane
>> >> >> >> >> >>
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> Shane
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Shane
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Shane
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> Shane
>> >>
>> >>
>> >
>>
>>
>> -- 
>> Shane
>>
>>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Mike Kienenberger <mk...@gmail.com>]

The cause is probably that

mainForm:_id30:_id33:editableAnecdotalComment548806536 !=
mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536

So the question is why does _id30 get translated to contentPanel_1153
and _id33 get translated to contentPanel_1344 on submit?

It looks like you've went from automatically generated ids for these
components to explicitly-set (plus some random number) ids for these
components.


On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> At the point where the warning is logged,
> component.getClientId(FacesContext) doesn't return a value contained in
> the request parameter map. While that's good for me to know, I'm
> guessing you guys already knew that :) What could cause the mismatch?
> Thanks in advance.

On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> Mike Kienenberger wrote:
> > Another way would be to set a breakpoint somewhere and
> > check what's in the request parameter map for the current request.
> OK, what I've done is to add a Servlet Filter to the mix (in looking at
> example code, it seems that the filter may come in handy down the line).
> What I figured was that the filter will get processed early, and is
> therefore a good place to set a breakpoint to examine request
> parameters. (Although as I write this I'm wondering about filter
> ordering and the Extensions filter) It seems as though the component
> id's do not correspond to the request parameters which make it through
> to the filter. In the generated html I have
>
> id="mainForm:_id30:_id33:editableAnecdotalComment548806536"
>
> and in the request I have
>
> param:
> mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536,
>
> value: [Ljava.lang.String;@1fff293
>
> The "editableAnecdotalComment548806536" portion is the ID that I set.
> All of the _idXX components get mapped to different parameter names
> (contentPanel happens to be the name I assigned to the main panel on the
> jsp page whose binding attribute I use to build up dynamic content).
> Since all component id's get mapped, I don't yet see a problem. I
> haven't tried stepping into anything outside my own code yet, but I
> guess that's next on the list.
>
> Shane
>
> > You can save the generated html to a file and manually change the url
> > to something else that will trap and log the values.
> >
> > Lots of different options, but the key is to verify that there is no
> > value being submitted for your component, which is what the error
> > message is claming.
> >
> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> Mike Kienenberger wrote:
> >>
> >> > If there's no such element, then you need to figure out why the
> >> > element wasn't rendered.
> >> I guess I wasn't clear. The components in question are in the generated
> >> html. They are enabled and rendered and I can't find anything which
> >> might potentially disable them via javascript. Certainly none of the
> >> javascript that I input will do this and I don't see any in the
> >> generated javascript which might either.
> >>
> >> > If so, then you need to figure out why there's no submitted value when
> >> > you submit the form -- perhaps submitting the form through some kind
> >> > of proxy which logs all of the values would help.
> >> OK, can you expand on this a bit? Do you mean some 'off the shelf' proxy
> >> or something different? This is what I was getting at with the
> >> PhaseListener, if I could see what was actually making it through, I
> >> might be able to make some sense of what's going on.
> >>
> >> Shane
> >>
> >> >
> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> Mike Kienenberger wrote:
> >> >> > Set a breakpoint on the line generating the error.
> >> >> > Your first step is to determine which component value is missing
> >> from
> >> >> > your form submit.
> >> >> According to the warning message, I can see that there are several
> >> text
> >> >> area components which are the problem (I assign the id's myself,
> >> so it
> >> >> is easy to verify which components it is complaining about). Most
> >> of the
> >> >> components in this page are generated in java code, and everything
> >> looks
> >> >> fine inside the factory method responsible for creating the text
> >> >> components (isDisabled()==false and isRendered()==true). Visually,
> >> >> immediately preceding an attempt to navigate away from this page via
> >> >> CommandLink, the fields in question are rendered and enabled. After
> >> >> that, I can see my request scoped backing bean get created once
> >> the link
> >> >> is clicked, but then the warnings are thrown and no navigation takes
> >> >> place. In terms of the generated html, it is a monsterous form with
> >> >> scads of disabled components, so it is not terribly easy to verify
> >> >> anything (my javascript skills suck as well, and that doesn't help).
> >> >> However, everything which gets disabled is set inside the java code
> >> >> which generates all of the content for the main panel so there
> >> ought not
> >> >> to be any issues with client side disables.
> >> >>
> >> >> > Once you know that, look at the generated html before the submit
> >> and
> >> >> > see if you can determine why the input for that component didn't
> >> >> > submit a value.
> >> >> OK, what do I look for? I know the component id a priori, so I can
> >> >> isolate the 3 times which it occurs in the generated html. Once
> >> for the
> >> >> component name, once for the id, and once in some javascript tied
> >> to a
> >> >> sepeate button which does a spell check on the component in question
> >> >> (fwiw, the spell check function does not alter either the rendered or
> >> >> disabled state of the component and this issue crops up regardless of
> >> >> whether or not the spell check function is actually invoked)
> >> >>
> >> >> I don't see anything in the html which suggests a problem, but I'm
> >> not
> >> >> altogether sure what to look for.
> >> >>
> >> >> Shane
> >> >>
> >> >> >
> >> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> Thanks for the suggestions,
> >> >> >>
> >> >> >> In reviewing the potential problems you listed below, I'm still
> >> >> stuck. I
> >> >> >> don't use ajax, so 1) shouldn't be an issue. I don't disable
> >> >> anything in
> >> >> >> javascript, so 2) shouldn't affect me. I only use a single form
> >> with
> >> >> >> everything inside it, so 3) shouldn't be an issue either. And I
> >> don't
> >> >> >> tie any EL to the disabled/rendered properties (only the value is
> >> >> >> mutated via EL expression).
> >> >> >>
> >> >> >> What do you think would be the best way to diagnose what is going
> >> >> wrong?
> >> >> >> I guess I could attach a PhaseListener and set a breakpoint in
> >> >> there to
> >> >> >> try to dissect what JSF thinks is wrong. I'm at a real loss here
> >> >> since I
> >> >> >> can't see anything wrong and the components which are causing the
> >> >> >> problem are used to capture the most important data I deal with.
> >> >> Thanks
> >> >> >> for the help
> >> >> >>
> >> >> >> Shane
> >> >> >>
> >> >> >>
> >> >> >> Andrew Robinson wrote:
> >> >> >> > That error occurs if there is no submitted value (I know -
> >> obvious
> >> >> >> > statement). Several things can cause it though. Here are the
> >> >> ones that
> >> >> >> > are most common IMO (P -> problem, S->Work-around/Solution)
> >> >> >> >
> >> >> >> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
> >> >> >> > a4j:region around any component with ajaxSingle set to true
> >> to make
> >> >> >> > sure only that component is decoded and updated
> >> >> >> >
> >> >> >> > 2) (P) Element is removed from the client DOM or is disabled
> >> >> *and* the
> >> >> >> > JSF component is not disabled. (S) The client side
> >> enabled/rendered
> >> >> >> > should map to the server-side enabled/rendered. Therefore, if
> >> >> you are
> >> >> >> > disabling/removing components on the client, you need to make
> >> >> sure you
> >> >> >> > change the value on the server *before* the apply request values
> >> >> phase
> >> >> >> > (I think that is the correct phase of the error).
> >> >> >> >
> >> >> >> > 3) (P) Component is not inside of the form that was submitted.
> >> >> (S1) Do
> >> >> >> > not use multiple forms if doing so, instead use the subForm
> >> >> component
> >> >> >> > in the sandbox with one form or use one or multiple forms with
> >> >> >> > a4j:region if using A4J. (S2) make sure all components that
> >> >> implement
> >> >> >> > EditableValueHolder are placed inside of a UIForm component.
> >> >> >> >
> >> >> >> > 4) (P) The EL expression tied to the rendered or disabled
> >> >> property of
> >> >> >> > the component is not view specific and has been changed by
> >> another
> >> >> >> > view or is changed before the apply request values phase. (S)
> >> Make
> >> >> >> > sure the rendered and/or disabled properties of components do
> >> not
> >> >> >> > change after rendering and before the apply request values.
> >> >> >> >
> >> >> >> > -Andrew
> >> >> >> >
> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> >> Mike Kienenberger wrote:
> >> >> >> >> > I've also had it happen if the page changes and the facelets
> >> >> >> component
> >> >> >> >> > tree (or jsp page) is still cached somewhere.
> >> >> >> >> I'm almost completely certain it is not a caching issue
> >> >> (although it
> >> >> >> >> would be good to know if one could configure Tomcat not to
> >> cache
> >> >> >> >> anything, ever...) I've hand nuked caches several times and
> >> tried
> >> >> >> >> executing on a different machine (Tomcat running on the
> >> >> localhost in
> >> >> >> >> both cases).
> >> >> >> >>
> >> >> >> >> Shane
> >> >> >> >> >   Same idea -- the
> >> >> >> >> > expected submitted page elements do not match the actual
> >> >> submitted
> >> >> >> >> > page elements.
> >> >> >> >> >
> >> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> >> >>
> >> >> >> >> >> I am having some strange navigation problems (once again...)
> >> >> >> and the
> >> >> >> >> >> only clue I have is the warning below.
> >> >> >> >> >>
> >> >> >> >> >> HtmlRendererUtils - There should always be a submitted value
> >> >> >> for an
> >> >> >> >> >> input if it is rendered, its form is submitted, and it is
> >> not
> >> >> >> >> disabled
> >> >> >> >> >> or read-only.
> >> >> >> >> >>
> >> >> >> >> >> In Googling the error message, it seems that the problem
> >> >> should be
> >> >> >> >> >> related to using Javascript to disable a control which
> >> my-faces
> >> >> >> >> expects
> >> >> >> >> >> to get a value from. The warning goes on to name the
> >> >> component in
> >> >> >> >> >> question, but there isn't any Javascript which touches these
> >> >> text
> >> >> >> >> areas,
> >> >> >> >> >> in fact there isn't any Javascript which disables
> >> anything. The
> >> >> >> >> >> components which are (in theory) causing the warning are
> >> >> certainly
> >> >> >> >> not
> >> >> >> >> >> disabled visually and for the most part they all contain
> >> text.
> >> >> >> >> They also
> >> >> >> >> >> happen to be created in Java code, so there is no jsp to
> >> post
> >> >> >> here.
> >> >> >> >> >>
> >> >> >> >> >> Can anyone give me a more detailed interpretation of what
> >> the
> >> >> >> warning
> >> >> >> >> >> means and when it arises?
> >> >> >> >> >>
> >> >> >> >> >> --
> >> >> >> >> >> Shane
> >> >> >> >> >>
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Shane
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Shane
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Shane
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Shane
> >>
> >>
> >
>
>
> --
> Shane
>
>

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Mike Kienenberger wrote:
> Another way would be to set a breakpoint somewhere and
> check what's in the request parameter map for the current request.
OK, what I've done is to add a Servlet Filter to the mix (in looking at 
example code, it seems that the filter may come in handy down the line). 
What I figured was that the filter will get processed early, and is 
therefore a good place to set a breakpoint to examine request 
parameters. (Although as I write this I'm wondering about filter 
ordering and the Extensions filter) It seems as though the component 
id's do not correspond to the request parameters which make it through 
to the filter. In the generated html I have

id="mainForm:_id30:_id33:editableAnecdotalComment548806536"

and in the request I have

param: 
mainForm:contentPanel_1153:contentPanel_1344:editableAnecdotalComment548806536, 

value: [Ljava.lang.String;@1fff293

The "editableAnecdotalComment548806536" portion is the ID that I set. 
All of the _idXX components get mapped to different parameter names 
(contentPanel happens to be the name I assigned to the main panel on the 
jsp page whose binding attribute I use to build up dynamic content). 
Since all component id's get mapped, I don't yet see a problem. I 
haven't tried stepping into anything outside my own code yet, but I 
guess that's next on the list.

Shane

> You can save the generated html to a file and manually change the url
> to something else that will trap and log the values.
>
> Lots of different options, but the key is to verify that there is no
> value being submitted for your component, which is what the error
> message is claming.
>
> On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> Mike Kienenberger wrote:
>>
>> > If there's no such element, then you need to figure out why the
>> > element wasn't rendered.
>> I guess I wasn't clear. The components in question are in the generated
>> html. They are enabled and rendered and I can't find anything which
>> might potentially disable them via javascript. Certainly none of the
>> javascript that I input will do this and I don't see any in the
>> generated javascript which might either.
>>
>> > If so, then you need to figure out why there's no submitted value when
>> > you submit the form -- perhaps submitting the form through some kind
>> > of proxy which logs all of the values would help.
>> OK, can you expand on this a bit? Do you mean some 'off the shelf' proxy
>> or something different? This is what I was getting at with the
>> PhaseListener, if I could see what was actually making it through, I
>> might be able to make some sense of what's going on.
>>
>> Shane
>>
>> >
>> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> Mike Kienenberger wrote:
>> >> > Set a breakpoint on the line generating the error.
>> >> > Your first step is to determine which component value is missing 
>> from
>> >> > your form submit.
>> >> According to the warning message, I can see that there are several 
>> text
>> >> area components which are the problem (I assign the id's myself, 
>> so it
>> >> is easy to verify which components it is complaining about). Most 
>> of the
>> >> components in this page are generated in java code, and everything 
>> looks
>> >> fine inside the factory method responsible for creating the text
>> >> components (isDisabled()==false and isRendered()==true). Visually,
>> >> immediately preceding an attempt to navigate away from this page via
>> >> CommandLink, the fields in question are rendered and enabled. After
>> >> that, I can see my request scoped backing bean get created once 
>> the link
>> >> is clicked, but then the warnings are thrown and no navigation takes
>> >> place. In terms of the generated html, it is a monsterous form with
>> >> scads of disabled components, so it is not terribly easy to verify
>> >> anything (my javascript skills suck as well, and that doesn't help).
>> >> However, everything which gets disabled is set inside the java code
>> >> which generates all of the content for the main panel so there 
>> ought not
>> >> to be any issues with client side disables.
>> >>
>> >> > Once you know that, look at the generated html before the submit 
>> and
>> >> > see if you can determine why the input for that component didn't
>> >> > submit a value.
>> >> OK, what do I look for? I know the component id a priori, so I can
>> >> isolate the 3 times which it occurs in the generated html. Once 
>> for the
>> >> component name, once for the id, and once in some javascript tied 
>> to a
>> >> sepeate button which does a spell check on the component in question
>> >> (fwiw, the spell check function does not alter either the rendered or
>> >> disabled state of the component and this issue crops up regardless of
>> >> whether or not the spell check function is actually invoked)
>> >>
>> >> I don't see anything in the html which suggests a problem, but I'm 
>> not
>> >> altogether sure what to look for.
>> >>
>> >> Shane
>> >>
>> >> >
>> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> Thanks for the suggestions,
>> >> >>
>> >> >> In reviewing the potential problems you listed below, I'm still
>> >> stuck. I
>> >> >> don't use ajax, so 1) shouldn't be an issue. I don't disable
>> >> anything in
>> >> >> javascript, so 2) shouldn't affect me. I only use a single form 
>> with
>> >> >> everything inside it, so 3) shouldn't be an issue either. And I 
>> don't
>> >> >> tie any EL to the disabled/rendered properties (only the value is
>> >> >> mutated via EL expression).
>> >> >>
>> >> >> What do you think would be the best way to diagnose what is going
>> >> wrong?
>> >> >> I guess I could attach a PhaseListener and set a breakpoint in
>> >> there to
>> >> >> try to dissect what JSF thinks is wrong. I'm at a real loss here
>> >> since I
>> >> >> can't see anything wrong and the components which are causing the
>> >> >> problem are used to capture the most important data I deal with.
>> >> Thanks
>> >> >> for the help
>> >> >>
>> >> >> Shane
>> >> >>
>> >> >>
>> >> >> Andrew Robinson wrote:
>> >> >> > That error occurs if there is no submitted value (I know - 
>> obvious
>> >> >> > statement). Several things can cause it though. Here are the
>> >> ones that
>> >> >> > are most common IMO (P -> problem, S->Work-around/Solution)
>> >> >> >
>> >> >> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
>> >> >> > a4j:region around any component with ajaxSingle set to true 
>> to make
>> >> >> > sure only that component is decoded and updated
>> >> >> >
>> >> >> > 2) (P) Element is removed from the client DOM or is disabled
>> >> *and* the
>> >> >> > JSF component is not disabled. (S) The client side 
>> enabled/rendered
>> >> >> > should map to the server-side enabled/rendered. Therefore, if
>> >> you are
>> >> >> > disabling/removing components on the client, you need to make
>> >> sure you
>> >> >> > change the value on the server *before* the apply request values
>> >> phase
>> >> >> > (I think that is the correct phase of the error).
>> >> >> >
>> >> >> > 3) (P) Component is not inside of the form that was submitted.
>> >> (S1) Do
>> >> >> > not use multiple forms if doing so, instead use the subForm
>> >> component
>> >> >> > in the sandbox with one form or use one or multiple forms with
>> >> >> > a4j:region if using A4J. (S2) make sure all components that
>> >> implement
>> >> >> > EditableValueHolder are placed inside of a UIForm component.
>> >> >> >
>> >> >> > 4) (P) The EL expression tied to the rendered or disabled
>> >> property of
>> >> >> > the component is not view specific and has been changed by 
>> another
>> >> >> > view or is changed before the apply request values phase. (S) 
>> Make
>> >> >> > sure the rendered and/or disabled properties of components do 
>> not
>> >> >> > change after rendering and before the apply request values.
>> >> >> >
>> >> >> > -Andrew
>> >> >> >
>> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> Mike Kienenberger wrote:
>> >> >> >> > I've also had it happen if the page changes and the facelets
>> >> >> component
>> >> >> >> > tree (or jsp page) is still cached somewhere.
>> >> >> >> I'm almost completely certain it is not a caching issue
>> >> (although it
>> >> >> >> would be good to know if one could configure Tomcat not to 
>> cache
>> >> >> >> anything, ever...) I've hand nuked caches several times and 
>> tried
>> >> >> >> executing on a different machine (Tomcat running on the
>> >> localhost in
>> >> >> >> both cases).
>> >> >> >>
>> >> >> >> Shane
>> >> >> >> >   Same idea -- the
>> >> >> >> > expected submitted page elements do not match the actual
>> >> submitted
>> >> >> >> > page elements.
>> >> >> >> >
>> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >> >>
>> >> >> >> >> I am having some strange navigation problems (once again...)
>> >> >> and the
>> >> >> >> >> only clue I have is the warning below.
>> >> >> >> >>
>> >> >> >> >> HtmlRendererUtils - There should always be a submitted value
>> >> >> for an
>> >> >> >> >> input if it is rendered, its form is submitted, and it is 
>> not
>> >> >> >> disabled
>> >> >> >> >> or read-only.
>> >> >> >> >>
>> >> >> >> >> In Googling the error message, it seems that the problem
>> >> should be
>> >> >> >> >> related to using Javascript to disable a control which 
>> my-faces
>> >> >> >> expects
>> >> >> >> >> to get a value from. The warning goes on to name the
>> >> component in
>> >> >> >> >> question, but there isn't any Javascript which touches these
>> >> text
>> >> >> >> areas,
>> >> >> >> >> in fact there isn't any Javascript which disables 
>> anything. The
>> >> >> >> >> components which are (in theory) causing the warning are
>> >> certainly
>> >> >> >> not
>> >> >> >> >> disabled visually and for the most part they all contain 
>> text.
>> >> >> >> They also
>> >> >> >> >> happen to be created in Java code, so there is no jsp to 
>> post
>> >> >> here.
>> >> >> >> >>
>> >> >> >> >> Can anyone give me a more detailed interpretation of what 
>> the
>> >> >> warning
>> >> >> >> >> means and when it arises?
>> >> >> >> >>
>> >> >> >> >> --
>> >> >> >> >> Shane
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Shane
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Shane
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> Shane
>> >>
>> >>
>> >
>>
>>
>> -- 
>> Shane
>>
>>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Mike Kienenberger <mk...@gmail.com>]

I mean that when you hit the submit button, your web browser generates
something along these lines


name1=value1
name2=value2
name3=value3
name4=value4

Insure that there are values submitted for each of your textfield ids.

If you happen to have some proxy software sitting around that will log
these values before resubmitting it somewhere else, that'd be one way
to do it.   Another way would be to set a breakpoint somewhere and
check what's in the request parameter map for the current request.
You can save the generated html to a file and manually change the url
to something else that will trap and log the values.

Lots of different options, but the key is to verify that there is no
value being submitted for your component, which is what the error
message is claming.

On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> Mike Kienenberger wrote:
>
> > If there's no such element, then you need to figure out why the
> > element wasn't rendered.
> I guess I wasn't clear. The components in question are in the generated
> html. They are enabled and rendered and I can't find anything which
> might potentially disable them via javascript. Certainly none of the
> javascript that I input will do this and I don't see any in the
> generated javascript which might either.
>
> > If so, then you need to figure out why there's no submitted value when
> > you submit the form -- perhaps submitting the form through some kind
> > of proxy which logs all of the values would help.
> OK, can you expand on this a bit? Do you mean some 'off the shelf' proxy
> or something different? This is what I was getting at with the
> PhaseListener, if I could see what was actually making it through, I
> might be able to make some sense of what's going on.
>
> Shane
>
> >
> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> Mike Kienenberger wrote:
> >> > Set a breakpoint on the line generating the error.
> >> > Your first step is to determine which component value is missing from
> >> > your form submit.
> >> According to the warning message, I can see that there are several text
> >> area components which are the problem (I assign the id's myself, so it
> >> is easy to verify which components it is complaining about). Most of the
> >> components in this page are generated in java code, and everything looks
> >> fine inside the factory method responsible for creating the text
> >> components (isDisabled()==false and isRendered()==true). Visually,
> >> immediately preceding an attempt to navigate away from this page via
> >> CommandLink, the fields in question are rendered and enabled. After
> >> that, I can see my request scoped backing bean get created once the link
> >> is clicked, but then the warnings are thrown and no navigation takes
> >> place. In terms of the generated html, it is a monsterous form with
> >> scads of disabled components, so it is not terribly easy to verify
> >> anything (my javascript skills suck as well, and that doesn't help).
> >> However, everything which gets disabled is set inside the java code
> >> which generates all of the content for the main panel so there ought not
> >> to be any issues with client side disables.
> >>
> >> > Once you know that, look at the generated html before the submit and
> >> > see if you can determine why the input for that component didn't
> >> > submit a value.
> >> OK, what do I look for? I know the component id a priori, so I can
> >> isolate the 3 times which it occurs in the generated html. Once for the
> >> component name, once for the id, and once in some javascript tied to a
> >> sepeate button which does a spell check on the component in question
> >> (fwiw, the spell check function does not alter either the rendered or
> >> disabled state of the component and this issue crops up regardless of
> >> whether or not the spell check function is actually invoked)
> >>
> >> I don't see anything in the html which suggests a problem, but I'm not
> >> altogether sure what to look for.
> >>
> >> Shane
> >>
> >> >
> >> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> Thanks for the suggestions,
> >> >>
> >> >> In reviewing the potential problems you listed below, I'm still
> >> stuck. I
> >> >> don't use ajax, so 1) shouldn't be an issue. I don't disable
> >> anything in
> >> >> javascript, so 2) shouldn't affect me. I only use a single form with
> >> >> everything inside it, so 3) shouldn't be an issue either. And I don't
> >> >> tie any EL to the disabled/rendered properties (only the value is
> >> >> mutated via EL expression).
> >> >>
> >> >> What do you think would be the best way to diagnose what is going
> >> wrong?
> >> >> I guess I could attach a PhaseListener and set a breakpoint in
> >> there to
> >> >> try to dissect what JSF thinks is wrong. I'm at a real loss here
> >> since I
> >> >> can't see anything wrong and the components which are causing the
> >> >> problem are used to capture the most important data I deal with.
> >> Thanks
> >> >> for the help
> >> >>
> >> >> Shane
> >> >>
> >> >>
> >> >> Andrew Robinson wrote:
> >> >> > That error occurs if there is no submitted value (I know - obvious
> >> >> > statement). Several things can cause it though. Here are the
> >> ones that
> >> >> > are most common IMO (P -> problem, S->Work-around/Solution)
> >> >> >
> >> >> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
> >> >> > a4j:region around any component with ajaxSingle set to true to make
> >> >> > sure only that component is decoded and updated
> >> >> >
> >> >> > 2) (P) Element is removed from the client DOM or is disabled
> >> *and* the
> >> >> > JSF component is not disabled. (S) The client side enabled/rendered
> >> >> > should map to the server-side enabled/rendered. Therefore, if
> >> you are
> >> >> > disabling/removing components on the client, you need to make
> >> sure you
> >> >> > change the value on the server *before* the apply request values
> >> phase
> >> >> > (I think that is the correct phase of the error).
> >> >> >
> >> >> > 3) (P) Component is not inside of the form that was submitted.
> >> (S1) Do
> >> >> > not use multiple forms if doing so, instead use the subForm
> >> component
> >> >> > in the sandbox with one form or use one or multiple forms with
> >> >> > a4j:region if using A4J. (S2) make sure all components that
> >> implement
> >> >> > EditableValueHolder are placed inside of a UIForm component.
> >> >> >
> >> >> > 4) (P) The EL expression tied to the rendered or disabled
> >> property of
> >> >> > the component is not view specific and has been changed by another
> >> >> > view or is changed before the apply request values phase. (S) Make
> >> >> > sure the rendered and/or disabled properties of components do not
> >> >> > change after rendering and before the apply request values.
> >> >> >
> >> >> > -Andrew
> >> >> >
> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> Mike Kienenberger wrote:
> >> >> >> > I've also had it happen if the page changes and the facelets
> >> >> component
> >> >> >> > tree (or jsp page) is still cached somewhere.
> >> >> >> I'm almost completely certain it is not a caching issue
> >> (although it
> >> >> >> would be good to know if one could configure Tomcat not to cache
> >> >> >> anything, ever...) I've hand nuked caches several times and tried
> >> >> >> executing on a different machine (Tomcat running on the
> >> localhost in
> >> >> >> both cases).
> >> >> >>
> >> >> >> Shane
> >> >> >> >   Same idea -- the
> >> >> >> > expected submitted page elements do not match the actual
> >> submitted
> >> >> >> > page elements.
> >> >> >> >
> >> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >> >>
> >> >> >> >> I am having some strange navigation problems (once again...)
> >> >> and the
> >> >> >> >> only clue I have is the warning below.
> >> >> >> >>
> >> >> >> >> HtmlRendererUtils - There should always be a submitted value
> >> >> for an
> >> >> >> >> input if it is rendered, its form is submitted, and it is not
> >> >> >> disabled
> >> >> >> >> or read-only.
> >> >> >> >>
> >> >> >> >> In Googling the error message, it seems that the problem
> >> should be
> >> >> >> >> related to using Javascript to disable a control which my-faces
> >> >> >> expects
> >> >> >> >> to get a value from. The warning goes on to name the
> >> component in
> >> >> >> >> question, but there isn't any Javascript which touches these
> >> text
> >> >> >> areas,
> >> >> >> >> in fact there isn't any Javascript which disables anything. The
> >> >> >> >> components which are (in theory) causing the warning are
> >> certainly
> >> >> >> not
> >> >> >> >> disabled visually and for the most part they all contain text.
> >> >> >> They also
> >> >> >> >> happen to be created in Java code, so there is no jsp to post
> >> >> here.
> >> >> >> >>
> >> >> >> >> Can anyone give me a more detailed interpretation of what the
> >> >> warning
> >> >> >> >> means and when it arises?
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Shane
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Shane
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Shane
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Shane
> >>
> >>
> >
>
>
> --
> Shane
>
>

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Mike Kienenberger wrote:

> If there's no such element, then you need to figure out why the
> element wasn't rendered.
I guess I wasn't clear. The components in question are in the generated 
html. They are enabled and rendered and I can't find anything which 
might potentially disable them via javascript. Certainly none of the 
javascript that I input will do this and I don't see any in the 
generated javascript which might either.

> If so, then you need to figure out why there's no submitted value when
> you submit the form -- perhaps submitting the form through some kind
> of proxy which logs all of the values would help.
OK, can you expand on this a bit? Do you mean some 'off the shelf' proxy 
or something different? This is what I was getting at with the 
PhaseListener, if I could see what was actually making it through, I 
might be able to make some sense of what's going on.

Shane

>
> On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> Mike Kienenberger wrote:
>> > Set a breakpoint on the line generating the error.
>> > Your first step is to determine which component value is missing from
>> > your form submit.
>> According to the warning message, I can see that there are several text
>> area components which are the problem (I assign the id's myself, so it
>> is easy to verify which components it is complaining about). Most of the
>> components in this page are generated in java code, and everything looks
>> fine inside the factory method responsible for creating the text
>> components (isDisabled()==false and isRendered()==true). Visually,
>> immediately preceding an attempt to navigate away from this page via
>> CommandLink, the fields in question are rendered and enabled. After
>> that, I can see my request scoped backing bean get created once the link
>> is clicked, but then the warnings are thrown and no navigation takes
>> place. In terms of the generated html, it is a monsterous form with
>> scads of disabled components, so it is not terribly easy to verify
>> anything (my javascript skills suck as well, and that doesn't help).
>> However, everything which gets disabled is set inside the java code
>> which generates all of the content for the main panel so there ought not
>> to be any issues with client side disables.
>>
>> > Once you know that, look at the generated html before the submit and
>> > see if you can determine why the input for that component didn't
>> > submit a value.
>> OK, what do I look for? I know the component id a priori, so I can
>> isolate the 3 times which it occurs in the generated html. Once for the
>> component name, once for the id, and once in some javascript tied to a
>> sepeate button which does a spell check on the component in question
>> (fwiw, the spell check function does not alter either the rendered or
>> disabled state of the component and this issue crops up regardless of
>> whether or not the spell check function is actually invoked)
>>
>> I don't see anything in the html which suggests a problem, but I'm not
>> altogether sure what to look for.
>>
>> Shane
>>
>> >
>> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> Thanks for the suggestions,
>> >>
>> >> In reviewing the potential problems you listed below, I'm still 
>> stuck. I
>> >> don't use ajax, so 1) shouldn't be an issue. I don't disable 
>> anything in
>> >> javascript, so 2) shouldn't affect me. I only use a single form with
>> >> everything inside it, so 3) shouldn't be an issue either. And I don't
>> >> tie any EL to the disabled/rendered properties (only the value is
>> >> mutated via EL expression).
>> >>
>> >> What do you think would be the best way to diagnose what is going 
>> wrong?
>> >> I guess I could attach a PhaseListener and set a breakpoint in 
>> there to
>> >> try to dissect what JSF thinks is wrong. I'm at a real loss here 
>> since I
>> >> can't see anything wrong and the components which are causing the
>> >> problem are used to capture the most important data I deal with. 
>> Thanks
>> >> for the help
>> >>
>> >> Shane
>> >>
>> >>
>> >> Andrew Robinson wrote:
>> >> > That error occurs if there is no submitted value (I know - obvious
>> >> > statement). Several things can cause it though. Here are the 
>> ones that
>> >> > are most common IMO (P -> problem, S->Work-around/Solution)
>> >> >
>> >> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
>> >> > a4j:region around any component with ajaxSingle set to true to make
>> >> > sure only that component is decoded and updated
>> >> >
>> >> > 2) (P) Element is removed from the client DOM or is disabled 
>> *and* the
>> >> > JSF component is not disabled. (S) The client side enabled/rendered
>> >> > should map to the server-side enabled/rendered. Therefore, if 
>> you are
>> >> > disabling/removing components on the client, you need to make 
>> sure you
>> >> > change the value on the server *before* the apply request values 
>> phase
>> >> > (I think that is the correct phase of the error).
>> >> >
>> >> > 3) (P) Component is not inside of the form that was submitted. 
>> (S1) Do
>> >> > not use multiple forms if doing so, instead use the subForm 
>> component
>> >> > in the sandbox with one form or use one or multiple forms with
>> >> > a4j:region if using A4J. (S2) make sure all components that 
>> implement
>> >> > EditableValueHolder are placed inside of a UIForm component.
>> >> >
>> >> > 4) (P) The EL expression tied to the rendered or disabled 
>> property of
>> >> > the component is not view specific and has been changed by another
>> >> > view or is changed before the apply request values phase. (S) Make
>> >> > sure the rendered and/or disabled properties of components do not
>> >> > change after rendering and before the apply request values.
>> >> >
>> >> > -Andrew
>> >> >
>> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> Mike Kienenberger wrote:
>> >> >> > I've also had it happen if the page changes and the facelets
>> >> component
>> >> >> > tree (or jsp page) is still cached somewhere.
>> >> >> I'm almost completely certain it is not a caching issue 
>> (although it
>> >> >> would be good to know if one could configure Tomcat not to cache
>> >> >> anything, ever...) I've hand nuked caches several times and tried
>> >> >> executing on a different machine (Tomcat running on the 
>> localhost in
>> >> >> both cases).
>> >> >>
>> >> >> Shane
>> >> >> >   Same idea -- the
>> >> >> > expected submitted page elements do not match the actual 
>> submitted
>> >> >> > page elements.
>> >> >> >
>> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >> >>
>> >> >> >> I am having some strange navigation problems (once again...)
>> >> and the
>> >> >> >> only clue I have is the warning below.
>> >> >> >>
>> >> >> >> HtmlRendererUtils - There should always be a submitted value
>> >> for an
>> >> >> >> input if it is rendered, its form is submitted, and it is not
>> >> >> disabled
>> >> >> >> or read-only.
>> >> >> >>
>> >> >> >> In Googling the error message, it seems that the problem 
>> should be
>> >> >> >> related to using Javascript to disable a control which my-faces
>> >> >> expects
>> >> >> >> to get a value from. The warning goes on to name the 
>> component in
>> >> >> >> question, but there isn't any Javascript which touches these 
>> text
>> >> >> areas,
>> >> >> >> in fact there isn't any Javascript which disables anything. The
>> >> >> >> components which are (in theory) causing the warning are 
>> certainly
>> >> >> not
>> >> >> >> disabled visually and for the most part they all contain text.
>> >> >> They also
>> >> >> >> happen to be created in Java code, so there is no jsp to post
>> >> here.
>> >> >> >>
>> >> >> >> Can anyone give me a more detailed interpretation of what the
>> >> warning
>> >> >> >> means and when it arises?
>> >> >> >>
>> >> >> >> --
>> >> >> >> Shane
>> >> >> >>
>> >> >> >>
>> >> >> >
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Shane
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> Shane
>> >>
>> >>
>> >
>>
>>
>> -- 
>> Shane
>>
>>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Mike Kienenberger <mk...@gmail.com>]

Or, to put this another way, I don't think that debugging MyFaces is
going to help you find the error.   While it's possible that there's
some subtle edge case in MyFaces causing this error, I think the first
thing to check is that the expected submitted form value pairs in the
html generated match the actual submitted form value pairs in the
generated html once it is submitted.    That's why the general causes
of this error are things that happen after JSF generates the page but
before JSF processes the results of submitting the page --
javascript-induced changes, ajax-induced changes, cache-induced
changes, etc.


On 6/8/07, Mike Kienenberger <mk...@gmail.com> wrote:
> Assuming that the error points to a component with id "myTextArea",
> you should have generated html (use view source before you hit the
> submit button) that has something along these lines:
>
> <textarea name="myForm:myTextArea" id="myForm:myTextArea" rows="5">
>
> If so, then you need to figure out why there's no submitted value when
> you submit the form -- perhaps submitting the form through some kind
> of proxy which logs all of the values would help.
>
> If there's no such element, then you need to figure out why the
> element wasn't rendered.
>
>
> On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> > Mike Kienenberger wrote:
> > > Set a breakpoint on the line generating the error.
> > > Your first step is to determine which component value is missing from
> > > your form submit.
> > According to the warning message, I can see that there are several text
> > area components which are the problem (I assign the id's myself, so it
> > is easy to verify which components it is complaining about). Most of the
> > components in this page are generated in java code, and everything looks
> > fine inside the factory method responsible for creating the text
> > components (isDisabled()==false and isRendered()==true). Visually,
> > immediately preceding an attempt to navigate away from this page via
> > CommandLink, the fields in question are rendered and enabled. After
> > that, I can see my request scoped backing bean get created once the link
> > is clicked, but then the warnings are thrown and no navigation takes
> > place. In terms of the generated html, it is a monsterous form with
> > scads of disabled components, so it is not terribly easy to verify
> > anything (my javascript skills suck as well, and that doesn't help).
> > However, everything which gets disabled is set inside the java code
> > which generates all of the content for the main panel so there ought not
> > to be any issues with client side disables.
> >
> > > Once you know that, look at the generated html before the submit and
> > > see if you can determine why the input for that component didn't
> > > submit a value.
> > OK, what do I look for? I know the component id a priori, so I can
> > isolate the 3 times which it occurs in the generated html. Once for the
> > component name, once for the id, and once in some javascript tied to a
> > sepeate button which does a spell check on the component in question
> > (fwiw, the spell check function does not alter either the rendered or
> > disabled state of the component and this issue crops up regardless of
> > whether or not the spell check function is actually invoked)
> >
> > I don't see anything in the html which suggests a problem, but I'm not
> > altogether sure what to look for.
> >
> > Shane
> >
> > >
> > > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> > >> Thanks for the suggestions,
> > >>
> > >> In reviewing the potential problems you listed below, I'm still stuck. I
> > >> don't use ajax, so 1) shouldn't be an issue. I don't disable anything in
> > >> javascript, so 2) shouldn't affect me. I only use a single form with
> > >> everything inside it, so 3) shouldn't be an issue either. And I don't
> > >> tie any EL to the disabled/rendered properties (only the value is
> > >> mutated via EL expression).
> > >>
> > >> What do you think would be the best way to diagnose what is going wrong?
> > >> I guess I could attach a PhaseListener and set a breakpoint in there to
> > >> try to dissect what JSF thinks is wrong. I'm at a real loss here since I
> > >> can't see anything wrong and the components which are causing the
> > >> problem are used to capture the most important data I deal with. Thanks
> > >> for the help
> > >>
> > >> Shane
> > >>
> > >>
> > >> Andrew Robinson wrote:
> > >> > That error occurs if there is no submitted value (I know - obvious
> > >> > statement). Several things can cause it though. Here are the ones that
> > >> > are most common IMO (P -> problem, S->Work-around/Solution)
> > >> >
> > >> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
> > >> > a4j:region around any component with ajaxSingle set to true to make
> > >> > sure only that component is decoded and updated
> > >> >
> > >> > 2) (P) Element is removed from the client DOM or is disabled *and* the
> > >> > JSF component is not disabled. (S) The client side enabled/rendered
> > >> > should map to the server-side enabled/rendered. Therefore, if you are
> > >> > disabling/removing components on the client, you need to make sure you
> > >> > change the value on the server *before* the apply request values phase
> > >> > (I think that is the correct phase of the error).
> > >> >
> > >> > 3) (P) Component is not inside of the form that was submitted. (S1) Do
> > >> > not use multiple forms if doing so, instead use the subForm component
> > >> > in the sandbox with one form or use one or multiple forms with
> > >> > a4j:region if using A4J. (S2) make sure all components that implement
> > >> > EditableValueHolder are placed inside of a UIForm component.
> > >> >
> > >> > 4) (P) The EL expression tied to the rendered or disabled property of
> > >> > the component is not view specific and has been changed by another
> > >> > view or is changed before the apply request values phase. (S) Make
> > >> > sure the rendered and/or disabled properties of components do not
> > >> > change after rendering and before the apply request values.
> > >> >
> > >> > -Andrew
> > >> >
> > >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> > >> >> Mike Kienenberger wrote:
> > >> >> > I've also had it happen if the page changes and the facelets
> > >> component
> > >> >> > tree (or jsp page) is still cached somewhere.
> > >> >> I'm almost completely certain it is not a caching issue (although it
> > >> >> would be good to know if one could configure Tomcat not to cache
> > >> >> anything, ever...) I've hand nuked caches several times and tried
> > >> >> executing on a different machine (Tomcat running on the localhost in
> > >> >> both cases).
> > >> >>
> > >> >> Shane
> > >> >> >   Same idea -- the
> > >> >> > expected submitted page elements do not match the actual submitted
> > >> >> > page elements.
> > >> >> >
> > >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> > >> >> >>
> > >> >> >> I am having some strange navigation problems (once again...)
> > >> and the
> > >> >> >> only clue I have is the warning below.
> > >> >> >>
> > >> >> >> HtmlRendererUtils - There should always be a submitted value
> > >> for an
> > >> >> >> input if it is rendered, its form is submitted, and it is not
> > >> >> disabled
> > >> >> >> or read-only.
> > >> >> >>
> > >> >> >> In Googling the error message, it seems that the problem should be
> > >> >> >> related to using Javascript to disable a control which my-faces
> > >> >> expects
> > >> >> >> to get a value from. The warning goes on to name the component in
> > >> >> >> question, but there isn't any Javascript which touches these text
> > >> >> areas,
> > >> >> >> in fact there isn't any Javascript which disables anything. The
> > >> >> >> components which are (in theory) causing the warning are certainly
> > >> >> not
> > >> >> >> disabled visually and for the most part they all contain text.
> > >> >> They also
> > >> >> >> happen to be created in Java code, so there is no jsp to post
> > >> here.
> > >> >> >>
> > >> >> >> Can anyone give me a more detailed interpretation of what the
> > >> warning
> > >> >> >> means and when it arises?
> > >> >> >>
> > >> >> >> --
> > >> >> >> Shane
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Shane
> > >> >>
> > >> >>
> > >> >
> > >>
> > >>
> > >> --
> > >> Shane
> > >>
> > >>
> > >
> >
> >
> > --
> > Shane
> >
> >
>

Re: HtmlRendererUtils - There should always be a submitted value

[Mike Kienenberger <mk...@gmail.com>]

Assuming that the error points to a component with id "myTextArea",
you should have generated html (use view source before you hit the
submit button) that has something along these lines:

<textarea name="myForm:myTextArea" id="myForm:myTextArea" rows="5">

If so, then you need to figure out why there's no submitted value when
you submit the form -- perhaps submitting the form through some kind
of proxy which logs all of the values would help.

If there's no such element, then you need to figure out why the
element wasn't rendered.


On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> Mike Kienenberger wrote:
> > Set a breakpoint on the line generating the error.
> > Your first step is to determine which component value is missing from
> > your form submit.
> According to the warning message, I can see that there are several text
> area components which are the problem (I assign the id's myself, so it
> is easy to verify which components it is complaining about). Most of the
> components in this page are generated in java code, and everything looks
> fine inside the factory method responsible for creating the text
> components (isDisabled()==false and isRendered()==true). Visually,
> immediately preceding an attempt to navigate away from this page via
> CommandLink, the fields in question are rendered and enabled. After
> that, I can see my request scoped backing bean get created once the link
> is clicked, but then the warnings are thrown and no navigation takes
> place. In terms of the generated html, it is a monsterous form with
> scads of disabled components, so it is not terribly easy to verify
> anything (my javascript skills suck as well, and that doesn't help).
> However, everything which gets disabled is set inside the java code
> which generates all of the content for the main panel so there ought not
> to be any issues with client side disables.
>
> > Once you know that, look at the generated html before the submit and
> > see if you can determine why the input for that component didn't
> > submit a value.
> OK, what do I look for? I know the component id a priori, so I can
> isolate the 3 times which it occurs in the generated html. Once for the
> component name, once for the id, and once in some javascript tied to a
> sepeate button which does a spell check on the component in question
> (fwiw, the spell check function does not alter either the rendered or
> disabled state of the component and this issue crops up regardless of
> whether or not the spell check function is actually invoked)
>
> I don't see anything in the html which suggests a problem, but I'm not
> altogether sure what to look for.
>
> Shane
>
> >
> > On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> Thanks for the suggestions,
> >>
> >> In reviewing the potential problems you listed below, I'm still stuck. I
> >> don't use ajax, so 1) shouldn't be an issue. I don't disable anything in
> >> javascript, so 2) shouldn't affect me. I only use a single form with
> >> everything inside it, so 3) shouldn't be an issue either. And I don't
> >> tie any EL to the disabled/rendered properties (only the value is
> >> mutated via EL expression).
> >>
> >> What do you think would be the best way to diagnose what is going wrong?
> >> I guess I could attach a PhaseListener and set a breakpoint in there to
> >> try to dissect what JSF thinks is wrong. I'm at a real loss here since I
> >> can't see anything wrong and the components which are causing the
> >> problem are used to capture the most important data I deal with. Thanks
> >> for the help
> >>
> >> Shane
> >>
> >>
> >> Andrew Robinson wrote:
> >> > That error occurs if there is no submitted value (I know - obvious
> >> > statement). Several things can cause it though. Here are the ones that
> >> > are most common IMO (P -> problem, S->Work-around/Solution)
> >> >
> >> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
> >> > a4j:region around any component with ajaxSingle set to true to make
> >> > sure only that component is decoded and updated
> >> >
> >> > 2) (P) Element is removed from the client DOM or is disabled *and* the
> >> > JSF component is not disabled. (S) The client side enabled/rendered
> >> > should map to the server-side enabled/rendered. Therefore, if you are
> >> > disabling/removing components on the client, you need to make sure you
> >> > change the value on the server *before* the apply request values phase
> >> > (I think that is the correct phase of the error).
> >> >
> >> > 3) (P) Component is not inside of the form that was submitted. (S1) Do
> >> > not use multiple forms if doing so, instead use the subForm component
> >> > in the sandbox with one form or use one or multiple forms with
> >> > a4j:region if using A4J. (S2) make sure all components that implement
> >> > EditableValueHolder are placed inside of a UIForm component.
> >> >
> >> > 4) (P) The EL expression tied to the rendered or disabled property of
> >> > the component is not view specific and has been changed by another
> >> > view or is changed before the apply request values phase. (S) Make
> >> > sure the rendered and/or disabled properties of components do not
> >> > change after rendering and before the apply request values.
> >> >
> >> > -Andrew
> >> >
> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> Mike Kienenberger wrote:
> >> >> > I've also had it happen if the page changes and the facelets
> >> component
> >> >> > tree (or jsp page) is still cached somewhere.
> >> >> I'm almost completely certain it is not a caching issue (although it
> >> >> would be good to know if one could configure Tomcat not to cache
> >> >> anything, ever...) I've hand nuked caches several times and tried
> >> >> executing on a different machine (Tomcat running on the localhost in
> >> >> both cases).
> >> >>
> >> >> Shane
> >> >> >   Same idea -- the
> >> >> > expected submitted page elements do not match the actual submitted
> >> >> > page elements.
> >> >> >
> >> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >> >>
> >> >> >> I am having some strange navigation problems (once again...)
> >> and the
> >> >> >> only clue I have is the warning below.
> >> >> >>
> >> >> >> HtmlRendererUtils - There should always be a submitted value
> >> for an
> >> >> >> input if it is rendered, its form is submitted, and it is not
> >> >> disabled
> >> >> >> or read-only.
> >> >> >>
> >> >> >> In Googling the error message, it seems that the problem should be
> >> >> >> related to using Javascript to disable a control which my-faces
> >> >> expects
> >> >> >> to get a value from. The warning goes on to name the component in
> >> >> >> question, but there isn't any Javascript which touches these text
> >> >> areas,
> >> >> >> in fact there isn't any Javascript which disables anything. The
> >> >> >> components which are (in theory) causing the warning are certainly
> >> >> not
> >> >> >> disabled visually and for the most part they all contain text.
> >> >> They also
> >> >> >> happen to be created in Java code, so there is no jsp to post
> >> here.
> >> >> >>
> >> >> >> Can anyone give me a more detailed interpretation of what the
> >> warning
> >> >> >> means and when it arises?
> >> >> >>
> >> >> >> --
> >> >> >> Shane
> >> >> >>
> >> >> >>
> >> >> >
> >> >>
> >> >>
> >> >> --
> >> >> Shane
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Shane
> >>
> >>
> >
>
>
> --
> Shane
>
>

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Mike Kienenberger wrote:
> Set a breakpoint on the line generating the error.
> Your first step is to determine which component value is missing from
> your form submit.
According to the warning message, I can see that there are several text 
area components which are the problem (I assign the id's myself, so it 
is easy to verify which components it is complaining about). Most of the 
components in this page are generated in java code, and everything looks 
fine inside the factory method responsible for creating the text 
components (isDisabled()==false and isRendered()==true). Visually, 
immediately preceding an attempt to navigate away from this page via 
CommandLink, the fields in question are rendered and enabled. After 
that, I can see my request scoped backing bean get created once the link 
is clicked, but then the warnings are thrown and no navigation takes 
place. In terms of the generated html, it is a monsterous form with 
scads of disabled components, so it is not terribly easy to verify 
anything (my javascript skills suck as well, and that doesn't help). 
However, everything which gets disabled is set inside the java code 
which generates all of the content for the main panel so there ought not 
to be any issues with client side disables.

> Once you know that, look at the generated html before the submit and
> see if you can determine why the input for that component didn't
> submit a value.
OK, what do I look for? I know the component id a priori, so I can 
isolate the 3 times which it occurs in the generated html. Once for the 
component name, once for the id, and once in some javascript tied to a 
sepeate button which does a spell check on the component in question 
(fwiw, the spell check function does not alter either the rendered or 
disabled state of the component and this issue crops up regardless of 
whether or not the spell check function is actually invoked)

I don't see anything in the html which suggests a problem, but I'm not 
altogether sure what to look for.

Shane

>
> On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
>> Thanks for the suggestions,
>>
>> In reviewing the potential problems you listed below, I'm still stuck. I
>> don't use ajax, so 1) shouldn't be an issue. I don't disable anything in
>> javascript, so 2) shouldn't affect me. I only use a single form with
>> everything inside it, so 3) shouldn't be an issue either. And I don't
>> tie any EL to the disabled/rendered properties (only the value is
>> mutated via EL expression).
>>
>> What do you think would be the best way to diagnose what is going wrong?
>> I guess I could attach a PhaseListener and set a breakpoint in there to
>> try to dissect what JSF thinks is wrong. I'm at a real loss here since I
>> can't see anything wrong and the components which are causing the
>> problem are used to capture the most important data I deal with. Thanks
>> for the help
>>
>> Shane
>>
>>
>> Andrew Robinson wrote:
>> > That error occurs if there is no submitted value (I know - obvious
>> > statement). Several things can cause it though. Here are the ones that
>> > are most common IMO (P -> problem, S->Work-around/Solution)
>> >
>> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
>> > a4j:region around any component with ajaxSingle set to true to make
>> > sure only that component is decoded and updated
>> >
>> > 2) (P) Element is removed from the client DOM or is disabled *and* the
>> > JSF component is not disabled. (S) The client side enabled/rendered
>> > should map to the server-side enabled/rendered. Therefore, if you are
>> > disabling/removing components on the client, you need to make sure you
>> > change the value on the server *before* the apply request values phase
>> > (I think that is the correct phase of the error).
>> >
>> > 3) (P) Component is not inside of the form that was submitted. (S1) Do
>> > not use multiple forms if doing so, instead use the subForm component
>> > in the sandbox with one form or use one or multiple forms with
>> > a4j:region if using A4J. (S2) make sure all components that implement
>> > EditableValueHolder are placed inside of a UIForm component.
>> >
>> > 4) (P) The EL expression tied to the rendered or disabled property of
>> > the component is not view specific and has been changed by another
>> > view or is changed before the apply request values phase. (S) Make
>> > sure the rendered and/or disabled properties of components do not
>> > change after rendering and before the apply request values.
>> >
>> > -Andrew
>> >
>> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> Mike Kienenberger wrote:
>> >> > I've also had it happen if the page changes and the facelets 
>> component
>> >> > tree (or jsp page) is still cached somewhere.
>> >> I'm almost completely certain it is not a caching issue (although it
>> >> would be good to know if one could configure Tomcat not to cache
>> >> anything, ever...) I've hand nuked caches several times and tried
>> >> executing on a different machine (Tomcat running on the localhost in
>> >> both cases).
>> >>
>> >> Shane
>> >> >   Same idea -- the
>> >> > expected submitted page elements do not match the actual submitted
>> >> > page elements.
>> >> >
>> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >> >>
>> >> >> I am having some strange navigation problems (once again...) 
>> and the
>> >> >> only clue I have is the warning below.
>> >> >>
>> >> >> HtmlRendererUtils - There should always be a submitted value 
>> for an
>> >> >> input if it is rendered, its form is submitted, and it is not
>> >> disabled
>> >> >> or read-only.
>> >> >>
>> >> >> In Googling the error message, it seems that the problem should be
>> >> >> related to using Javascript to disable a control which my-faces
>> >> expects
>> >> >> to get a value from. The warning goes on to name the component in
>> >> >> question, but there isn't any Javascript which touches these text
>> >> areas,
>> >> >> in fact there isn't any Javascript which disables anything. The
>> >> >> components which are (in theory) causing the warning are certainly
>> >> not
>> >> >> disabled visually and for the most part they all contain text.
>> >> They also
>> >> >> happen to be created in Java code, so there is no jsp to post 
>> here.
>> >> >>
>> >> >> Can anyone give me a more detailed interpretation of what the 
>> warning
>> >> >> means and when it arises?
>> >> >>
>> >> >> --
>> >> >> Shane
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> Shane
>> >>
>> >>
>> >
>>
>>
>> -- 
>> Shane
>>
>>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Mike Kienenberger <mk...@gmail.com>]

Set a breakpoint on the line generating the error.
Your first step is to determine which component value is missing from
your form submit.

Once you know that, look at the generated html before the submit and
see if you can determine why the input for that component didn't
submit a value.

On 6/8/07, Shane Petroff <sh...@mayet.ca> wrote:
> Thanks for the suggestions,
>
> In reviewing the potential problems you listed below, I'm still stuck. I
> don't use ajax, so 1) shouldn't be an issue. I don't disable anything in
> javascript, so 2) shouldn't affect me. I only use a single form with
> everything inside it, so 3) shouldn't be an issue either. And I don't
> tie any EL to the disabled/rendered properties (only the value is
> mutated via EL expression).
>
> What do you think would be the best way to diagnose what is going wrong?
> I guess I could attach a PhaseListener and set a breakpoint in there to
> try to dissect what JSF thinks is wrong. I'm at a real loss here since I
> can't see anything wrong and the components which are causing the
> problem are used to capture the most important data I deal with. Thanks
> for the help
>
> Shane
>
>
> Andrew Robinson wrote:
> > That error occurs if there is no submitted value (I know - obvious
> > statement). Several things can cause it though. Here are the ones that
> > are most common IMO (P -> problem, S->Work-around/Solution)
> >
> > 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
> > a4j:region around any component with ajaxSingle set to true to make
> > sure only that component is decoded and updated
> >
> > 2) (P) Element is removed from the client DOM or is disabled *and* the
> > JSF component is not disabled. (S) The client side enabled/rendered
> > should map to the server-side enabled/rendered. Therefore, if you are
> > disabling/removing components on the client, you need to make sure you
> > change the value on the server *before* the apply request values phase
> > (I think that is the correct phase of the error).
> >
> > 3) (P) Component is not inside of the form that was submitted. (S1) Do
> > not use multiple forms if doing so, instead use the subForm component
> > in the sandbox with one form or use one or multiple forms with
> > a4j:region if using A4J. (S2) make sure all components that implement
> > EditableValueHolder are placed inside of a UIForm component.
> >
> > 4) (P) The EL expression tied to the rendered or disabled property of
> > the component is not view specific and has been changed by another
> > view or is changed before the apply request values phase. (S) Make
> > sure the rendered and/or disabled properties of components do not
> > change after rendering and before the apply request values.
> >
> > -Andrew
> >
> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> Mike Kienenberger wrote:
> >> > I've also had it happen if the page changes and the facelets component
> >> > tree (or jsp page) is still cached somewhere.
> >> I'm almost completely certain it is not a caching issue (although it
> >> would be good to know if one could configure Tomcat not to cache
> >> anything, ever...) I've hand nuked caches several times and tried
> >> executing on a different machine (Tomcat running on the localhost in
> >> both cases).
> >>
> >> Shane
> >> >   Same idea -- the
> >> > expected submitted page elements do not match the actual submitted
> >> > page elements.
> >> >
> >> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >> >>
> >> >> I am having some strange navigation problems (once again...) and the
> >> >> only clue I have is the warning below.
> >> >>
> >> >> HtmlRendererUtils - There should always be a submitted value for an
> >> >> input if it is rendered, its form is submitted, and it is not
> >> disabled
> >> >> or read-only.
> >> >>
> >> >> In Googling the error message, it seems that the problem should be
> >> >> related to using Javascript to disable a control which my-faces
> >> expects
> >> >> to get a value from. The warning goes on to name the component in
> >> >> question, but there isn't any Javascript which touches these text
> >> areas,
> >> >> in fact there isn't any Javascript which disables anything. The
> >> >> components which are (in theory) causing the warning are certainly
> >> not
> >> >> disabled visually and for the most part they all contain text.
> >> They also
> >> >> happen to be created in Java code, so there is no jsp to post here.
> >> >>
> >> >> Can anyone give me a more detailed interpretation of what the warning
> >> >> means and when it arises?
> >> >>
> >> >> --
> >> >> Shane
> >> >>
> >> >>
> >> >
> >>
> >>
> >> --
> >> Shane
> >>
> >>
> >
>
>
> --
> Shane
>
>

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Thanks for the suggestions,

In reviewing the potential problems you listed below, I'm still stuck. I 
don't use ajax, so 1) shouldn't be an issue. I don't disable anything in 
javascript, so 2) shouldn't affect me. I only use a single form with 
everything inside it, so 3) shouldn't be an issue either. And I don't 
tie any EL to the disabled/rendered properties (only the value is 
mutated via EL expression).

What do you think would be the best way to diagnose what is going wrong? 
I guess I could attach a PhaseListener and set a breakpoint in there to 
try to dissect what JSF thinks is wrong. I'm at a real loss here since I 
can't see anything wrong and the components which are causing the 
problem are used to capture the most important data I deal with. Thanks 
for the help

Shane


Andrew Robinson wrote:
> That error occurs if there is no submitted value (I know - obvious
> statement). Several things can cause it though. Here are the ones that
> are most common IMO (P -> problem, S->Work-around/Solution)
>
> 1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
> a4j:region around any component with ajaxSingle set to true to make
> sure only that component is decoded and updated
>
> 2) (P) Element is removed from the client DOM or is disabled *and* the
> JSF component is not disabled. (S) The client side enabled/rendered
> should map to the server-side enabled/rendered. Therefore, if you are
> disabling/removing components on the client, you need to make sure you
> change the value on the server *before* the apply request values phase
> (I think that is the correct phase of the error).
>
> 3) (P) Component is not inside of the form that was submitted. (S1) Do
> not use multiple forms if doing so, instead use the subForm component
> in the sandbox with one form or use one or multiple forms with
> a4j:region if using A4J. (S2) make sure all components that implement
> EditableValueHolder are placed inside of a UIForm component.
>
> 4) (P) The EL expression tied to the rendered or disabled property of
> the component is not view specific and has been changed by another
> view or is changed before the apply request values phase. (S) Make
> sure the rendered and/or disabled properties of components do not
> change after rendering and before the apply request values.
>
> -Andrew
>
> On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> Mike Kienenberger wrote:
>> > I've also had it happen if the page changes and the facelets component
>> > tree (or jsp page) is still cached somewhere.
>> I'm almost completely certain it is not a caching issue (although it
>> would be good to know if one could configure Tomcat not to cache
>> anything, ever...) I've hand nuked caches several times and tried
>> executing on a different machine (Tomcat running on the localhost in
>> both cases).
>>
>> Shane
>> >   Same idea -- the
>> > expected submitted page elements do not match the actual submitted
>> > page elements.
>> >
>> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>> >>
>> >> I am having some strange navigation problems (once again...) and the
>> >> only clue I have is the warning below.
>> >>
>> >> HtmlRendererUtils - There should always be a submitted value for an
>> >> input if it is rendered, its form is submitted, and it is not 
>> disabled
>> >> or read-only.
>> >>
>> >> In Googling the error message, it seems that the problem should be
>> >> related to using Javascript to disable a control which my-faces 
>> expects
>> >> to get a value from. The warning goes on to name the component in
>> >> question, but there isn't any Javascript which touches these text 
>> areas,
>> >> in fact there isn't any Javascript which disables anything. The
>> >> components which are (in theory) causing the warning are certainly 
>> not
>> >> disabled visually and for the most part they all contain text. 
>> They also
>> >> happen to be created in Java code, so there is no jsp to post here.
>> >>
>> >> Can anyone give me a more detailed interpretation of what the warning
>> >> means and when it arises?
>> >>
>> >> --
>> >> Shane
>> >>
>> >>
>> >
>>
>>
>> -- 
>> Shane
>>
>>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Andrew Robinson <an...@gmail.com>]

That error occurs if there is no submitted value (I know - obvious
statement). Several things can cause it though. Here are the ones that
are most common IMO (P -> problem, S->Work-around/Solution)

1) (P) A4J and the ajaxSingle attribute set to true. (S) Use
a4j:region around any component with ajaxSingle set to true to make
sure only that component is decoded and updated

2) (P) Element is removed from the client DOM or is disabled *and* the
JSF component is not disabled. (S) The client side enabled/rendered
should map to the server-side enabled/rendered. Therefore, if you are
disabling/removing components on the client, you need to make sure you
change the value on the server *before* the apply request values phase
(I think that is the correct phase of the error).

3) (P) Component is not inside of the form that was submitted. (S1) Do
not use multiple forms if doing so, instead use the subForm component
in the sandbox with one form or use one or multiple forms with
a4j:region if using A4J. (S2) make sure all components that implement
EditableValueHolder are placed inside of a UIForm component.

4) (P) The EL expression tied to the rendered or disabled property of
the component is not view specific and has been changed by another
view or is changed before the apply request values phase. (S) Make
sure the rendered and/or disabled properties of components do not
change after rendering and before the apply request values.

-Andrew

On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> Mike Kienenberger wrote:
> > I've also had it happen if the page changes and the facelets component
> > tree (or jsp page) is still cached somewhere.
> I'm almost completely certain it is not a caching issue (although it
> would be good to know if one could configure Tomcat not to cache
> anything, ever...) I've hand nuked caches several times and tried
> executing on a different machine (Tomcat running on the localhost in
> both cases).
>
> Shane
> >   Same idea -- the
> > expected submitted page elements do not match the actual submitted
> > page elements.
> >
> > On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
> >>
> >> I am having some strange navigation problems (once again...) and the
> >> only clue I have is the warning below.
> >>
> >> HtmlRendererUtils - There should always be a submitted value for an
> >> input if it is rendered, its form is submitted, and it is not disabled
> >> or read-only.
> >>
> >> In Googling the error message, it seems that the problem should be
> >> related to using Javascript to disable a control which my-faces expects
> >> to get a value from. The warning goes on to name the component in
> >> question, but there isn't any Javascript which touches these text areas,
> >> in fact there isn't any Javascript which disables anything. The
> >> components which are (in theory) causing the warning are certainly not
> >> disabled visually and for the most part they all contain text. They also
> >> happen to be created in Java code, so there is no jsp to post here.
> >>
> >> Can anyone give me a more detailed interpretation of what the warning
> >> means and when it arises?
> >>
> >> --
> >> Shane
> >>
> >>
> >
>
>
> --
> Shane
>
>

Re: HtmlRendererUtils - There should always be a submitted value

[Shane Petroff <sh...@mayet.ca>]

Mike Kienenberger wrote:
> I've also had it happen if the page changes and the facelets component
> tree (or jsp page) is still cached somewhere.
I'm almost completely certain it is not a caching issue (although it 
would be good to know if one could configure Tomcat not to cache 
anything, ever...) I've hand nuked caches several times and tried 
executing on a different machine (Tomcat running on the localhost in 
both cases).

Shane
>   Same idea -- the
> expected submitted page elements do not match the actual submitted
> page elements.
>
> On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>>
>> I am having some strange navigation problems (once again...) and the
>> only clue I have is the warning below.
>>
>> HtmlRendererUtils - There should always be a submitted value for an
>> input if it is rendered, its form is submitted, and it is not disabled
>> or read-only.
>>
>> In Googling the error message, it seems that the problem should be
>> related to using Javascript to disable a control which my-faces expects
>> to get a value from. The warning goes on to name the component in
>> question, but there isn't any Javascript which touches these text areas,
>> in fact there isn't any Javascript which disables anything. The
>> components which are (in theory) causing the warning are certainly not
>> disabled visually and for the most part they all contain text. They also
>> happen to be created in Java code, so there is no jsp to post here.
>>
>> Can anyone give me a more detailed interpretation of what the warning
>> means and when it arises?
>>
>> -- 
>> Shane
>>
>>
>


-- 
Shane

Re: HtmlRendererUtils - There should always be a submitted value

[Mike Kienenberger <mk...@gmail.com>]

I've also had it happen if the page changes and the facelets component
tree (or jsp page) is still cached somewhere.   Same idea -- the
expected submitted page elements do not match the actual submitted
page elements.

On 6/5/07, Shane Petroff <sh...@mayet.ca> wrote:
>
> I am having some strange navigation problems (once again...) and the
> only clue I have is the warning below.
>
> HtmlRendererUtils - There should always be a submitted value for an
> input if it is rendered, its form is submitted, and it is not disabled
> or read-only.
>
> In Googling the error message, it seems that the problem should be
> related to using Javascript to disable a control which my-faces expects
> to get a value from. The warning goes on to name the component in
> question, but there isn't any Javascript which touches these text areas,
> in fact there isn't any Javascript which disables anything. The
> components which are (in theory) causing the warning are certainly not
> disabled visually and for the most part they all contain text. They also
> happen to be created in Java code, so there is no jsp to post here.
>
> Can anyone give me a more detailed interpretation of what the warning
> means and when it arises?
>
> --
> Shane
>
>