I'm new to PHP, AJAX, and databases.
But I want to know what experiences programmers think and do.
When using AJAX, do you worry about users who have JavaScript disabled?
Do you have a backup solution? Or is the number of those who have JavaScript disabled so small that it isn't a concern?
Wow I got a lot of opinions, which is good, but I think it's important for me to clarify a bit.
I'm asking specifically in terms of AJAX in websites.
When it comes to JavaScript in my websites, I work with the goal of using it to ENHANCE the experience of the user, but ensure that the core of the site will still function for users with JavaScript disabled.
But from my understanding of AJAX, it IS the core functionality is it not? It communicates with the server or database the way PHP does. So how do you make a fallback for that? Or do you?
Again, if I'm mistaken about the role of AJAX, please forgive and enlighten me.
They key is to understand the viewers you are targeting. If your site is plenty useful without javascript, then it may be worth the extra effort to make a reasonable experience when javascript is disabled. You would have to understand the functionality of your site and targetted viewership to know whether that extra effort was worth it or not. There is no single correct answer here.
If your site isn't very useful when javascript is disabled, then it may not be worth the extra effort to try to do anything beyond tell the users that javascript is required. Why put in a bunch of extra effort (and a lot of extra testing) if those viewers won't be loyal to your site and be regular visitors anyway because the user experience will be fairly undesirable.
So, the answer is it depends a lot on what your site does, who your competition is and who your viewers are. Though people on SO like to argue with me in this regard (out of the purity of every web site should work for all - I think), it is getting harder and harder to justify the business case for the extra work for making many sites work without javascript these days. It, of course, depends upon the specifics of your site, competition and viewers. In my book, it is by no means a given that you should make every site work without javascript enabled.
If you Google, you can find articles that discuss how many users have Javascript disabled. This Yahoo article from mid 2010 says that they saw .25% - 2% of users with JS disabled.
As for Ajax specifically, there is no like replacement or fallback without Javascript. If you have a design that depends upon using Ajax for communicating with your server, then that design will require Javascript - period. Your only alternative would be to have a non-Ajax design (a more traditional page request from your server with one URL for one static page) that could be served instead that did not use Ajax. If your other design used and depended upon Ajax, this non-Ajax design would be a significantly different design and implementation.
When creating a website, the key is to create a site that works regardless of the user's settings. Your site's design and functionality should not be dependent on the user having Javascript enabled.
Just make a container around everything and set the display to none using CSS. Set "onload" to a JavaScript function that sets the display back to "block". This way, only stuff in the "noscript" tag will show when JavaScript is disabled. You can use it to say that your web application uses AJAX, ect. I like to showcase a privacy policy that NoScript users will be happy about on these fallback pages.
Related
So I'm trying to make my own mini CMS, and just for my knowledge once I get it good enough, and I know enough, I'd like to sell it. Now for licensing, I know there's tons of licensing scripts you can pay for, but would the following be advisable?
I'd like to plant a script hidden in my CMS where instead of checking for some sort of key, it checks if your domain is allowed to run the CMS by running it past the main CMS database. Now I have two questions.
1.) Could I encrypt the code, so if I wanted it to redirect to a page where it just says "CMS Deactivated" For example, so that people don't go through the code just ctrl-f searching for the key text?
2.) I was going to reach the domain name by doing the following, $_SERVER['SERVER_NAME']. Is that going to be a reliable way of checking the domain? IE. Will IIS pick up on it?
I'm not trying to completely extinguish cracking of the CMS, I know that is impossible.
Maybe you should consider housing the whole thing on your own servers and making the content accessible via a REST API. You can certainly restrict and control that way.
Providing a CMS with source code to any client opens you to evaluation and cleansing. Not saying there's no way, but I am saying it may be easier for you to provide the content via REST than to write perfect security. Especially if you're asking this question.
As I said in my comment, I think worring about money is irrelevant for now, but here's some information for you to learn from.
1.) I haven't found an encryption solution that works. Any will require you to install additional PHP components (and no one wants to deal with that when there are plenty of free CMS's out there). There is code obfuscation, but that's iffy at best.
2.) According to this page, that should work on IIS!
Again, to re-iterate: This is not a request to program anything for me. I am looking for more experienced web developers to tell me if my idea is really doable, as it involves some pretty tough issues (at least, I think so). Please, if this post is to be closed, could I at least get a little advice on where I should be posting instead first?
Imagine: You visit a website (say malonssite.com). You sign in, you get a double-paned window. Left side is chat list(think FB buddy list). Right side is a "browser".
The chat list is populated by other people who have signed into malonssite.com AND are visiting the same page as as you using the "embedded" browser.
Each user has the ability to "allow followers", at which point whatever site they visit, all their followers "follow".
Image sketch:
My abilities:
PHP
MySQL
Javascript (node.js included, but that's more serverish I guess)
I've done long polling and ajax, but this gets complicated. I am thinking something like this might be best done in flash? Or maybe an oldschool Java applet? I am just not sure.
I am pretty confident I can make this thing on my own, I am just not sure what technology to use. I usually hit stumbling blocks in each area, normally along the lines of the same origin policy. I know that JSONP can get around the SOP, however is it powerful enough to do what I want? I am not familiar enough with it.
Sockets in general (websockets, flash sockets, etc) and node.js are pretty new to me, and I think they somehow hold the answer, I am just looking for some verification.
Thanks!
As I see it, you'll just need an iframe with a JScript asking its src and sending it to the server. So basically the user will stay on your own domain, browsing other web sites in the iframe and you will have no cross-origin-request issues.
You could use ape engine for the server side, which is exactly meant for this sort of things.
It is very possible.
Simple? no. But possible.
HTML/CSS/JS will easily take care of the front end layout,that should be elementary.
Node.js is a good option, and would be best suited if you know that traffic will be heavy.
If traffic won't be heavy, i guess php is OK.
And you will also need a backend database...again, depends on how many users you think you'll have. nosql ones would suit well, although oracle just claimed they 'exponentially' improved mySQL performance.
But think about this idea carefully. The concept of allowing users to communicate if they're on the same page is neat - but they'd have to browse a site within your site....furthermore, you have to account when the user presses next/back button in the browser.
perhaps you could make a fork of firefox and implement this as a software
did you mean something like talkita
or any other solution on google search "chat with others on same page"?
some of them also allow followors (subscribers) etc..
have a look, maybe youll get an idea.
please forget about flash and java applets...
i think this is a great idea and i hope you can get it to work.
I would really use NodeJS + (Socket.IO | SockJS) for the server-side and realtime communication, all your SOP problems will be gone.
As for the client side, just take care of cross browsing the javascript and css
For data persistence, some kind of nosql implementation: mongoDB or couchDB for example
So, it's been about 3 years since I wrote and went live with my company's main internet facing website. Originally written in php, I've since just been making minor changes here and there to progress the site as we've needed to.
I've wanted to rewrite it from the ground up in the last year or so and now, we want to add some major features so this is a perfect time.
The website in question is as close to a banking website as you'd get (without being a bank; sorry for the obscurity, but the less info I can give out, the better).
For the rewrite, I want to separate the presentation layer from the processing layer as much as I can. I want the end user to be stuck in a box and not be able to get out so to speak
(this is all because of PCI complacency, being PEN tested every 3 months, etc...)
So, being probed every 3 months has increasingly made me nervous. We haven't failed yet and there hasen't been a breach yet, but I want to make sure I continue to pass (as much as I can anyways)
So, I'm considering rewriting the presentation layer in Adobe Flex and do all the processing in PHP (effectively IMO, separating presentation from processing) - I would do all my normal form validation in flex (as opposed to javascript or php) and do my reads and writes to the db via php.
My questions are:
I know Flash has something like 99% market penetration - do people find this to be true? Has anyone seen on their own sites being in flash that someone couldn't access it?
Flash in general has come under alot of attacks about security and the like - i know this. I would use a swf encryptor - disable debugging (which i got snagged on once on a different application), continue to use https and any other means i can think of.
At the end of the day, everyone knows if someone wants in to the data bad enough, their going to find a ways in; i just wanna make it as difficult for them as i can.
Any thoughts are appreciated.
-Mario
There are always people who, for one reason or another, don't install the Flash plugin. Bear in mind that these are distinctly in the minority. Realize also that some people still refuse to enable Javascript. The question you have to ask yourself is whether this small group is enough to get you to move off of some newer technologies.
If the answer to that is yes, you will have to resort to vanilla HTML form processing, sending everything to the server for validation, etc.
If the answer is no, don't be afraid to use Flex. It works fine with https protocol, and is as secure as you want. That said, I wouldn't use it for username/password validation on the client; that information should always be encrypted and sent to a secure server. But validation of other types of field (phone number, etc.) shouldn't be a problem.
There are definitely people who don't have Flash installed and yes, there are people who have JavaScript disabled. But no matter whether you develop for the common denominator which is plain HTML forms or if you go high end, e.g. Flex or AJAX, never ever rely on the client to validate the inputs. It's a good first step, but everything that comes from the client, be it Flash or Ajax or Silverlight or whatever, could be forged.
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.
I have a doubt: -
Is there any standard/convention that when should I use "Smarty templating" and when should I use Javascript Ajax calls to produce the content? I can use Ajax/Javascript calls to produce the content dynamically.
My application uses both Ajax and Smarty, but I want to set a rule for developers
You should only use AJAX calls to load dynamic data that is not known at the moment the page is loaded. For example, when you click the "comments" link for a given question/answer on Stack Overflow, an AJAX call is made to dynamically load the data. This is a result of the user clicking the comments link, not a result of the page loading. You don't know that you should show those comments at the time the page is loaded, so it is appropriate to make an AJAX call in this case.
You should use templating to show any data that is known at the moment the page is loaded. It makes it easier to deal with people that have Javascript disabled (I know, not a lot), and it provides a clear separation of logic from presentation. Another important benefit of using templating is the fact that is can significantly decrease the number of HTTP requests made from the client's browser.
This is especially important in the mobile browsing world where latency, not bandwidth, is your biggest obstacle. In mobile Safari, for example, a single HTTP request to a Smarty-templated page will load significantly faster than a request to load a Javascript-templated page that makes five or six additional HTTP requests. This is especially true when using EDGE, 3G, and other non-wifi mobile data services. In fact, this is so important that it is the first guideline in Yahoo's Best Practices for Speeding Up Your Website.
Ideally, you should also gracefully degrade functionality when Javascript is disabled. A good example is an auto-completing search box. It's really cool to have suggested search terms magically appear as you type, but if you turn off Javascript, you still have a functional search box. That's a classic example of a good degradation in service. Stack Overflow generally does a great job providing a solid non-Javascript experience. One place it falls short is in the comments. When Javascript is disabled, only the most popular comments are displayed, and posting new comments is disabled.
Unless absolutely necessary, you should think of Javascript as a bonus feature that might not be enabled, not as something that should be used to construct critical pieces of your website. There are obviously exceptions (some things just can't be done without Javascript). You'll notice, for example, that Stack Overflow is very usable with Javascript turned off. You won't get the real-time updates when new answers are posted, or fancy real-time Markdown previews, but the core functionality is still there. All the "heavy lifting" is done with HTML and CSS. Javascript is just icing (admittedly very good icing) on the cake. This is kind of a side note, but it's important enough to mention.
It probably depends on what sort of work you are doing in your templates. Personally, I hate doing a lot of heavy style/layout stuff strictly in Javascript. If you can load the bulk of your layout via. Smarty and just change specific bits of data (just the data, not the markup/style, if possible) that might be a good place to start with for standardizing within your own developer team.
Use templates for server-side generation and DHTML/AJAX for anything after the original page load (not using a refresh). Even then, the server response for the AJAX call itself can be assembled with a template, which may work best for any non-trivial content.