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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
