I want to make a faq panel when user ask any question it show on the top of division without reloading the page for that i think i have to make a connection with database after every few second. Now the question is that how to make connection without reloading the page and how to show new question ?
You have two options:
Ajax, which allows you to retrieve data from the server with JavaScript, which you can then use to manipulate the DOM. The basis of Ajax is the XMLHttpRequest object, which allows you to retrieve data completely behind-the-scenes in JavaScript. Note that Ajax is limited by the Same Origin Policy, but for what you're describing, that's fine — you'll be loading data from the same origin.
Frames (e.g., iframe elements), which you can load content into by setting their src property.
Of the two, Ajax is much more flexible.
References / further reading:
DOM2 Core
DOM2 HTML
DOM3 Core
HTML5 Web Applications APIs
XMLHttpRequest object
Side note: Although obviously you can use XMLHttpRequest and the DOM methods directly, note that there are cross-browser differences (and outright bugs), which can be smoothed over for you by a good library like jQuery, Prototype, YUI, Closure, or any of several others. They also provide a lot of useful utility functionality, allowing you to focus on the actual problem you're trying to solve rather than the details of the plumbing.
For example, here's how you would send an Ajax request to a server using jQuery and have an element on the page updated with the HTML fragment the server sends back:
$("#target").load("get_the_data.php", {article: x});
That says: Request an HTML fragment from get_the_data.php sending it the parameter article with the value from the x variable, and put that HTML fragment inside the element that has the HTML id "target". That would be a good 10 lines of code if you didn't use a library. Now, that's not a lot, but repeat that over and over (and in the process deal with an IE bug around looking up elements by their id), and you see how it can add up.
I do recommend you read the references above so you know how the libraries are doing what they're doing (it's not magic), but there's no reason not to leverage the hard work people have done to make this stuff easier.
I think what you need is AJAX. It is a way of contacting the server with only partial page refresh. I don't know how it works with php as i use asp.net but here is a link that may help.
It's Ajax turn. What you need is a technology called AJAX. You can find something usable in jQuery library that provides different methods to work with Ajax more easily.
http://api.jquery.com/jQuery.ajax/
You will create a relation with your server-side programming language and your database through a client-side scripting language (Javascript in this case).
This is an example of these realations:
http://jqueryui.com/demos/autocomplete/
You have to look into push/publish/subscription technologies. Few that i know are pubnum and commet
Related
I am using PHP mvc framework (Codeigniter) for my web blog.
I am going to implement Ajax for the first time to see the real benefit myself.
I guess what I've done from the view such as formatting and display result on html page can now be replaced by the Ajax implementation. So I guess the view of the the server side mvc would no longer be used.
With a form validation, it is suggested to gear up with logic for both client and server in case javascript gets bypassed. I guess the same concept applies here with Ajax when javascript is disabled from client browser. I mean, you get no data when it's disabled. What would be the back up solution for this scenario like how validation is handled?
You've asked two questions but I'm just going to answer the first one: can AJAX replace the role a server-side view traditionally had?
In MVC web frameworks the view is a template for converting data passed in from the controller into HTML, however, client-side templating languages have become quite popular and are a perfectly reasonable alternative to rendering HTML output on the server, and they have definite advantages.
Firstly, since you're not sending an entire HTML payload to the client browser but instead just the content, you can save significantly on bandwidth. Generating the HTML client side allows you to transmit only data (like JSON or XML) to the client. The server side view would simply contain script tags pointing to the JavaScript templates and the content payload.
Secondly, since these JavaScript templates can be served up from a CDN, you benefit from the speed of those networks plus caching across pages, so the user is likely only downloading those templates which are unique to a specific page as well as data.
However, there are some disadvantages, such as SEO, although there are some workarounds for that. One option would be to serve up an SEO friendly version of the page to crawlers using a server side view, or simply render your templates server-side using Node.js or Rhino. The beauty of writing templates in a language that compiled to JavaScript is that both the server and the browser and execute them, which can be said for no other language.
I am embarking on part of a project now that has me planning on how to load a dynamic table data from a DB. I have uncovered two basic methods.
I believe that I can use url query strings to communicate with the php backend of my phpbb3 forum. And it can load the appropriate data and ship it off to the user in full static page chunks. So I would have something like /stats.php?page=3&orderby=name&dir=desc.
Or I can just send the same empty page to everyone and the browser can dynamically load anything that the user wants using ajax.
Or some combination of the two.
What is best practice? What are the downsides and upsides of both?
It really depends what you're trying to do. For simplicity's sake, I would say that the first option (just load it with the appropriate query string variables in the URL) is better.
Rendering a page using AJAX is pretty much always more complicated. However, it also gives you much more control over the UI if you know what you're doing. From my experience, if you want your page to be more like a "web app" with dynamic things happening everywhere, it is much easier to simply load JSON data from the server via AJAX and to dynamically create views via some sort of templating system. Otherwise you're stuck with loading the DOM with PHP, and then somehow communicating that data to your JavaScript, either by using data-XXX attributes on DOM elements, having PHP output a JSON string at the top of a page and assign it to a JavaScript variable, etc. It could get very complicated and convoluted.
In your case it looks like you're just trying to allow users to view certain data from your forum. Barring any additional requirements, I would recommend going with the first option because it will be much easier. This is simple enough that you don't seem to need to load anything dynamically.
A good rule of thumb is the more complicated and dynamic your UI, the more you should think about moving to a "web app" framework, and just let the server act as a REST server.
I've built a fairly complex web app (html, javascript, jQuery, php, mySQL) and use several mechanisms for navigating through the site (e.g. anchor/links, submit buttons, window.location, window.open). I'm looking for two things:
What are all the mechanisms possible for moving around a site or a source that will allow me to find such a list
What, if any, documentation standards are there for documenting such actions; something like the flow charts used to document procedural code.
I'm not sure either by what you mean in "thing 1". The best tool to map all the paths is the UML Sequence Diagram.
Services such as Omniture and Google Analytics let you visualize such paths of user navigation. You could explore that option. Basically they work by tracking a page's URL and its referrer URL (accessible via document.referrer) and then making the connection.
If I understand your comment on dj_segfault properly, I'm not even sure you understand the concept of server/client interaction.
I don't think there is an answer to this because the technology is changing all the time and it is different depending on what devices you are using.
You only have to look at Node.js (if you understand the technology) to see that the lines between server and client can be blurred, and that it's just not a simple answer.
The bottom line is in fact there are no navigation "things" unless you program them, and how you program them is your choice depending on requirement.
For example a vanilla link
Google
Can either be static HTML content or echo'ed from a php script which was used to select the data from a database to get the URL and print it. But it doesn't have to be either of these.
If you wanted to navigate to google you could use a button with an onClick javascript or an event listener with data collected by AJAX. It could be derived from other content values on-the-fly or be a string. I could probably imagine 20 different possibilities but that doesn't make them all suitable for the application.
Just keep incrementally improving your project, use this forum to answer specific questions and you'll learn a lot. I did.
I've been trawling SO for a couple of hours tonight looking for some answers, but I've not found anything that really answers what I'm after. My apologies if it has, in fact, been answered already.
I'm designing a new website and I'm trying to decide on the architecture to use to serve the content. In the past, my websites have used PHP feeding data into Smarty templates.
However, recently at my work, I've been working on a Java web application where jQuery was used to retrieve the data from a RESTful API (which returned JSON), where HTML template pages were used as the base and javascript was used (utilising jQuery) to fill in the content.
My question:
The website I'm designing will be in PHP, but would it be better to construct (or use an existing) RESTful API or to continue on as I've done before feeding the data into Smarty templates?
Are there real benefits to one or the other, or does it just come down to developer preference/experience?
If it helps, the website will be for a church, where the content types will be CMS-like; news/announcements, wiki-like pages, and a limited type of social networking (for the minister to communicate with parishioners).
Short answer: It sounds like filling the content with JavaScript would not be useful in your case. Loading the data with JavaScript is adding a layer of complexity with minimal or no benefit (in your case). Take a look at CMSs and websites that have similar functionality to what you're doing. WordPress, Drupal, etc.
For an example of when it might be useful to load data with JavaScript, check out the tags section on this site. When you search for a tag it queries the server without reloading the page. However, the initial tag list is loaded during the initial page load without any JS.
Here are some cases where you might benefit from loading information with JS:
There is some data that will take longer to load. For example, you're getting data from a web service. Using the traditional method, you would need all the data you need for the page to be available before it can be displayed. If you loaded that data with JavaScript, the page could load and the slow data would appear when it returns. Realistically, you would probably just cache the data but this is just an example.
You will be getting more data as the user stays on the page. You might want to update the page without refreshing.
You want the user to be able to query more data without refreshing the page.
Your users have limited bandwidth (mobile).
This site has more guidelines: http://www.oracle.com/technetwork/articles/javase/index-137171.html
What's the best way to add dynamic content to a web page after a successfull xml http request. To break down a more concrete example:
User fills in data in input field (e.g. a forum post)
Data is asynchrously updated using the ajax technology
The forum post is instantly displayed for the end user
Sites like Facebook or last.fm (when you post a shout, ie) send the processed markup in a direct object back to the javascript, instead of just the processed data. An example of this written in jQuery would be
$('#activeField').html(callback.data);
Another way to do this is to create the dom elements on the fly with javascript. I find this too clumsy as there's no easy (?) and simple way of doing this today. At the same time, sending the processed markup directly from the server violates our application's design principles (MVC), as having markup in a front controller is not preferred.
What's the "best practices" way of doing this? Thanks!
At the same time, sending the
processed markup directly from the
server vioalates our application's
design principles (MVC), as having
markup in a front controller is not
preferred.
I may be missiing the point, but could you not send markup from the server by rendering it within a view as you would normally, rather than having to have markup in your controller? Assuming your View mechanism has the ability to return rendered HTML rather than outputting it immediately, you could retrieve this and then add it to an array before calling json_encode() and outputting it. You could potentially then use the same view code to render this piece of HTML regardless of whether it is being fetched as part of a full page or via an AJAX call.
I think this question pushes too far on subjective perhaps, but personally I believe the best plan is for the request to return JSON which describes both the content and the mechanism (by which I mean javascript method) for serialising that to HTML if multiple possibilities exist. This saves on bandwidth and (as you've pointed out) preserves your separation of concerns. The last thing I want really is for my front-end guys to have to deal with arbitrary mark-up from the server-side guys. Abstraction is good.
I don't really get why you feel JS generated mark-up is clumsy or difficult. A handful of JS methods which parse and generate standard JSON structures seems lightweight and trivial to me, though I must admit I've always rolled my own here. Almost certainly there's a framework for this out there (anyone?). If not, well I've got this great business idea...