I am quite new to web development and have a task to develop a web application that will basically show the user 5-15 pull down lists on one page, where each selection will limit the choices in all other lists. The user should be able to start with any one of the lists (so no set selection order) and when the user have selected something in each list or all parameters are otherwise locked by previous choices the user has to press the GO button and some calculations will take place, presenting a database selection. Basically it is a muliple parameter product selector application.
The relations between the lists are not simple, and could need calculated fields etc, and one list could affect the content of several others. The database behind will be MYSQL, probably a single large table, with perhaps 30 fields and 500-5000 rows. I will be using PHP, JavaScript and perhaps AJAX unless you have a strong reason not to.
I have done some research and found three ways to do this:
Send all data to the browser and handle the filtering etc client side with Javascript.
Send parameters back to the server after each selection and reload the whole form after each selection. Probably a littebit Javascript and most code in PHP.
Use AJAX to change all list content dynamically without reloading the whole form.
Since I am so new to this I have a hard time telling which way to go, what pitfalls there are etc...
I have some conserns:
A. Slow initial loading. Worst for #1?
B. Slow dynamic response. Worst for #2?
C. Complicated programming. Worst for #3?
D. Compatibility issues for different browsers and plattforms. Have no idea of which method is most likely to create problems...better if I use some Framework?
E. Could I even try to make something at least part-working for people with javascript turned off? (like selecting each list on a new page and having to press GO button each time)? (I think I can tell my users they must have Javascript on so no big issue....) Perhaps #2 is best here?
F. I think the specification of "free selection order" means I have to download most of the database initially, so perhaps I should try to avoid that option.....if I keep it I might as well use method #1, or???
G. It would be best to do as much as possible of the selction/filtering in SQL to allow future extensions by building custom SQL code, so that gives a big minus to #1...
H. Other pitfalls etc???
I have found tutorials etc for all three methods, but if you can point to good resources like this I would appreciate it, especially so I dont base my code on examples that are not smart/good/compatible....
1:
http://www.bobbyvandersluis.com/articles/unobtrusivedynamicselect.php
http://javascript.about.com/library/bl3drop.htm
http://www.experts-exchange.com/Programming/Languages/Scripting/JavaScript/Q_20523133.html
2:
http://www.plus2net.com/php_tutorial/php_drop_down_list.php
http://www.plus2net.com/php_tutorial/php_drop_down_list3.php
3:
http://techinitiatives.blogspot.com/2007/01/dynamic-dropdown-list-using-ajax_29.html
http://www.webmonkey.com/tutorial/Build_an_Ajax_Dropdown_Menu
http://www.noboxmedia.com/massive-ajax-countryarea-drop-down-list/
http://freeajaxscripts.net/tutorials/Tutorials/ajax/view/Create_AJAX_Dynamic_Drop_Down_List_using_PHP_-_xajax.html
3+jQuery:
http://remysharp.com/2007/01/20/auto-populating-select-boxes-using-jquery-ajax/
Now to the question: Could anyone experienced in all these methods help me out a bit, with the evaluation of methods 1-3 above so I can choose one and get started on the right track? Also, will I be helped by learning/unsing a framework like jQuery+jSON for this?
Rgds
PM
I'd definitely recommend using AJAX with jQuery its tested in all of the major browsers and has simple calls that will make it a lot faster to code and you wouldn't have the browsers compatibility problems of normal JavaScript.
Send all data to the browser and handle the filtering etc client side
with Javascript.
You mentioned that your table has 30 columns and 500-5000 rows potentially? In that case it would not be a good idea to send that much data when the page loads as: 1. It will make the page slower to load and 2. It is likely to make the browser hang (think IE).
Send parameters back to the server after each selection and reload the
whole form after each selection.
Probably a littebit Javascript and
most code in PHP.
I'm not sure how this differs much from the third approach, but probably you mean that you need to reload the page? In that case it isn't likely to be a good user experience if they need wait for the page to refresh every time a drop down selection is changed..
Use AJAX to change all list content
dynamically without reloading the
whole form.
By far the best approach from a user's perspective as it makes filling out the form simple. Perhaps slightly harder to implement from your end, but as you would likely need to perform the same calculations with each of the solutions - might as well move them to a separate page that can be called by AJAX to retrieve your data. As others have mentioned, using jQuery for all your JavaScript/AJAX stuff is going to make things a hell of a lot easier ;)
My personal recommendation is to go with AJAX.
Raw SQL or not is really a question of what backend you are using.
You need to be able to set the relationships between the different selections. The population of the lists must be able to communicate with your backend.
The real issue here is how you implement the relationships between selections. I have no good answer here, it depends heavily on the backend and your administrative needs. It can be hard coded in PHP or configured via XML or via administrative interfaces and persisted to your database solution.
It's no easy task to make it fully customizable.
The reason why i suggest using AJAX is basically because you need to filter upon any change in any selection. That would mean either download a lot of unused information or a lot of page refresh. Going with ajax gives the user a smooth experience all the way.
jquery is a simpple way to use... You can also try a particular class called xajax..! These will make stuff easier.
Related
I have a dilemma and I guess the best way to solve it is to turn to the community. I have an Add button, that gives you a list of options. Depending on which option you choose it should show a dialog box and a form.
What is the best way to do it?
Have all the forms already coded and delivered and activate the right one (this might mean that I have to repeat a lot of code and it's not an optimized way of doing things)
Load the form through Ajax (this could be a good way if it wouldn't come with the expense of having to fetch the form from the server)
Create it dynamically in Javascript? (the best?)
First one is surely not an option if you have most of the questions same.
Option 2 and 3 have both their plus/minus points.
AJAX Fetching Form
This way, you avoid cluster on the code page, you can hide certain options from users until they select particular option (this can be both good/bad depending on circustances).
Might involve more time in fetching data from another server, but less processing on client side, more on server side.
Dynamic Javascript
Quite opposite of the above, all the form generating rules will have to be in form of JS and thus available in source code. Can cluster it a bit, and not hidden.
More data processing on client side than on server side.
If it was upto me, I would do AJAX one, just because it looks cleaner, but depending on your restrictions/tolerance, you may go for 3 as well.
Second option is same with the first one; to fetch the right form, you must have forms already there.
Third option is good but it is not so edit-friendly. You will come to your code after 3 weeks and BOM!
I can recommend you to AJAX one, even if you write that much of code. But pay attention to this
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&.... )
This is a technical design question more then a syntax question.
I have a large page with 9 forms corresponding to different tables. I've wrestled with the design and I there's no way out I have to send all the forms via ajax to the server for processing. There are lots of interrelations. I can't combine the forms into one large one either. So the question is what's the best way to send a lot of forms via ajax. To further complicate the issue there are dynamic forms with fields with same names.
I'm trying a technique of:
1. serializing each form,
2. prepending the form name to each field name
3. combining the serialized version of the forms into one
4. posting that combined serialized form to the server as one
5. breaking them apart on the server side into separate arrays and then finally doing the application logic
I just don't know if there's a tried and true easier solution and I'm making a mountain out of a mole hill
If there's genuinely no way to redesign the page, then your solution seems simple and straightforward to me, not at all "mountain"-ish. To me, though, your description of the page screams "redesign," though of course I don't have enough information to work with.
One such redesign would be to send field changes to the server as they happen, rather than waiting and submitting the entire thing. The server side can hold them as "pending" if you need the user to explicitly commit the whole thing when they're done. But that depends on expense of server resources, etc.
You should be able to send 9 separate AJAX requests without hassle (assuming that a: each doesn't rely on the response of another, and b: this isn't something which happens all the time).
Using your javascript library (you are using one, right??) just loop through your forms and AJAX submit each one. I think it'll probably only process probably 2 at a time, but if that's not a problem to your design, then all should be sweet.
It would certainly keep the PHP/Server-Side part of the equation much much simpler.
If you were working with a high-traffic site, then you'd probably want to reduce the number of requests being made, but chances are your current setup will work sufficiently well.
I'd prepare a javascript dispatcher which would smartly do the job of posting the data. So when the submit button is pressed it would collect all the data needed, and then send the data to the appropriate controllers on the server side.
It could block the form, in the meanwhile, or display a "Processing..." popup.
I have to build a large form for users to fill out in order to apply for graduate study at the college I work for. There will be a large amount of information to collect (multiple addresses, personal information, business information, past school information, experience, etc...) and I want to know the best way to handle all this. I'm going to be using PHP and Javascript.
Are there any helpers or pieces of frameworks that I can use to help with the building/validation of the form, something I can just pop into my existing project?
Also would like any advice as far as keeping track of a large form and the resulting data.
You need to use multiple pages, and you need to include a mechanism whereby users can leave, and come back and fill out the rest of the form later (or if they're accidentally disconnected). Otherwise you're going to have all sorts of user issues, not due to your service, but because they're using computers and internet connections that are flaky, etc.
Survey software is probably a reasonable approximation of what you're doing, and there are survey packages for most PHP CMS's. Are you building this from scratch, or do you have an existing CMS underneath?
-Adam
A few tips, without knowing all the specifics of your form:
Don't show the user everything at once - this can be accomplished by multiple pages, or by selectively showing/hiding elements on the form as the user progresses through it. Provide contextual navigation that says "You're on step 3 of 10" so the user can get a sense of where they are in the form and how much effort is required to finish it.
Providing a mechanism to save and return later is a fantastic idea. If possible, provide a link to an email account of their choosing - you want to make this component as easy to use as possible, and requiring them to fill out an additional username/password to retrieve their data is just another barrier to completion.
Only ask for what you absolutely need. Yes, you're going to have to fight some political battles here - everyone wants as much as they can get. One way to combat this (especially effective when you have pressure from multiple groups) is to build out some prototypes: 1 with EVERYTHING and one with several sections reduced or removed. Have stakeholders from each group fill out both of them and measure their time to completion or roll-throughput yield. When you've got completion data, and they realize how much every other group is asking for (in addition to their group) they are easier to work with. In short, remove as much as possible - let the user go back later to provide more details if they wish.
Write down all your inputs on index cards and see how they logically fit together. More often than not you will find more efficient groupings or orderings. More than likely you will come up with much more usable ideas. This is extremely important when converting paper forms to online forms. Usability.gov has a fantastic case study on this topic.
A List Apart have an article on building sensible forms that is a good read
Why does the form need to be large on the first instance? Can't you trim it down to the bare essentials for the account and provide a way for them to come back later to flesh out the rest of the details?
For form validation, pop a gander on the jQuery validation plugin, Validation
Well I agree with Adam but I have some advise for you.
If I were you, I would create some virtual hidden tabs instaed of multiple forms with a next button.
You can create some which can control by javascript. First show the first one which will collect personal information like Name,Birthday,email, and etc... .
Once user filled them out and clicked on next button,hid this and show the other which will ask for other information like address and so on.
Once the whole dive compeleted, at the last div put a submit button which will submite the whole information to the server at once.
By why do so?
User will not get shocked becuase will not see a long form at each time and will fill out with patient.
You hit server at once;usually universtites and college's servers are too busy, you better design a form which hit the server least. This could count as performance tip.
Since you will submit the whole data at once, you would not worry about the issue that user will continue to fill out the other pages or not,so you will use less session which still will count as a performance tip.
This way makes your form more interesting and you can called you did something like Ajax.
You can add Javascript form validation to make it more user-friendly, but one thing you should never skimp on is the server-side validation... which has historically been awful in PHP.
One thing that'll make your life a million times easier here is the filter library, especially filter_input_array() since you can build the input validation programmatically instead of having to copy and paste a lot of checks. It takes some getting used to, but it's much, much better than the old way of doing things.
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.