I'm working on several reports for a web application. I have to show some data from my database in some bar/line charts. I'm using Codeigniter framework so my backend is PHP and my frontend is mostly composed of html and JS. As for displaying graphs I'm using e-charts library.
My question is, what's the best practice when retrieving data for the charts. I could use an ajax call and retrieve general data, then format it in the frontend using JS and finally drawing the chart.
A second option would be to also make an ajax call, but making an endpoint that already sends the data in an specific format that the graph can understand. Then that endpoint would only be used by this specific graph.
A third option is again making a specific function to retrieve and format the data in the backend, but this time work with both the html and the data in the codeigniter view. Then serve the html+js page with all the data required, no asynchronous call involved.
All three options have some limitations, so I'm wondering which is the best practice. And if you have another option I'd like to read about it.
I guess it depends on your needs. Overall, I think the best practice is to make as few dependencies as possible between your backend and your frontend. Especially if you plan to change your frontend or want to serve multiple frontends.
So the endpoint should return data in a format that can be understood and used by everyone.
You need to inject services into the controller of this API. So the controller receives data from the services and responds to it. Just that. The data extraction (from the database) and processing must be done by the services.
This way you are more flexible. You can create an API controller for your AJAX calls and another controller that renders HTML if needed.
With the first one, the API controller, as I said above, the controller receives data and returns it. You let the frontend take care of the computation, transformation, etc.
With the second, the controller has to get the data from the injected services but also compute, transform, etc, then render HTML.
Read about the single-responsability principle or, more generally, the separation of concerns principle.
Related
I want to refactor my php site which supports a front end which makes ajax calls.
Currently my ajax calls a php page which stores all my backend code and based on the parameters passed from the ajaxcall it determines which php methods to run.
I realize building a rest API as the php backend woudl be better but was wondering if there is another alternative? ie a good way to structure a php page that allows for clean re-usable ajax calls from the front end?
Thanks
There are multiple ways of doing such kind of web development. It could be REST based micro framework approach in PHP where you invoke different views. Another could be to invoke the PHP code solely based on the input or interactions on the view (HTML/Javascript) using AJAX. Depends what you want to achieve.
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 write *sql / php applications a lot a I find myself having to rewrite javascript all the time to do the same stuff over and over. Usually, when the API i have to work with is very simple, its not a big deal to write one-off ajax methods to interact with PHP, which updates sql tables via PDO.
But, when it comes to big data objects sent from php to javascript that need to be parsed, edited, updated, sent back to PHP, and then updated by an application layer, I'm writing javascript all day long to handle these "big objects" and every. little. thing. that could be updated within them.
There has to be a better way. What is it?
What's the nature of the changes that cause you to rewrite large swaths of your frontend js code? Is it new data that you need to surface in the frontend, or is it changes to the structure of the data?
If it's new data and you want to stop focusing on updating your frontend code to deal with it, you would probably need to implement something that lets the javascript build out your frontend in a more dynamic way. I could see this working as a service that passed back as a structured UI mapping in some data format that your frontend js could parse (you'd have to include all the data you needed and probably some information about the format of that data, ie, string, text, date, etc).
That might work alright for some form data, that's basically how form objects work in MVC frameworks like CakePHP or even Drupal. And in fact if that's your goal, to just provide some user-facing content entry, you might even be well-off to check out implementing this code in one of those frameworks.
If the problem is that you're making changes to your structural data, but by and large you're surfacing the same data fields, you probably just need an abstraction of your front-end data models and your backend data models. You can come up with your javascript object definitions that define what the structured data you pass back should look like, define what your backend model looks like, and then define a mapping layer between the two. If the structure of the data changes in the backend, your contract between the javascript object definition and the mapping layer wouldn't need to change, and you could merely change the contract between the mapping layer and your backend data model layer.
I am creating an application that will make heavy use of Ajax and performance is required. I've searched the best ways to handle Ajax requests using the Zend Framework, and saw that the most commonly used ways are the Context-switch and/or an Action per Controler to handle Ajax requests. If I were to use the first way I would have to keep a script in the view for each type of format that I could return (JSON, XML, etc.), and I think it's unnecessary, and the second way, I would get an action full of if/elses.
I do not see anyone suggesting the creation of a module only for Ajax, this would be a bad practice? In my opinion this would make things easier, and the whole code for Ajax would be in one place, I would like to know what you think about it before making a decision, and of course, constructive criticism is welcome.
If you have a controller which only needs to handle AJAX, then you can just use the views as usual.
The context switch is meant for cases where an action needs to serve multiple types of contents (JSON, XML, HTML etc.).
If you know that the whole controller will just output JSON, for example, you can create a single view (or no view at all) and call this particular view from all actions in the controller.
I am a PHP and ExtJS user. I am looking into developing an application using a good PHP framework (CakePHP; good as in "I consider this good for me") and ExtJS version 3. What I would like to achieve is a complete Ext viewport with many grids and functions that would call PHP urls for retrieving data, saving data, edit/remove data (not just for grids, also for treepanel and such). I would like to use CakePHP as backend with all its capabilities for executing these functions. My first goal is to integrate the obAuth component (or any other secure authentification plugin for CakePHP) with an ExtJS 3 login interface. I am searching for the best method of combining these too so that I can easily restrict functions based on the usergroup access. I am thinking of a setup where the logged in user makes one post from Ext regarding the execution of a function and the CakePHP response made present as errors or notifiers through Ext alert boxes.
Do you think this is possible ? Any thoughts of an ideal config for this ?
Thank you.
If you're going back and forth between JavaScript and Cake a lot the first thing you might want to do is override or extend the default View class so it'll package variables you set in the controller automatically into a JSON array or whatever you prefer. That'll save you from having to make a view for each action and/or overriding the layout each time. Study cake/libs/view/view.php and/or cake/libs/view/media.php, you can create custom views in app/views/.
Make use of the RequestHandler Component a lot to reuse logic both for normal views and AJAX.
Beyond that it's normal JS with a PHP backend.
This is actually very easy. First, integrate the obAuth Component into a basic CakePHP install, to see if it works properly and doesn't have any strange quirks. Once that's done, get to work on your frontend.
Your frontend should be designed entirely with ExtJS components. Either design your frontend with ExtJS or via HTML templates, but try not to do both, as it gets confusing and hard to maintain. I recently did this, and every controller action had a view that set up the DOM with some basic elements (a header for the page, any divs I needed to bind components to, and the .js file that was specific to that page/view).
Then, make your application RESTful. All of your ExtJS components can read data from a DataStore (or can just take a URL as the data source), so you just give them the paths you'd like and you're done.
Check out Bancha, it integrates ExtJS 4 and CakePHP 2.
It does this by doing all the communication in the background using an completely implemented Ext.Direct for CakePHP.
cheers
Roland