I have a PHP app that uses Smarty. It is not using any standard MVC framework but achieves the same aim as follows:
each click that causes a page transition does it by calling a structured URL (akin to REST calls) that is interpreted by Apache rewrite rules (in .htaccess) into specific query parameters attached to the index.php file.
the index.php then determines which page or sub-page to load, performs whatever controller logic and then assembles the display info, loads smarty vars and then displays
I read somewhere that it's not advisable to mix front and back end MVC frameworks. I however need to convert the app in as short a timeframe as possible.
The typical combination is to have angular call a PHP REST backend. However I would rather keep all the deep business logic in the back end (not just CRUD actions) but have the PHP send back to my angular the data to be displayed.
I'm pretty new to Angular: is there anything that makes this technically impossible or suboptimal?
The typical combination is to have angular call a PHP REST backend.
Typical, yes. But not absolutely necessary. Your webservice can be structured the way you want.
However I would rather keep all the deep business logic in the back end (not just CRUD actions) but have the PHP send back to my angular the data to be displayed.
I might be misinterpreting you but, keeping your business logic in the backend is how it is supposed to be. Rest is not CRUD.
the index.php then determines which page or sub-page to load, performs whatever controller logic and then assembles the display info, loads smarty vars and then displays
The problem here is the "controller logic". From what I can gather you're trying to replace a server-side template engine with a client side template engine. That's fine. But AngularJS is not a template engine and there are some key points that might make it a bad choice in your case:
Angular is meant to work as a single page website/app. This means it expects pageflow and view logic, for instance, to be controlled by the client side. By keeping the "controller" logic in the backend, you turn Angular into an extremely inefficient and heavy template engine.
It expects the backend to serve (structured) data, not a "full" view. Sure, nothing stops you from requesting a PHP document. But it kind of defeats the purpose of using angular.
It plays nicely with REST because of its stateless nature. This
can be a bit of a challenge since it deviates from the usual PHP setup. The biggest example are logins and PHP sessions.
Usually, in most PHP setups, a user authenticates through a login form and then the server responds with a cookie, usually containing a PHPSESSID. While the cookie gets passed around, the user stays logged in and the appropriate UI/view/data is displayed. To adapt this logic to AngularJS single page app requires a bit of work. This article might help you
I'm pretty new to Angular: is there anything that makes this technically impossible or suboptimal?
In short... impossible no, far from it. suboptimal maybe...
Related
Coming from non-JS html interpretation it's kind of hard for me to grasp the concept of loading server-side data to REACT.JS "view".
Let's say I've have a site built on Laravel (using routes). Each route request (e.g. "/", "contact") has it's own view. That view is loaded with data coming from a controller and displayed in the view. If I change the route I'll be redirected to another view and I'll get different data from a different controller.
Now the question. Let's say I have a simple site. Top part is my login information and maybe some notifications icon the content of the page changes with going to different sections of the web.
So If I keep using Laravel routes. Every page will be "re-rendered" + I'll have to manually select which components belong to that part of the site. I'll have to retrieve the information that stays the same from the whole web (e.g. login details + notification) again - this kills the react.js principle doesn't it?
Also, what is the best way to propagate server-site data to React.JS? Should I just "echo" out JSON object to the view and then "use" it in REACT?
Could I be pointed to some meaningful approach of how to use React.js along with PHP.
You mostly answered your question :-) With Laravel, the UI is rendered on the server. React is mostly interesting for client-side UI. That said, not everything can be done on the server, and some user interactions can only be managed by the browser. That is why jQuery became so successful in addition to PHP.
If your app deliver some complex client-side code, it could be usefull to build this code as React components, even if you keep your current server-side router: to make the code easier to maintain, but also to write - once familiar with React way of implementing things.
If you would like to transform your app to fully use React and a client-side router, that enable browsing the app without re-rendering at each page, this is called SPA (single page apps). The react ecosystem is pretty cool for building SPA. Usually, though, the server is just a static server delivering JS files, and the app connects to a REST API of some kind.
In some cases, routes can also be served from the server, for specific purposes:
Faster display of first page
Social Graph tags can be added to the specific page (to enable usable Facebook
or Twitter shares, for example)
Should you need to enable this server-side routing, which makes your app universal or isomorphic, you must use components that can be understood by both the browser and the server, this is why React app are usually served by Node.js, so everything is in Javascript.
Example tutorial about building a universal app with React https://medium.com/front-end-developers/handcrafting-an-isomorphic-redux-application-with-love-40ada4468af4#.h8p6lc23w (your intuition is right in this case, a JSON object with app current data is sent at first render)
Also check the awesome react page (https://github.com/enaqx/awesome-react) if you're interested in the React ecosystem.
Recap:
PHP + React: Easily add complex components to some pages, better to keep it that way if you just have a lot of static content, SEO, and just a few complex components on a single page that React can help you with.
React + API: Common SPA app, better for rich and complex UI, pretty easy to develop if starting from scratch and familiar with javascript, but complexity arise with performance management and SEO on large apps
Universal React: the best of both worlds, setup kinda complex (cf tutorial)
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.
How do you go about designing/structuring a completely ajaxed MVCish style site? I guess what confuses me the most is that there would only be one view that adapts and changes to the user actions...
I'm looking to build a really simple app, both front end and back end in this style.
Yeah, you'd be building a "front controller" of sorts that would route the views (there would be more than one) to the page for rendering in divs. My company does this with two of its apps and it's lightning fast and a great way to go for a simple app...users love it. Key to the success is a well-formulated layout with well-defined divs to receive the content. As you'll be repeatedly writing and re-writing to them, you have to ensure ahead of time that they are able to handle data of various sizes and amounts as you'll have very few ways to effect layout per page on the overall container....besides after-the-fact hacks (just say no!)
Do as you would with controllers and models and the views (the front-end view code) In some cases our code will use an intermediary page (we call it a mid-model) to generate Jquery data in a JSON string format. It's not quite a model in that case, as it takes action like a model but sometimes returns more than just JSON depending on the needs of the Jquery element.
An interesting offshoot of this system is the use of a program called XAJAX. It's a PHP library that facilitates AJAX called directly to PHP functions, so it eliminates the need to do intermediary JSON generating pages like Jquery uses. For those who understand PHP but struggle with Javascript, this can be an easier solution to grasp. While the documentation hasn't proven very strong, it's a very powerful tool.
I would do all your views as usual (except they would only be HTML fragments that would be inserted into the page) and then have an extra "special" controller and view that loads your views via Ajax. When a link is clicked or something like that the JavaScript makes an Ajax request to the special controller with the view you want to load. The special controller then renders the view and sends it back to be inserted into the page.
I have been in web programming for 2 years (Self taught - a biology researcher by profession). I designed a small wiki with needed functionalities and a scientific RTE - ofcourse lot is expected. I used mootools framework
and AJAX extensively.
I was always curious when ever I saw the query strings passed from URL. Long encrypted query string directly getting passed to the server. Especially Google's design is such. I think this is the start of providing a Web Service to a client - I guess.
Now, my question is : is this a special, highly professional, efficient / advanced web design technique to communicate queries via the URL ?
I always felt that direct URL based communication is faster. I tried my bit and could send a query through the URL directly. here is the link: http://sgwiki.sdsc.edu/getSGMPage.php?8
By this , the client can directly link to the desired page instead of searching and / or can automate. There are many possibilities.
The next request: Can I be pointed to such technique of web programming?
oops: I am sorry, If I have not been able to convey my request clearly.
Prasad.
I think this is the start of providing
a Web Service to a client - I guess.
No not really, although it can be. Its used to have a central entry point to the entire application. Its a common practice and has all kinds of benefits, but its obviously not required. Often thes days though even a normal url you see may not actual be a physical page in the application.. each part of the path may actuall be mapped to a variable through rewriting and routing on the server side. For example the URL of this question:
http://stackoverflow.com/questions/2557535/general-web-programming-designing-question
Might map to something like
http://stackoverflow.com/index.php?module=questions&action=view&question=2557535&title=general-web-programming-designing-question
is this a special, highly
professional, efficient / advanced web
design technique to communicate
queries via the URL ?
Having a centralized page through which all functions within an application are accessed is part of the Front Controller Pattern - a common pattern in applications generally used as part of the overall Model, View, Controller (MVC) pattern. In MVC, the concerns of the application are divided into the model which holds the business logic. These models are then used by the controller to perform a set of tasks which can produce output. This output is then rendered to the client (browser, window manager, etc..) via the view layer.
I think that essentially what you are asking about is query strings. In a url after a page, there may be a question mark after which, there may be URL parameters (generally called GET request parameters.)
http://www.google.com/search?q=URL+parameter
Generally, processing this would be done on the server-side. For example, in PHP, one could use the following:
$_GET['q']
The aforementioned code would be the value of the variable. Alternatively, to do this client-side, one could use anchors. Replace the question mark with a hash sign #
Since this is used for anchors, when a URL is changed to have an anchor tag, the page is not refreshed. This allows for a completely AJAX-driven page to manipulate the URL without refreshing. This method is often used also for enabling back-button support for AJAX pages.
In JavaScript, one can use the onload handler as an opportunity to read the URL of the page and get the hash part of the URL. The page could then make a request back to the server to read any neccessary data.
It's a consequence of using a front controller architecture. This fits neatly with the idea of a wiki where the same code is used to render multiple different wiki pages - the content is defined by the data.
Using the query part of the URL for the page selection criteria is not the only solution. e.g. if you are using apache then you could implement:
http://sgwiki.sdsc.edu/getSGMPage.php?8
as
http://sgwiki.sdsc.edu/getSGMPage.php/8
(you'll need to add your own parsing to get the value out.
Alternatively, you can use mod_rewrite to map components out of the path back into the query.
There's no particular functional/performance reason for adopting any of these strategies. Although it is recommended, where the URL is idempotent, that each page be addressable via a GET operation (also useful for SEO).
C.
I've been tasked to migrate a web application to a more 'modern feeling' AJAX web 2.0 deal. The application as is currently uses PHP to pull data from the database, present the user with forms, and then update the database based on those form submissions. Frames are used to have a persistent main navigation menu, and a content area where the actual
So each php script basically looks for $_POST information; if there is none, it shows the user database data, otherwise it updates data ( provided it is proper data ) and then show the user the result. There are simple get navigations that show subsets.
To migrate this to a AJAX site with a css layout with the content changes happening inside a div, I'm precluded from using POST, because that refreshes the whole page, right? ( I mean I could, but that would be wasteful -- I don't need to regenerate the whole page when only a small part changes.) So basically, the whole task is using Javascript to read the form information, send an XML HTTP Request, and display results? That sounds like a lot of re-writing the existing php funcitonality in javascript, which I would hope to avoid.
Have I understood the task correctly? Are there libraries or frameworks that can help me?
You have two problems here, which are related in some ways, but shouldn't be simply lumped together.
CSS for layout
Only loading part of pages when forms are submitted
I'd work on the separately (while keeping the other in mind as you do so)
First, I suggest you focus on moving to web standards based pages — without introducing Ajax.
It is true that there are some inefficiencies to be had when reloading the whole page, but this approach is simple and relatively easy to debug.
While you do this, consider separating out your display and business logic. The MVC pattern works well for this.
CakePHP is a popular MVC framework that might help.
Once you have a working system, then you can worry about using Ajax. Follow the principles of progressive enhancement.
If you have separated our your display logic from the business logic you should find it relatively simple to reuse your existing code with a different View that provides the data you care about in a JavaScript friendly format (such as JSON).
You can process this to update the parts of the page you care about.
Frameworks that can help you include YUI and jQuery.
I wrote a simple example last year. Lines 51 onwards of the main script pump data into either an HTML template for processing directly by the browser or a JSON module for processing with JS. There isn't a great deal of duplicate effort there since the code for looking at the parameters sent by the user and extracting data from the DB based on it is shared.