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