I've created a jQuery form that people can fill in. When they're finished, they can click one of two buttons to post the form to a PHP file. The PHP file processes the data in the form and put it into the database. The database then has some triggers, and the data is output.
What I'm wondering is if I should submit to the same PHP file regardless of which button they press and just use conditional statements inside the PHP file? Or is it cool if I use a different PHP file: one for either button?
I'm also using the PHP wordwrap() function with <br> as an argument. I'm wondering if I should just be using CSS to word wrap because it may cause problems with handling the data form within MySQL.
If the logic triggered by the two buttons is largely similar, then a single script makes sense - you only have to special-case whatever minor bits are different between the two.
If the two logic paths are fundamentally different, then it may make more sense to have two separate scripts. The choice is up to you.
As for wordwrap, generally you should alway store data in its "raw" format, and only do such processing upon retrieval for display. This is especially true if the data will be used in multiple output formats: plain text, html, pdf, excel, etc... Each has its own word wrapping rules/requirements, and forcing your data to be stored in html-style means you'd just have to undo all that work when dealing with one of the other targets.
Six of one, half dozen of the other on the method. I personally progressively enhance my forms to use Ajax submission to an "AjaxDispatcher" that processes ALL form submissions, but that's entirely preference.
With the PHP, be thinking about the worst case scenario--if someone gets some bad info through or the DB fails, how am I going to tell them of the problem? That's why I use the Ajax method, with built-in return methods for easy notification. It can be done server side too to avoid ajax, it's just not as quick for the user or pretty.
Definitely don't forget the form pre-processing, which is made much easier via jQuery inline validation It makes for more user-friendly feedback about form issues and doesn't "cost" a php hit in the process. It's not a replacement for server-side validation, but a nice added touch.
I would question the need for two buttons. I do UI development in online applications for a living and a recent site "dictated" that we do two buttons for relatively similar paths because the marketing types couldn't understand how similar the paths were. It turned into a giant mess, with multiple different "paths" through the process that just confused the living daylights out of the site's users. Never mind that it resulted in having to write a test routine that had 14 different cases (don't ask!) Depending on your situation, you can draw from hidden fields, combinations of answers, or other methods to achieve a form with just one simple input, which is much more user friendly in the grand scheme of things. It also makes it an easier decision on your part as to how to process the data.
When in doubt, remember that the art of UI is simply making an unfamiliar situation feel familiar to the user despite never having been there before. Now, how many forms have you filled out recently with two different methods to submit, side-by-side?
I wouldn't personally wordwrap a textarea. It could have some unexpected consequences if the user starts resizing your textareas as most modern browsers now allow. HTML actually handles wrapping relatively gracefully, considering it's just markup.
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&.... )
So, I'm new to dynamic web design (my sites have been mostly static with some PHP), and I'm trying to learn the latest technologies in web development (which seems to be AJAX), and I was wondering, if you're transferring a lot of data, is it better to construct the page on the server and "push" it to the user, or is it better to "pull" the data needed and create the HTML around it on the clientside using JavaScript?
More specifically, I'm using CodeIgniter as my PHP framework, and jQuery for JavaScript, and if I wanted to display a table of data to the user (dynamically), would it be better to format the HTML using CodeIgniter (create the tables, add CSS classes to elements, etc..), or would it be better to just serve the raw data using JSON and then build it into a table with jQuery? My intuition says to do it clientside, as it would save bandwidth and the page would probably load quicker with the new JavaScript optimizations all these browsers have now, however, then the site would break for someone not using JavaScript...
Thanks for the help
Congratulations for moving to dynamic sites! I would say the following conditions have to be met for you to do client-side layout (it goes without saying that you should always be doing things like filtering DB queries and controlling access rights server side):
Client browser and connection capabilities are up to snuff for the vast majority of use cases
SEO and mobile/legacy browser degradation are not a big concern (much easier when you synthesize HTML server side)
Even then, doing client-side layout makes testing a lot harder. It also produces rather troublesome synchronization issues. With an AJAX site that loads partials, if part of the page screws up, you might never know, but with regular server-side composition, the entire page is reloaded on every request. It also adds additional challenges to error/timeout handling, session/cookie handling, caching, and navigation (browser back/forward).
Finally, it's a bit harder to produce perma-URLs in case someone wants to share a link with their friends or bookmark a link for themselves. I go over a workaround in my blog post here, or you can have a prominent "permalink" button that displays a dynamically rendered permalink.
Overall, especially when starting out, I would say go with the more kosher, better supported, more tutorialed, traditional approach of putting together the HTML server side. Then dip in some AJAX here and there (maybe start out with form validation or auto-completion), and then move on up.
Good luck!
It is much better to do the heavy lifting on the server side.
In CodeIgniter you create a view, looping through all the rows in the table adding in the classes or whatever else you would need. There is no reason at all to do this in Javascript.
Javascript is a sickly abused language with unfortunate syntax. Why on earth would you want to load a page, and then issue a AJAX call to load up some JSON objects to push into a table is beyond me. There is little reason to do that.
Javascript (and jQuery) is for end user enhancement. Make things slide, flash, disappear! It is not for data processing in even the mildest of loads. The end user experience would be crap because you're relying on their machine to process all the data when you have a server that is infinitely more capable and even designed for this specifically.
It depends on your target market and the goal of your site.
I strongly believe in using the client side where ever you can to offload work from the server. Obviously its important you do it correctly so it remains fast for the end user.
On sites where no-js support is important (public websites, etc), you can have fallbacks to the server. You end up doubling code in these situations but the gains are very beneficial.
For advanced web applications, you can decided if making JS a requirement is worth the trade of losing a (very) few users. For me, if I have some control over the target market, I make it a requirement and move on. It almost never makes sense to spend a ton of time to support a small percentage of potential audience. (Unless the time is spent on accessibility which is different, and VERY important regardless of how many people fit into this group on your site.)
The important thing to remember, is touch the DOM as little as possible to get the job done. This often means building up an HTML string and using a single append action to add it to the page vs looping through a large table and adding one row at a time.
It's better to do as much as possible on the server-side because 1) you don't know if the client will even have JavaScript enabled and 2) you don't know how fast the client-side processing will be. If they have a slow computer and you make them process the entire site, they're going to get pretty ticked off. JavaScript/jQuery is only supposed to be used to enhance your site, not process it.
You got the trade-off correctly. However, keep in mind that you can activate compression in the server side, which will probably make adding repetitive markup to format the table a small bandwidth cost.
Keep also in mind that writing Javascript that works in all browsers (including hand-helds) is more complicated than doing the same server side in PHP. And don't forget that the "new JavaScript optimizations" do not apply to the same extent to browsers of handheld devices.
I do a great deal of AJAX app development and I can tell you this from my experience. a good balance between the two is key.
do the raw data server-side but use javascript to make any modifications that you would need to it. such as paging, column sorting, row striping, etc.
I absolutely love doing everything in AJAX heh.. but there are some short falls to doing it using AJAX, and that's SEO. search engines do not read javascript, so for the sake of your website's page rank, I would say have all data served up server side and then formatted and made look cool client-side.
The reason I love AJAX so much is because it drastically speeds up your APP usage by the user as it only loads the data you need to load where you need to load it, versus load the entire page every time you do something... you can do a whole bunch of stuff, such as hide/show rows/columns (we are talking about table manipulation here because you mentioned a table) and even with these show/hide actions add delete actions where when you click a delete row or button it deletes that row not only visually but in the database all done via AJAX calls to server-side code.
in short.
raw data: server-side sending to the client the raw data in html layout (tables for table structured data, however I do everything else in divs and other flexible html tags, only do tables for column/row style data)
data formatting: client-side which also includes any means of interacting with the data. adding to it, deleting from it, sorting it differently etc. This achieves two things. SEO, and User Experience (UX).
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.
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.