There are many ways to handle forms. one is to simply submit the form and the get variables on php and another one that i'm thinking of, is to send data with ajax and during this process we can show a dialog and show the information about processing the data with a progress bar.
despite the fact that ajax is faster than the standard technique and sometimes it's easier to use why there's a very few websites that are using the ajax method ?
It's not that you shouldn't be using ajax to post forms, is that you have to "double" your work (for small amounts of double). I usually make a form work with normal submit, and then I override it with javascript. That way you have a non-javascript fall-back, and don't leave anyone behind. Also lok at jQuery's $.post and $('#myform').serialize methods.
There is no intrinsic reason that it isn't used more. It's just that for most websites, AJAX isn't really needed.
Javascript, as a language, should be treated primarily as an 'addon'. Your page should work perfectly without using Javascript, AJAX, or any other browser languages.
What should ideally happen, is when you Javascript loads, it puts in an event catcher that when the form is submitted, it returns false and instead submits it using AJAX. If Javascript is not enabled, nothing every submits false, and the form is submitted server side.
This allows the most compatability, and is the reason people discourage having a lot of Javascript in the actual tags like this:
Go
Some people turn off Javascript, and some old browser might have errors with that onClick event. Heck, people might develop new browsers that omit Javascript completely for one reason or another.
The Point is that Javascript should simply be an 'addon' to the web page, not the heart of it.
(Unless it is a Javascript Application, which does absolutely everything through Javascript. Normal forms however are not Javascript Applications)
AJAX is not necessarily faster, it's not necessarily easier to use, and not all visitors will be able to use it at all (in particular those who have disabled JavaScript for some or all websites). It's also not always possible to reliably show a progress bar for the AJAX submission any more than it is for a traditional submission. Finally, since the server-side code will look about the same regardless of which client-side submission method you use, submitting via AJAX is more effort, which is not always justified.
That's not to suggest that AJAX is a poor technology, or that it should be avoided. However, even forms that have the option to submit via AJAX should also support traditional submissions. After that, which forms you choose to enable AJAX submissions for should depend on where you have the budget (or, if it's a pet project, the time) to do the extra work.
AJAX is a relatively new technology, and I'm sure in some applications is difficult to implement. If you're doing down the road of adding AJAX to your application consider Progressive Enhancement.
Related
This is more a question of concept. here is the situation, we have a list of objects, and need to show a modal with a editing/adding form for an object. You have around 10 fields, which is better, to generate the form on the fly with javascipt, to make an ajax call and generate the form with the server language then return it as html and show it, or generate the form inline (when the list is created ) and just show it?
I am not asking on how to do it, i can do it in all of the ways i have described, the question is which of these is cleaner and more efficient by today's standards.
The third option (generate server side) is the best, for two reasons:
People with JavaScript turned off can still see the forms. (Make sure you hide them with JS if you're showing them with JS.)
Screen readers will be able to read the forms.
JavaScript is a great tool to enhance UX, but don't rely on it for things to work.
I would use the "on the fly" method or the third. With the first you may decrease Serverload (it's depending of your user-base and the data) and as the normal user has JS enabled it's not a problem.
The third is good because it doesn't requires Javascript enabled, and so even old or mobile devices can display the form correctly.
The second is IMHO the worst as it requires JavaScript and takes the server under more load.
When you don't have a big user-base which needs this form often then use the method which is easier for you to develop and maintain.
When I first started web development with php, when using POST I would have the page with the form that contained the information and then another php page which the “action” attribute pointed to and hence where the all the processing i.e. database work was done. After making a website with many forms I found that I was building up lots of pages and it was getting quite messy.
Then I started to look for a way to avoid this. I then found that I could post a page to itself and hence halving the amount of pages that I needed to use to submit a form. I did this using the isset() function in php. The problem with this is that the whole page needed to be refreshed.
Even more towards the future I discovered jquery and its use of ajax to submit forms etc. This led me back to me original problem of having too many pages and getting confused with what did what. So now I am wondering (although I’m not quite sure I can make sense of it) if there is a way to combine the two? Can jquery use ajax to process a form which points to itself?
The other options that I was thinking of would be to have one page that I send all forms and actions to, which has all my processing in and determine which section to use based on a switch. I’m not sure of the effects that this would have on performance though.
What views do you have on each of the methods?
What are the pros/cons?
Are any of the methods I mentioned frowned upon/bad practice?
This question has been baffling me for a while now, and so I thought it best to get the thoughts of the experts.
Thanks in advance.
Adam Holmes.
Well the answer is quite simple. Jquery uses AJAX to request pages the same way as you would with a regular form. Thus you can use jquery to post information from the form on the page itself, and then as you would normally with isset() do whatever you want.
The obvious advantage is that you don't need to refresh the page, and everything seems more seamless. However sometimes you will need to refresh anyway, for instance during logging in. The disadvantage is that users with javascript off will not be able to use that form, however from my experience this now mostly applies on mobile devices, and in limited manner even then.
I would say that using jquery/ajax to submit your forms is the way to go, just be sure to provide javascript-less alternative if it is something essential and if you receive a lot of traffic from mobile devices.
Somebody else will probably provide more elaborate answer, so take this just as a little summary.
jQuery can process it, and send anywhere you want :-)
Don't you thinked about using some kind of classes and autoload ( PHP 5 ) ? - it makes choosing in your second option much simpler ( somepage.php?class=Foo&.... )
I have several forms in one HTML page...
I have to filter these forms somewhere... (eg check if all or some form elements have values etc...)
I am using ajax to submit the forms, but i dont know if i should filter it before submitting it to my php file, or filtering it inside the php file?
I want the fastest way for the data to show up....
??????????????
Thanks
Filter in both places. You cannot trust anything the client sends to your server, so always check in a server side script that what they sent is good. But you don't want your client to wait, so check using client side script as well.
Always consider that there are people out there, who have JavaScript deactivated. For them you need to check data at the server side.
Also the checks on JavaScript side could be manipulated (Firebug, etc) so you also have to check the data on the server side for people having JavaScript enabled.
i would at first say that having multiple forms on one page is definitely not the best practice. especially if you're using Ajax to submit forms. use validation on the client-side along with server-side. consider using some framework, which can ease your life and give you some custom solutions.
Why should I bother to use JavaScript for form validation when I still have to use PHP since the user could have JavaScript support turned off.
Isn't it unnecessary?
Update:
Ok thanks for your answers. it sounds like a good idea to have it on the client side too. where can I download good JavaScript validations?
Do you know where I can download a validation script like that one in yahoo when you register an account?
Javascript validation allows your user to be informed of any errors prior to their submitting the form to the server. This saves irritating page-reloads (since on submit the JS catches the event and validates the form, preventing form-submission if errors are found) and minimises the chances of their having to re-enter information again (and again and again...), or leaving prior to completing the form properly. JS validation is not a substitute for server-side validation (since the user can see the JS, and, by saving the page and amending the JS do whatever they want); but it's a convenience for them.
This is simply part of the concept of progressive enhancement, whereby JS provides a mechanism for enhancing the experience for the user, if it's there and turned on, and hopefully makes their interaction with your site pleasant, or, at least, minimally irritating.
Edited in response to OP's question regarding 'where to download a JS validation tool.'
While I can't -necessarily- recommend any one library (I tend to write my own as required, or borrow from previously self-written examples), a Google search threw these options up:
http://www.jsvalidate.com/
Stephen Walther's page, discussing Microsoft's CDN and jQuery-validation, linking to jQuery Validation plug-in:
jQuery.validate (hosted at MS' ajax.microsoft.com subdomain)
jQuery.validate.min
jQuery validate plug-in homepage (bassistance.de).
You should ALWAYS validate in PHP on the SERVER SIDE and validation in JavaScript is CLIENT SIDE validation for user CONVENIENCE. Thanks to validation on client user may find errors in his form without page relodaing. But user may sent form data without data script validation
(for example he may not have JS support in web browser), thus always validate on the server side.
... as courtesy to the users pretty much. Makes life easier for the ordinary users that simply commit human things from time to time.
I recommend you using unified server-side and client-side validation using a framework, since it may avoid confronting the user to data valid on client side but rejected by the server, or the opposite (client side too restrictive).
Following list of framework give information about server/client side validation:
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
It's a matter of whether you want your form (and website as a whole) to be interactive-cum-user-friendly or not. You can just let the server-side do the validations and throw the error back to the users but that would be less interactive and less user-friendly than warning the users before they submit the form (although you still need to validate the inputs on server-side no matter what). Just my 2 cents :P
I recomend to use Javascript for client side and Php for server side
This will make interaction or user friendly site nad reduce reloading page many times in case user submit wrong data
Yes, it is best practice to validate the user input values from both sides client and server side ,
some cases client was disabled javascript or mobile browser that doesn't javascript, remember there is spammers also.
To my mind, only client-side-checking of form input does not work because of security. Imagine you want to check a user password(if "yourpwd" == userinput), with js the user will see the password because it is in the browser-sourcecode .With php, it is not visible because php is for some reason hidden.
When is it appropriate to use AJAX?
what are the pros and cons of using AJAX?
In response to my last question: some people seemed very adamant that I should only use AJAX if the situation was appropriate:
Should I add AJAX logic to my PHP classes/scripts?
In response to Chad Birch's answer:
Yes, I'm referring to when developing a "standard" site that would employ AJAX for its benefits, and wouldn't be crippled by its application. Using AJAX in a way that would kill search rankings would not be acceptable. So if "keeping the site intact" requires more work, than that would be a "con".
It's a pretty large subject, but you should be using AJAX to enhance the user experience, without making the site totally dependent on it. Remember that search engines and some other visitors won't be able to execute the AJAX, so if you rely on it to load your content, that will not work in your favor.
For example, you might think that it would be nice to have users visit your blog, and then have the page dynamically load the newest article(s) with AJAX once they're already there. However, when Google tries to index your blog, it's just going to get the blank site.
A good search term to find resources related to this subject is "progressive enhancement". There's plenty of good stuff out there, spend some time following the links around. Here's one to start you off:
http://www.alistapart.com/articles/progressiveenhancementwithjavascript/
When you are only updating part of a page or perhaps performing an action that doesn't update the page at all AJAX can be a very good tool. It's much more lightweight than an entire page refresh for something like this. Conversely, if your entire page reloads or you change to a different view, you really should just link (or post) to the new page rather than download it via AJAX and replace the entire contents.
One downside to using AJAX is that it requires javascript to be working OR you to construct your view in such a way that the UI still works without it. This is more complicated than doing it just via normal links/posts.
AJAX is usually used to perform an HTTP request while the page is already loaded (without loading another page).
The most common use is to update part of the view. Note that this does not include refreshing the whole view since you could just navigate to a new page.
Another common use is to submit forms. In all cases, but especially for forms, it is important to have good ways of handling browsers that do not have javascript or where it is disabled.
I think the advantage of using ajax technologies isn't only for creating better user-experiences, the ability to make server calls for only specific data is a huge performance benefit.
Imagine having a huge bandwidth eater site (like stackoverflow), most of the navigation done by users is done through page reloads, and data that is continuously sent over HTTP.
Of course caching and other techniques help this bandwidth over-head problem, but personally I think that sending huge chunks of HTML everytime is really a waste.
Cons are SEO (which doesn't work with highly based ajax sites) and people that have JavaScript disabled.
When your application (or your users) demand a richer user experience than a traditional webpage is able to provide.
Ajax gives you two big things:
Responsiveness - you can update only parts of a web page at a time if need be (saving the time to re-load a page). It also makes it easier to page data that is presented in a table for instance.
User Experience - This goes along with responsiveness. With AJAX you can add animations, cooler popups and special effects to give your web pages a newer, cleaner and cooler look and feel. If no one thinks this is important then look to the iPhone. User Experience draws people into an application and make them want to use it, one of the key steps in ensuring an application's success.
For a good case study, look at this site. AJAX effects like animating your new Answer when posted, popups to tell you you can't do certain things and hints that new answers have been posted since you started your own answer are all part of drawing people into this site and making it successful.
Javascript should always just be an addition to the functionality of your website. You should be able to use and navigate the site without any Javascript involved. You can use Javascript as an addition to existing functionality, for example to avoid full-page reloads. This is an important factor for accessibility. Javascript should never be used as the only possibility to reach or complete a request on your site.
As AJAX makes use of Javascript, the same applies here.
Ajax is primarily used when you want to reload part of a page without reposting all the information to the server.
Cons:
More complicated than doing a normal post (working with different browsers, writing server side code to hadle partial postbacks)
Introduces potential security vulnerabilities (
You are introducing additional code that interacts with the server. This can be a problem on both the client and server.
On the client, you need ways of sending and receiving responses. It's another way of interacting with the browser which means there is another point of entry that has to be guarded. Executing arbritary code, posting data to a non-intended source etc. There are several exploits for Ajax apps that have been plugged over time, but there will always be more.
)
Pros:
It looks flashier to end users
Allows a lot of information to be displayed on the page without having to load all at the same time
Page is more interactive.