Hi guys,
this is our Input-decode code. Looks good to me...
I do suggest you look into the scope of your model first: do you save
the model between requests? If not, the read-only model-data will be
lost on the next request; so you should either put your model to
session-scope or use t:saveState to save the property between
requests.
Regards,
Martin
public static void decodeUIInput(FacesContext facesContext,
UIComponent component) {
if (!(component instanceof EditableValueHolder)) {
throw new IllegalArgumentException("Component "
+ component.getClientId(facesContext)
+ " is not an EditableValueHolder");
}
Map paramMap = facesContext.getExternalContext()
.getRequestParameterMap();
String clientId = component.getClientId(facesContext);
if (isDisabledOrReadOnly(component))
return;
if (paramMap.containsKey(clientId)) {
((EditableValueHolder) component).setSubmittedValue(paramMap
.get(clientId));
}
else {
log.warn(
"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. Component : " +
RendererUtils.getPathToComponent(component));
}
}
On 10/30/06, Andrew Robinson <[EMAIL PROTECTED]> wrote:
What I don't understand is why the server is looking for POST'ed
values from the client for read-only and disabled controls. If the
browser submits values for these, the server should ignore them.
Otherwise it could be a large security problem if users could, using
script, re-enable a control so that the value is submitted back to the
server.
The fact that the error is printed out seems like a bug to me. I would
think that UIInput controls should not print any errors or do any work
(no local or sumitted value processing) if the control is read-only or
disabled.
What does the spec. have to say about these two attributes?
-Andrew
On 10/29/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
>
>
> On 10/29/06, Simon Kitching <[EMAIL PROTECTED]> wrote:
> >
> > I don't know whether the behaviour you see with the normal one
> > (required=true causes error for components when readonly=true) also
> > applies to Sun's JSF implementation but I wouldn't be at all surprised.
> > Web browsers don't send data back unless the field is editable, and if
> > the JSF implementation (of any brand) doesn't see data for a required
> > field then it has to complain.
>
> Actually, that hasn't been my experience. Fields that are *disabled* will
> not be included in the POST, but if a field is not disabled, but is
> readonly, it should still be included. (That's what the HTML spec requires,
> too.)
>
> Craig
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
