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 <[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
>>
>>
>
--
Shane
