I just can't find a satisfying way to handle the Browser's History. Sure there are lovely plugins like History.js, which works fine for smaller things. But let me give you an example:
I have a multi-paged form that asks the user for different things. After every submit to the next page (actually the same, it just changes the view depending on HTTP-POST variables), there are some animations and changes on the page:
the main content changes to the next form (with a slideUp/slideDown)
the progress bar changes it's state with an animation
below this bar, some information about some of the input fades in
So that's pretty basic right now, but I'm already struggling, because all the animations (the last 2 parts) are different on every state (different div, different input-sources) and I have no idea how to make them so generic, that I have not to specify them separatly.
I could live with that though, but when a user hits the back button I have to redefine all those animations again (in reverse). The content-load sure is no problem, it basically just reloads the file with an ajax-load:
I execute a pushstate with the input data as the stateObj on submit
so I can execute the content-load in the bound 'statechange' event
As said though, the rest drives me insane.
I would highly recommend grabbing and learning Backbone.js. It plays great with jQuery and sets up your website in a modified MVC pattern. It also has a great system for handling URL changes and executing the appropriate code.
As for sliding, if you want to reverse animations, that could be a bit of a pain to keep track of. What I did with my app when I was sliding between screens is instead of sometimes sliding up and sometimes sliding down, I would always move the element in the DOM that I was sliding to so that it was after the element I was sliding from. That way the slide was always going in the same direction and my animations wouldn't get all goofy.
You could try JavaScriptMVC, which includes jQuery. Not sure if it meets your exact requirements but it is JavaScript and MVC...
Although not quite strictly MVC (of which there are several for JavaScript) I think backbone js is a great framework, that is based around the concepts of MVC, but re-worked to better suit the JavaScript language and environment.
Well after a lot of punching around and stuff, I decided to degrade to the simplest and best solution for my problem: Using the basics.
Instead of animating everything backwards/forwards when the user hits the back/forward buttons, I just reloaded the whole site with ajax so I can use the HTML/PHP fallback with the stateObj of the selected site.
Problem with History.js though is that it can't distinguish between pushState and back/forward button in the onstatechange-event. So I degraded from History.js to the standard W3C behaviour with pushstate. There will be an update with 1.8.0 that allows to distinguish between internal and external statechanges.
Thanks for all the answers, but I guess this is the most accurate way of dealing with it, while using MVC alone doesn't solve the problem - why I didn't accept any other answer!
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.
I recently created a website where a user logs in and accesses various forms and other things. I was wondering, after login, how can I change the php code so that it automatically modifies a portion of the page making it personal? Here is a screen shot of the front end.
I would like the login form portion disappear and then have a new layout replace it. Would I use Javascript or AJAX. If either, does anyone have any guidance on how to go about doing this project?
It sounds like one of your goals is to minimize page refreshes, possibly having none at all.
Your main challenges include:
1. Managing possibly lots of unrelated DIVs, which make up your functional segments.
2. Speed issues - lots of code crammed into one page.
3. All input sent asynchronously (things get complicated very fast when you want to do EVERYTHING with AJAX!)
As far as your initial login menu, you can fade that out by wrapping it in a DIV and calling jQuery's fadeOut() function on it. To update PHP components without refresh, that's where your AJAX comes in. You're going to want to use a little of each and like therealsix said, they're all essentially Javascipt at the core.
My best advice would be to spend a big chunk of your time dedicated to this project in the planning stage. Understand how you are going to deal with DIVs crashing into each other. Develop an overall table layout that gives you flexibility concerning where content DIVs come in and out. Think about which ones are replaceable at any given time. Study up on modular coding.
That's broad advice because I don't know what exactly the project entails, so if you have any specific issues, let me know.
I would say neither. If you're going to change the whole page, just redirect to a new page.
If you needed to do this without a page reload you would need to use javascript and AJAX (ajax in some sense is javascript). Then I would recommend you look at the jquery functions (http://api.jquery.com/load/)
I've got a PHP-driven site that has a recordkeeping form. The user chooses a battle in the first dropdown, then the winning side in the second. Currently the winning side options are only Side 1 , Side 2 corresponding to which was listed first in the battle setup. The submission has an "are you sure?" step to make sure they have a chance to correct the side if they chose the wrong one.
I'm the first to admit this is annoying, and want to make the winning side dropdown populate automatically based on the battle selected. I've been told this is bread-and-butter AJAX stuff.
My concern, though, is how to maintain functionality for JS-disabled users. Can this sort of dropdown auto-population carry the original PHP fixed values behind it?
Sorry for the lack of code. I haven't yet begun to study JavaScript and AJAX methods, just considering the theoretical applications to my site at this point...
Thank you.
You could do it like this.
When the page loads, if javascript support is enabled, the button/link which does the post is hidden and the site works with javascript otherwise the button/link is displayed and the site works without js
I'm not the AJAX guru but your idea sounds good. You can of course populate a drop down list and JS enabled browsers can remove/repopulate/alter/... this field whatever they like by loading data via an AJAX request.
With a little bit of googling, you should be able to find such already-developed solutions or at least get an idea of what others have done.
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.
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.