We have a large Silex/Angular app that is essentially a single page REST app. We use Silex security throughout the PHP side.
With the end of life of Silex here, we're trying to figure out the best route to maintaining the app. We're considering:
Symfony
Slim
Lumen
Silex maintainers say to switch to Symfony, but we're concerned that it will require a lot of work to make it work for a single page app.
We've also considered Slim or Lumen - and of the two we're leaning more toward Slim since it seems to have a larger user base.
Any thoughts on a recommended way to go would be greatly appreciated.
According to Fabien Potencier, Silex has migrated to Symfony 4+. I work with Symfony since 2007 and it is one of the best PHP framework, in my opinion! I would like to encourage you to have a look at their documentation and also pay attention to its community. They are strong and also, they are up to date with the framework!
Related
I just started with symfony 4 and have a question about "multi-controller", if my application got many routes, should i go for more controllers to keep the files tiny and readable or is one controller enough / recommended?
There is no recommended way about multi-controllers on the official documentation.
If multi-controller is a good choice, how to split?
If there a good documentation on the inet?
Absolutely yes, you should have more than one controller. Symfony's best practices recommend to keep your controllers tiny and delegate much of your application logic to services that you create to handle different actions. For this, it is essential that you have a basic understanding of Dependency Injection, the Container pattern and, more specifically, how Symfony's DI Container works (how you can register services, for example).
There's tons of documentation on Symfony in the intenet. This one on controllers.
KnpUniversity has some really good tutorials to get you started. Start with the Symfony series, then follow with Symfony Internals.
Also, you will greatly benefit from the features of the maker bundle, that will generate code for you really quickly. You can install it with composer require maker. Then, you can create a controller running php bin/console make:controller.
DukeScript looks like a life saver for we Java guys! I am considering it for a serious project. Was curious to know whether it's production ready and well documented. Also, liked to know what would be the best way to support routing in a web application.
I asked this question at the official google forum, but didn't get a reply. So, thought to re-ask here.
Here's a blog post with a little example. It shows a simple integration of location hash based routing with knockout templates. The full example code is available on github.
You might also use one of the javascript libraries like sammy or pagerjs, which would require integration with these frameworks, but I wanted to keep it simple.
Couple of month ago I got a legacy project written on Sf2. I fixed some bugs, and added some new functionality, but still i feel that it was made a little bit clumsy. Well, maybe not just a little :) So, I have a number of questions, how things really should be done in Sf2.
The first thing which is bothering me, is that the Application is separated on Frontend and Backend bundles. The're standing on the same model, and for example entity Book can be seen from FrontendBundle and edited from BackendBundle. In some way this is producing a confusion of abstractions. So my question is - is it right, or wrong, and if wrong how it should be done in appropriate way?
Bundles are components in symfony2 that provides a functionality to your app. The frontend and backend approach has changed in symfony2, the bundles are used instead.
For example, you can create a BookBundle, and put all the functionality regarding to books in that bundle, adding, updating etc. And by configuring the routes, you can redirect all the requests about the book to that bundle.
The main point is, the frontend and the backend about the books resides in same bundle, and only in that bundle(with controllers and entities and repositories and views etc.).
This is the intended usage in symfony2.
I'm new to version 2 of the Symfony framework. I made some projects with v1 but now trying to get my head around the new version and it's features.
I read over the concept of Bundles but it's purpose is not yet very clear to me.
Say you have a big web application, a CRM for example. How would the bundles look like?
Would it be NewsletterBundle (for sending newsletters), ContactManagementBundle (for managing contacts), UserBundle (for editing users and their permissions).
Or would it be less cut-up like, EmailBundle (for handling the entire email traffic), CRMBundle (for putting in all your CRM code), PermissionsBundle, ApiBundle.
I like to think of it like this: a bundle should represent a specific feature or set of like features for a project.
Your first example is a better use of bundles than your second example, because the purpose of each bundle is more defined. While it's possible to use one CRMBundle for everything, you wouldn't really be taking advantage of Symfony's ability to organize your code. Additionally, if you wanted to port over your Newsletter code to a new project, but not all of the CRM code, you'd have an easier time copying over a NewsletterBundle versus copying over the CRMBundle, and then pruning it.
When thinking about a Symfony2 project, sometimes you want to forget everything you know about symfony 1.x, since they take wildly different approaches to solving many problems. For example, in symfony 1 it was common to build a 'frontend' and 'backend' app for a project, and each app would obviously contain logic specific to those parts of the project. So you might have a Newsletter controller in both the frontend and backend apps. In Symfony2, you're better off using only one Newsletter bundle, but with two controllers (perhaps named 'frontend' and 'backend'). Again, an immediate benefit to this is how reusable your code becomes.
I'm currently working on a PHP project using CodeIgniter as my framework. I took a look at a few templating systems I could probably use - Strogen's Templating System (currently used in PyroCMS - if I'm not wrong), Twig, Smarty etc.
But I have decided to go on my own to build one from scratch. Since I have experience dealing with Wordpress templates, I was thinking of creating something similar.
To give you a run down of how wordpress themes work - Wordpress has a set of functions (Theme functions) that help gather data. I was wondering if following the same would be a good idea for my project as well?
If I did create such template functions which I would be calling within my views, would it work against the MVC principles? And would it affect the performance in any way?
Well, with MVC, models do the db interactions, views display the data, and controllers are the go-between. If you created your "template functions" in the controllers, I suppose you would be complying with MVC. If you wanted to say, create a library or helpers to do the gathering of/manipulation of data, you would not be complying with MVC convention. AFAIK, it's a matter of preference which way you choose. As far as performance, you could use profiling to test which is better.
However, if your aim is to build a templating system for CI that is similar to WP just because you are familiar with the way WP templating works, I'd proffer that it would likely take you substantially less time to learn a new one than build your own. I'd also imagine it would take much less time to learn the new one than it did to learn the WP one.
Also, I think pyro uses a combination of Phil's templating and smarty, but not positive. Phil has a templating system available for CI here: https://github.com/philsturgeon/codeigniter-template May be worth checking out.
cheers.