You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Titi Wangsa <bl...@gmail.com> on 2007/03/01 10:49:59 UTC

Re: Why does JSF submit through JavaScript?

i'm new to jsf, i'm using the myfaces 1.1.5 and somehow there is javascript
code in my commandbutton, did i do something wrong
the code is something like this
            <h:commandButton id="autoRegisterJobseekerFormSubmit"
                action="registerProfile" />
gets rendered as

<input id="autoRegisterJobseekerForm:autoRegisterJobseekerFormSubmit"
name="autoRegisterJobseekerForm:autoRegisterJobseekerFormSubmit"
type="submit" onclick="if(typeof
window.clearFormHiddenParams_autoRegisterJobseekerForm!='undefined'){clearFormHiddenParams_autoRegisterJobseekerForm('autoRegisterJobseekerForm');}"
/>
more javascript functrions, 2 or more follows
    function clear_autoRegisterJobseekerForm()
    {

clearFormHiddenParams_autoRegisterJobseekerForm('autoRegisterJobseekerForm');
    }

    function clearFormHiddenParams_autoRegisterJobseekerForm(currFormName)
    {
        var f = document.forms['autoRegisterJobseekerForm'];
        f.elements['autoRegisterJobseekerForm:_idcl'].value='';
        f.elements['autoRegisterJobseekerForm:_link_hidden_'].value='';
        f.target='';
    }

    clearFormHiddenParams_autoRegisterJobseekerForm();

Re: Why does JSF submit through JavaScript?

Posted by Simon Kitching <si...@rhe.co.nz>.
Titi Wangsa wrote:
> i'm new to jsf, i'm using the myfaces 1.1.5 and somehow there is 
> javascript code in my commandbutton, did i do something wrong
> the code is something like this
>             <h:commandButton id="autoRegisterJobseekerFormSubmit"
>                 action="registerProfile" />
> gets rendered as
> 
> <input id="autoRegisterJobseekerForm:autoRegisterJobseekerFormSubmit" 
> name="autoRegisterJobseekerForm:autoRegisterJobseekerFormSubmit" 
> type="submit" onclick="if(typeof 
> window.clearFormHiddenParams_autoRegisterJobseekerForm!='undefined'){clearFormHiddenParams_autoRegisterJobseekerForm('autoRegisterJobseekerForm');}" 
> />
> more javascript functrions, 2 or more follows
>     function clear_autoRegisterJobseekerForm()
>     {
>         
> clearFormHiddenParams_autoRegisterJobseekerForm('autoRegisterJobseekerForm');
>     }
>    
>     function clearFormHiddenParams_autoRegisterJobseekerForm(currFormName)
>     {
>         var f = document.forms['autoRegisterJobseekerForm'];
>         f.elements['autoRegisterJobseekerForm:_idcl'].value='';
>         f.elements['autoRegisterJobseekerForm:_link_hidden_'].value='';
>         f.target='';
>     }
>    
>     clearFormHiddenParams_autoRegisterJobseekerForm();
> 
> 
> 

This code is not *submitting* using javascript, it is just clearing a 
few variables. Even if javascript is disabled in the client browser the 
submit should still happen ok.

This code is a little different from 1.1.3 (which is what I'm currently 
using) but it seems clear enough. The normal way to submit a form in 
HTML is via a button. However JSF offers an additional feature: 
h:commandLink which allows a form to be submitted via a link. 
Unfortunately HTML doesn't support this directly so the only way to 
implement this is by attaching javascript to a link that sets a hidden 
field then submits the form. All this code is doing is clearing out any 
data left behind by this. Clearly if the browser doesn't have javascript 
enabled then these hidden fields can never be set, so the fact that they 
are never cleared doesn't matter.

I agree the output looks far from optimal; I would have thought that the 
input control could look like:
   <input ... onclick="return _myfaces_tidyup(this);"/>
Even better the page could contain some javascript that automatically 
searches for tags rendered from JSF components and dynamically attach 
the tidyup script, although that might have problems with race 
conditions as users can click on buttons before the page is completely 
rendered. However if we want this, we need to submit code patches!

Cheers,

Simon

Re: Why does JSF submit through JavaScript?

Posted by Mike Kienenberger <mk...@gmail.com>.
On 3/1/07, Jörn Zaefferer <jo...@googlemail.com> wrote:
> I guess it came from my frustration with JSF in general: While the
> programming model is great, I don't like the "output" JSF produces. While
> that may be acceptable for prototyping and intranet application, I wouldn't
> want to have that on a public website. My understanding of JSF and MyFaces
> is still too small to really understand why that is necessary or how it
> could be improved.

If you don't like the generated html, it's easy enough to substitute
your own renderkit, either completely or component-by-component.

Re: Why does JSF submit through JavaScript?

Posted by Jeff Bischoff <jb...@klkurz.com>.
Hasn't it branched already?

I see you commmited those changes you talked about this morning. Thanks! :D

Martin Marinschek wrote:
> Hi *,
> 
> I've got a solution for that rather messy javascript in
> command-buttons on my box - but I don't want to commit until tomahawk
> has been branched - just to be on the safe side of things...
> 
> regards,
> 
> Martin
> 
> On 3/2/07, Mike Kienenberger <mk...@gmail.com> wrote:
>> Jörn, patches are welcome :-)
>>
>> On 3/1/07, Jörn Zaefferer <jo...@googlemail.com> wrote:
>> > Thanks for your reply.
>> >
>> > At some point I'd like to commit my FacesUtil class to the project, 
>> which
>> > contains several extremely handy shortcuts for the rather noisy JSF 
>> API.
>>
> 
> 



Re: Why does JSF submit through JavaScript?

Posted by Martin Marinschek <ma...@gmail.com>.
Hi *,

I've got a solution for that rather messy javascript in
command-buttons on my box - but I don't want to commit until tomahawk
has been branched - just to be on the safe side of things...

regards,

Martin

On 3/2/07, Mike Kienenberger <mk...@gmail.com> wrote:
> Jörn, patches are welcome :-)
>
> On 3/1/07, Jörn Zaefferer <jo...@googlemail.com> wrote:
> > Thanks for your reply.
> >
> > At some point I'd like to commit my FacesUtil class to the project, which
> > contains several extremely handy shortcuts for the rather noisy JSF API.
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: Why does JSF submit through JavaScript?

Posted by Mike Kienenberger <mk...@gmail.com>.
Jörn, patches are welcome :-)

On 3/1/07, Jörn Zaefferer <jo...@googlemail.com> wrote:
> Thanks for your reply.
>
> At some point I'd like to commit my FacesUtil class to the project, which
> contains several extremely handy shortcuts for the rather noisy JSF API.

Re: Why does JSF submit through JavaScript?

Posted by Jörn Zaefferer <jo...@googlemail.com>.
Thanks for your reply.

Considering that the first target of MyFaces was to implement the JSF
specification, I guess there are a lot of areas that can be improved. At
some point I'd like to commit my FacesUtil class to the project, which
contains several extremely handy shortcuts for the rather noisy JSF API.

Currently I'm happy I got MyFaces with Facelets working on both Websphere
Portal 5.1 and 6, with IBM's portlet wiring.

Regards
Jörn

Re: Why does JSF submit through JavaScript?

Posted by Simon Kitching <si...@rhe.co.nz>.
Jörn Zaefferer wrote:
> 
> 
> On 3/1/07, *Simon Kitching* <simon.kitching@rhe.co.nz 
> <ma...@rhe.co.nz>> wrote:
> 
>     I believe it is (see my earlier reply), and that all the javascript is
>     doing is ensuring any garbage left behind by h:commandLink tags is
>     cleaned up (hidden fields _idcl and _link_hidden_).
> 
> 
> Ok, but that doesn't explain the JavaScript for an input of type submit. 
> From what I understood so far, the commandLink copy some values to 
> hidden fields before triggering the form submit. So by clicking a submit 
> button, those hidden fields shouldn't have any values...

True in most cases.

However it is possible for someone to click a commandLink, then click a 
submit button (before the response is received). In this case the second 
request will have the hidden field set to the command-link properties 
which will have unexpected consequences for the user.

I'm only guessing, but presume this is the reason for clearing these 
fields even from a submit button. I can't think of another one offhand; 
as you say, in normal use these should be empty.

> 
> I guess it came from my frustration with JSF in general: While the 
> programming model is great, I don't like the "output" JSF produces. 
> While that may be acceptable for prototyping and intranet application, I 
> wouldn't want to have that on a public website. My understanding of JSF 
> and MyFaces is still too small to really understand why that is 
> necessary or how it could be improved.

I'm not too fond of some of the currently generated HTML/script either. 
I *think* I can see significant potential for improvement. However until 
I have time to actually code and test a patch to fix it I'm reluctant to 
criticise. There may be reasons that it is the way it is, which I would 
find out when I try to implement an alternative. Or the code author may 
just have been short of time to optimise.

Cheers,

Simon

Re: Why does JSF submit through JavaScript?

Posted by Jörn Zaefferer <jo...@googlemail.com>.
On 3/1/07, Simon Kitching <si...@rhe.co.nz> wrote:

> I believe it is (see my earlier reply), and that all the javascript is
> doing is ensuring any garbage left behind by h:commandLink tags is
> cleaned up (hidden fields _idcl and _link_hidden_).


Ok, but that doesn't explain the JavaScript for an input of type submit.
>From what I understood so far, the commandLink copy some values to hidden
fields before triggering the form submit. So by clicking a submit button,
those hidden fields shouldn't have any values...

Your comment is a little rude; constructive criticism is fair, but
> accusations of incompetence are not.


Sorry for sounding rude, I'll try to do that better.

I guess it came from my frustration with JSF in general: While the
programming model is great, I don't like the "output" JSF produces. While
that may be acceptable for prototyping and intranet application, I wouldn't
want to have that on a public website. My understanding of JSF and MyFaces
is still too small to really understand why that is necessary or how it
could be improved.

This may be for compatibility with various browsers. Have you tested
> your proposed alternative against IE5, IE6, IE7, Firefox, Opera and
> Konqueror?


>From my experience the trick is to just check for window.property when
checking for a global variable (instead of typeof property...). I haven't
seen a case where that doesn't work, though I don't test reguarily in
Konquerer.

Re: Why does JSF submit through JavaScript?

Posted by Simon Kitching <si...@rhe.co.nz>.
Jörn Zaefferer wrote:
> I got the feeling that this was the result of bad knowledge 
> browser-behaviour, HTTP and HTML and JavaScript. I still have no idea 
> why the form isn't just submitted as is, using the name and value of the 
> submit to determine which button was clicked.

I believe it is (see my earlier reply), and that all the javascript is 
doing is ensuring any garbage left behind by h:commandLink tags is 
cleaned up (hidden fields _idcl and _link_hidden_).

Your comment is a little rude; constructive criticism is fair, but 
accusations of incompetence are not.

> 
> In addition, the JavaScript could be reduced. "if(typeof 
> window.clearFormHiddenParams_Blah!='undefined')" can be written as 
> "if(window.clearFormHiddenParams_Bla)". Considering that the code is 
> repeated all over the place, that can make quite a difference.

This may be for compatibility with various browsers. Have you tested 
your proposed alternative against IE5, IE6, IE7, Firefox, Opera and 
Konqueror?

Regards,

Simon

Re: Why does JSF submit through JavaScript?

Posted by Jörn Zaefferer <jo...@googlemail.com>.
I got the feeling that this was the result of bad knowledge
browser-behaviour, HTTP and HTML and JavaScript. I still have no idea why
the form isn't just submitted as is, using the name and value of the submit
to determine which button was clicked.

In addition, the JavaScript could be reduced. "if(typeof
window.clearFormHiddenParams_Blah!='undefined')" can be written as "if(
window.clearFormHiddenParams_Bla)". Considering that the code is repeated
all over the place, that can make quite a difference.