As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
AngularJS is very powerful when it comes to interactive HTML5 and model binding. On the other hand, PHP frameworks like Yii enable quick, well-structured, safe and powerful web application development. Both technologies provide sophisticated means for data access, iteration and page layouting.
Is it good or bad practice to mix those two approaches (client-side and server-side "page setup") or is this rather against the meaning of interactive, seamless HTML5 AJAX web applications?
I am not talking about generating JS using PHP (See this question) - I'm talking about generating a view that will make use of AngularJS.
I also know that an AngularJS page should (or can) communicate with the server via REST services to get data (See this question) instead of retrieving it from for example PHP variables directly. But to me it seems more convenient to design the "frame" for the entire web application separately in PHP (e.g. build the main menu or handle authorization/ sessions etc.)
It seems you may be more comfortable with developing in PHP you let this hold you back from utilizing the full potential with web applications.
It is indeed possible to have PHP render partials and whole views, but I would not recommend it.
To fully utilize the possibilities of HTML and javascript to make a web application, that is, a web page that acts more like an application and relies heavily on client side rendering, you should consider letting the client maintain all responsibility of managing state and presentation. This will be easier to maintain, and will be more user friendly.
I would recommend you to get more comfortable thinking in a more API centric approach. Rather than having PHP output a pre-rendered view, and use angular for mere DOM manipulation, you should consider having the PHP backend output the data that should be acted upon RESTFully, and have Angular present it.
Using PHP to render the view:
/user/account
if($loggedIn)
{
echo "<p>Logged in as ".$user."</p>";
}
else
{
echo "Please log in.";
}
How the same problem can be solved with an API centric approach by outputting JSON like this:
api/auth/
{
authorized:true,
user: {
username: 'Joe',
securityToken: 'secret'
}
}
and in Angular you could do a get, and handle the response client side.
$http.post("http://example.com/api/auth", {})
.success(function(data) {
$scope.isLoggedIn = data.authorized;
});
To blend both client side and server side the way you proposed may be fit for smaller projects where maintainance is not important and you are the single author, but I lean more towards the API centric way as this will be more correct separation of conserns and will be easier to maintain.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Me and my team will soon start the development of a new web (vtv) service.
Most of the stuff will be processed and handled through a json api but we need a decent control panel for users who want to access their data in a gui environment.
We are debating if it's worth the time to develop the control panel with a framework such as knockout or backbone or if we should just stick with our classic stack.
As a devoted Javascript fan and developer I have used both knockout and backbone for some minor apps on my spare time and I can already see how hard it is to put all these peaces together in a real production.
Is it really worth to spend extra money to follow the trends and give the user a speedier gui?
My company seems to be interested in fast bucks solely so please tell me arguments to use!
Thanks =)
I can't comment on Knockout, but Backbone is absolutely brilliant. It's a small framework to learn, and once you get the hang of it, you'll find it does what every framework of its kind should do: implement the bits that you would have implemented anyway, and think about the issues related to that that you'll realise a little down the line.
It provides a sensible event and object model system that handles the business of keeping server-side objects and client-side objects in sync and has a sensible view model with event bindings linking the two.
So to address your question, it really depends on what you're doing. If you're writing the kind of asynchronous application that uses models and gets data from an API, chances are you'll want to use the same architecture as Backbone. If you're not, you've either designed something very different and it'll be no use (so you can say 'it just doesn't fit') or you've made a mistake in your design and you'll soon need to re-write!
Knockout or Backbone will not help you give the user a 'speedier gui'
However, it will make development easier. The frameworks impose a structure on your code - which means its easier to maintain, other people on your team can read the code and understand the flow more easily. This means you can respond to user feedback faster and give your users a positive experience
For speed of the UI itself, you should use speed optimization techniques starting with investigating the causes of slowness of the UI
In general, I'd suggest you go ahead with the framework of your choice. Only good can come out of it
Generally you should choose a framework / library because it gives you added value or shortens development time.
If you have the time/money and want to learn to implement new technologies while writing software, that's great, go for it!
If you need to get things done quickly, use the right tool for the job.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Hi If I want to choose a language for web development what all the factors I should take care?
And following things are important in my application , so keeping these in mind what language I should choose ?
Every user will be having an account ( need database programming)
Different Data should be shown at client side based on type of the user ( there will be different type of the users, some data will be common to all, some data will be specific)
Need to manage all the data efficiently at server side ( server side programming )
Give rich UI at client side .
Keeping all such things in mind, what language I should choose for web development? please mention in terms of client side and server side programming.
And I did go through the same kind of question in stackoverflow , still am not clear with my doubt, expecting detailed answer. please Provide me necessary links, and I am thinking about php, ruby, JSP, but am not getting which one to choose and when?
Definitely It should be dependent on what I want, so above points tell that what exactly the application needs. Need to manage accounts, different data etc.
Almost (if not all) every modern languages have database bindings, and even if not, database programming could still be done using other backends.
This is application specific, has nothing to do with programming language.
Language contributes very little to speed of execution. Compiler/interpreter implementation, algorithms, data structures, architectures, frameworks matter at a MUCH greater point.
The only (dynamic) web programming language that browsers understand is JavaScript. You can use any JavaScript framework or even any framework that could generate JavaScript code to manipulate user interface.
For a general language:
Will it run on the server I'm looking at getting, or the hosting service I plan to buy?
Do I know it/can I learn it quickly?
Does it have the features I need now, as well as in the future if I plan to expand my web app?
Your questions:
Does this language have a ready-build database interface? If so, good!
Every single language out there supports some sort of conditional (if()) statement. You just need to use them properly, with the data you have.
Back to the first bullet point; will my chosen language run on a webserver?
With a few exceptions (NodeJS, for example), you can't use the same language client and serverside. You'll need to know at least HTML and CSS for your "rich UI", or you could always hire a designer and leave yourself to do the backend.
Personally, I would recommend you use PHP for this project. It does everything you want, is very widely supported by web hosts, and is free to use. Most web IDEs work well with PHP, as do text editors.
In all honesty you are describing just about any of the major server side scripting languages. It all comes down to how much experience you have with the language and which one has the API's / resources you need.
For example with PHP you can use Wordpress, Drupal or Joomla to power the CMS aspect of it all.
On the other hand if you had to script it all from hand then you just need to choose the language you prefer to use. Look at how the scripting language interacts with the database. Does it require much more code to access a query, are you comfortable using the language, can you use that language on your server?
PHP tends to be the no-brainer since it is widely support, there are plenty of resources and information all around the web due to it's popularity, and most of the major CMS's are written for it (meaning you don't have to write one yourself).
You could also consider newer Web languages like Opa or frameworks like ocsigen (with Ocaml), and you could also write your Web application; e.g. with FastCgi technology, in whatever language you are familiar with.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I'm designing a new website and I need a login system (Preferably in PHP and mySQL). I've written ad-hoc login systems before and I'm aware of all the security involved, etc. But as Jeff Atwood said, Never design what you can steal. So I'm wondering if there are any good PHP login/sign-in libraries. Can you recommend any?
some specifics
I am trying to avoid php frameworks if at all possible (there is no reason to import one just for the login function)
Also, I am aware I could simply use a social login or open-id, unless you are aware of a REALLY good library for this I would also prefer to not have to have to use something (open-id) I've never dealt with before
Finally I need to be able to edit the user information in the mySQL database
UserCake
http://usercake.com/
Login Register Lost password recovery
Update password Update user email
Email templates (optional) SHA1
security + Salt / Hash Account
activation (optional) Resend
activation email (optional) User
groups (Basic, id - group_name)
Multilingual support
Or
You can try
http://phpuserclass.com/
Some points before the answer.
You may rethink your strategy on frameworks. Modern frameworks like Zend Framework and also Symfony2 are loosely coupled. This means: you dont need to download/use the whole framework.
Another reason to rethink it, is that these frameworks are often robust, widely tested and used. In terms of performance they are not always of huge impact, especially with apc and other optimization methods, so are you affraid you will use too much harddisk space?
Your question is about something specific but easily done. This is exactly the type of stuff that frameworks are good at. Codeigniter, Zend Framework, Symfony, Symfony2 (am I missing one?), all offer code that will allow you to do this in maximum a matter of hours.
Libraries I would consider
Zend_Auth (has only zend_exception as hard depencencies). It's lightweight and has many options for integration with openauth and such. (requires about 10 php files) http://framework.zend.com/manual/en/zend.auth.html
Apache ZetaComponents (before ezcomponents)
http://incubator.apache.org/zetacomponents/documentation/trunk/Authentication/tutorial.html
Pear LiveUser
http://pear.php.net/package/LiveUser/download/
If you were to consider codeigniter, check this out: http://codeigniter.com/wiki/Category:Libraries::Authentication/
This tutorial is a bit on the old side, but it is one of the best out there and is very well done. There's no framework, it's just plain old good OOP PHP.]1 The code is available for download on the Tut.
It's well written, includes Cookies, and has a robust back end for user admin.
If the libraries you find do not apply, many of the concepts I presume you'll look into involve either combining PHP and LDAP, and/or PHP and the Apache authentication modules.
Your authentication requirements should also respect the principles of defense in depth.
Also, you might need to discover if your project requires authentication for JSON, XML-RPC, or REST APIs that could be operated by non-browser clients.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have just "finished" coding up a relatively involved web service in PHP. The code base is now a bit of a mess due to last minute requests, changes, add-ons, the usual.
I tried to code it as lightly as possible and in a manner that would maximise performance.
Therefore, I didn't use any frameworks like Zend or any ORMs like Doctrine.
I was wondering if there are any frameworks or design patterns that exist for the sole purpose of building APIs/web services in PHP?
I'm thinking of a refactor and I want to make sure now I know exactly what's involved I can build this thing properly.
I apologize in advance for the self-reference here to my own framework - there's no way for me to help you otherwise since I don't use anything else. I'm not advertising, since it's not public.
As I said in my comment, I think a good web front-end framework shouldn't mean it is a poor web service framework.
Because I was unsatisfied with the restrictive way any of the popular PHP frameworks (CodeIgniter, CakePHP, Kohana) processed requests, as well as their size, I wrote a framework that is designed for really only two purposes, process a request and determine an action to take, and then separate the code for that action from the view (response).
The design pattern I use is this:
All URLs are rewritten (mod_rewrite) and passed to your execution entry point.
Your entry point sets up paths that it will recognize and process. I.E. for a web service:
/users - User list
/user/* - User identified by the value where * is.
/user/*/delete - Delete the user
/posts - List posts
/post/* - View post *
Along with the path you specify a function, I.E. UserActions::saveUser to be executed if the HTTP method is POST. The reason it's only executed on POST is to enable output and input to have the same URL.
The path also specifies a view. This is the response body that will be sent to the browser. It can be rendered as straight PHP, or you could plug in a template engine. In the case of web services, all paths would probably use a single view that renders your data in the output format (JSON, XML, whatever). The view can be just a PHP method and is not required to specify a template file.
In the case of a web front-end, the view can have a parent view which wraps it (creating the page from the inside-out).
The last point is security. You can define a security type to be applied to any path. A security type just specifies what function (like SecurityManager::authorize) to check for authorization and if false is returned, it redirects to a path of your choosing.
The reasons I believe this design pattern works well for Web Services:
Enables you to use a single-entry point, but can be used with multiple entry points (for optimization, if needed).
No assuming that you want your URLs to match your Object Model, like most of the major frameworks do (a notable exception being Zend, as mentioned in the comments).
Easily adapted to REST (instead of just checking for POST, check for other methods too).
The removal of any HTML feels completely natural, since in this pattern the response is completely separated from processing.
This can all be done in a few classes.
Imho, every MVC-based "thing" can really help you.
If you really do not want to use anything (give a try to CakePHP!) already existing, strucutring your code following mvc can really help you to split the logic of your application on more layer, and keep it more readable and debuggable.
Of course, also with the better pattern you can write awful code, it's up to you!
I think you can use the same patterns you use by simple web applications. A restful service has different interface than a web application, but everything under that interface is the same. You can transform a restful service to a web application like so:
METHOD host/resource/data => host/resource/METHOD?data
resource is the controller, METHOD is the action.
For example:
GET http://library.com/books/123 => http://library.com/books/get?123
So you can use front controller and MVC.
A quick Google and I see
Frapi
Cake
Meditation
Code Canyon
I have never used any of these
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Remember Aptana Jaxer? It plugs into Apache and allows using JavaScript on the server-side as an alternative to languages such as PHP. It comes with a consistens and slick API for filesystem access, database connectivity, socket communication and whatever else you need.
I wonder why hasn't this been more widely adopted, why aren't more people using this? Javascript is a modern and clean programming language as opposed to PHP and the Jaxer API is just so much more consistent and neat. No offense, but the PHP API is just such a big mess with all its inconsistencies and its inconsequent function naming convention.
Jaxer also makes client/server communication really convenient with its runat="server-proxy" where you can directly call server-side function from within your client-side script and Jaxer takes care of all the XML HTTP request stuff.
So I would just really like to here what people think about it or why there's hardly anyone using it. Not wanting to start a flamewar here, I'm just curious.
Thanks
Well, first of all, there is Node.JS out there, too. Far more people have heard of that, probably. And people do use node, especially when it comes to chats and similar things: Things there long-polling is appreciated.
My personal problem with node is, that it is so asynchronous. That's a very, very, very big pro on one hand, because is allows most awesome performance and makes some things so much easier, but on the other hand it is a big minus for those used to synchronous programming languages. I simply have problems with looking at code which has 15 callbacks nested in each other...
I remember taking a look at Jaxer, back when it came out. I don't remember any sample applications at the time though. I wanted to get a feel for what it was good at. Just because a language is "cleaner", may not be enough to get people switch. What is its "unique benefit"? For example, Node.js is good at real-time applications and they make that relatively clear in the sample code on their front page.
I think there was also been more uptake of Javascript, since Jaxer was initially released. There seem to be more back-end developers who now also know Javascript. I would say that's more true now than when Jaxer was released. In other words, maybe it was ahead of its time.
Personally I liked Jaxer, because you easily could use the same code client and server-side without duplication (such as form validation), however I didn't like, that you had hardly any control over the generated pages, which where propped full of JavaScript even for the most trivial page and made the pages highly depended on JavaScript, which made unobtrusive JavaScript virtually impossible.
So I guess for purely JavaScript-based web apps it's ok, however now there is for example Google Web Toolkit, which is much more powerful, which basicly also allows you to use one language client and server-side.