Hi
This is something complicated. If you disable a link on the server, you
don't want a javascript that enable it on the client side, submit it and
then found that something that you don't expect has happended on the
server, right?. Who manage "disable" attribute? The client or the server?
If an action is performed on the server, the server manage the attribute,
so an Ajax request is mandatory to enable the input. Otherwise it could be
a security hole. The thing to remember here is "never trust on the client".
No matter how intelligent we want the client to be, in cases like this one
the state on the server is the king, and that will not change (because we
can't!).
Regards,
Leonardo
On Jun 10, 2014 10:06 PM, "Karl Kildén" <karl.kil...@gmail.com> wrote:
> Howard, thanks for the links and interest.
>
> In my case I already rewrote all my pages but I still think that error
> message is wrong.
>
> This is our use case:
>
> [X] Use Defaults for everything
>
> Once the user unclicks that checkbox 5 inputs are editable otherwise they
> get default. Since they get default I obviously just want JSF to leave me
> alone and you know behave like they are disabled ;)
>
> That way String fileName ="newFile.txt"; will not be changed and everything
> is smooth.
>
> What I see others complain about is that they have updated the value and
> then disabled yet still want it posted. This is a fundamental
> misunderstanding of how disabled works and differs from my scenario.
>
> In my case there was no reason to do it with javascript though and I did
> not like the solution in place so I fixed it by using f:ajax and
> disabled=#{condition} but had it been a central part of my system I would
> have been more hesitant to use the server side for such a simple operation.
>
>
>
> On 10 June 2014 21:51, Howard W. Smith, Jr. <smithh032...@gmail.com>
> wrote:
>
> > Leonardo, what are your thoughts on this thread? thanks.
> >
> >
> >
> > On Wed, Jun 4, 2014 at 11:43 AM, Karl Kildén <karl.kil...@gmail.com>
> > wrote:
> >
> > > Howard,
> > >
> > > To do that one would need a purpose. I fail to see the benefit other
> than
> > > bending the knee to a JSF limitation.
> > >
> > >
> > >
> > >
> > > On 4 June 2014 16:48, Howard W. Smith, Jr. <smithh032...@gmail.com>
> > wrote:
> > >
> > > > Karl, if Javascript was written to enable field, why is there not
> > > > Javascript to disable before submit?
> > > > On Jun 4, 2014 8:33 AM, "Karl Kildén" <karl.kil...@gmail.com> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > my app recently upgraded from JSF 1.2 had a broken page with this
> in
> > > the
> > > > > log:
> > > > >
> > > > > WARNING: There should always be a submitted value for an input if
> it
> > is
> > > > > rendered, its form is submitted, and it was not originally rendered
> > > > > disabled or read-only. You cannot submit a form after disab
> > > > > ling an input element via javascript. Consider setting read-only
> to
> > > true
> > > > > instead or resetting the disabled value back to false prior to form
> > > > > submission. Component : {Component-Path : [Class: javax.fa
> > > > > ces.component.UIViewRoot,ViewId: /pages/main.xhtml][Class:
> > > > > javax.faces.component.html.HtmlBody,Id: j_id_10][Class:
> > > > > javax.faces.component.html.HtmlForm,Id: f][Class:
> > > > > javax.faces.component.html.HtmlPane
> > > > > lGroup,Id: body][Class:
> javax.faces.component.html.HtmlPanelGroup,Id:
> > > > > contentBody][Class: javax.faces.component.html.HtmlPanelGrid,Id:
> > > > > j_id_2b_p][Class: javax.faces.component.html.HtmlInputText,Id: im
> > > > > portName] Location: /WEB-INF/facelets/admin/profileUploadForm.xhtml
> > at
> > > > line
> > > > > 88 and column 73}
> > > > >
> > > > >
> > > > > I don't understand this limitation. Is there some global flag I
> could
> > > use
> > > > > to make sure not included inputs are seen as unchanged or
> something?
> > > > >
> > > > > cheers
> > > > >
> > > >
> > >
> >
>
