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