I've recently started work at a new company, and was initially assigned to help the web development team.
To my horror, their template application they use to set up every single one of the projects they do, is completely procedural.
I am very eager to swap it over to OOP, but before I do that I need to actually understand how to create a project.
The initial work is there - there's an index.php that swallows all calls made to the site/web application.
What I need is a tutorial on how to set up proper routing so that I can look at a URL and go "call this function in this controller" instead of including a bunch of PHP files to get the job done.
Could someone please point me in the right direction?
I was in the same situation and this course helps me a lot to learn more about MVC and Routing in PHP. As #Armin said you can use Slim Framework or phroute .In the other hand, you can use Laravel framework to take care not only routing but also all the other challenges as a PHP developer you might have in the future
It sounds like they don't use any well known framework. They probably also don't want to use one. I think the best solution in this case would be some routing library. You could use the Slim Framework. You will understand everything you need to understand in about 30 minutes. It's very easy to setup and easy to extend.
You should not try to write your own routing library, it'll become quickly a quite complex thing. You will just reinvent the wheel and loose time.
I also would recommend the Slim Framework. I've spent way too much time trying to roll my own framework with routing but the maintenance and updating on my own framework got it the way of actual projects.
Slim is extremely easy to understand and offers a lot of flexibility to mold your own type of application. Between the routing, middleware, containers, and using the Eloquent DB ORM it has plenty to offer.
As others mentioned before, don't reinvent the wheel. There are plenty of tools out there you can lean on that allows you to focus on the actual project.
I think that Create your own PHP Framework from Symfony documentation is the thing you are looking for. You shouldn't be worried about the title, it's not only about creating frameworks. It shows you how to start using Symfony components in plain PHP application and eventually create your own framework.
But creating framework part is not the most important one. Understanding how to use object-oriented components in your code is the key part.
Of course, one of the components is routing. It's use is described in first chapters: Introduction, The HttpFoundation Component, The Front Controller, The Routing Component, Templating (don't skip this one!). But I recommend continuing to the end, it's easy to read and very interesting article. Even if you don't want to use Symfony (or it's components) this article will help you understand how to use any modern PHP components.
Problem:
I’m unsure how to set up multi client application for Symfony so that we would not violate Symfony's best practices and work against the framework.
I would like to have one main Core namespace which would contain all the base model classes. Right next to the core I would like to set up client specific namespaces which would be used, based on client regional setting. For example LocalUS for US market, LocalUK, for UK market etc.
The Local* namespaces should take first priority for including twig templates, and as a fallback use core common shared views (as I understand, this is solvable via twig namespaces). Same goes for controllers and models - these are probably solvable via extending the Core namespaced classes? Is this all solvable via routing and providing paths for these Local* controllers?
I was looking up on github to see if there are any project that have similar setup but I couldn’t find anything.
A little background:
We have an older legacy PHP Application which was built in-house from ground up using plain PHP. As the application has grown over time, it has become hard to maintain good code quality and standards. It’s also very time consuming to teach new developers our application logic, since the application basically follows no standard design patterns and just does it’s own thing. A lot of the underlying code which handles routes, controllers etc seems to work like “magic” that nobody really dares to touch.
It is because of that we would like to migrate our application to Symfony3 framework. I’ve read some articles about the overall process of migrating legacy applications to symfony, and managed to do it with silex pretty well. Silex, however is a bit too lightweight, I found that the assetic service provider had a lot of functionality missing (twig namespacing etc), and decided it would be best if we could move to a full stack symfony framework instead.
Look into Symfony bundles - they do exactly what you need. You create a "base" bundle, than extend it with other bundles. That's how FOSUserBundle works - it provides everything you need, than you extend it and overwrite it.
Let's say I want to create a Blog in Symfony which lives in BlogBundle. But this BlogBundle has dependencies on other bundles like FOSUserBundle, KnpPaginator bundle, FMBbCodeBundle or whatever I end up using. Does this mean I can't really reuse the BlogBundle in another project. The Best Practices for Reusable Bundles chapter of the symfony cookbook says
A bundle must not embed third-party PHP libraries. It should rely on the standard Symfony autoloading instead.
But what does that mean exactly? Can't I use anything that isn't programmed by me?
If that is the case, I'd have to reinvent the wheel for the most basic problems I encounter in developing my bundle. For example I would have to come up with my own paginator to paginate content, create my own user manager and so on..
I don't see a point in that as I would waste my time fixing problems that have already been done much better than I could do.
Or does the cookbook mean I can't use anything that doesn't live inside a bundle. This would make much more sense to me.
It really irritates me that nobody really has done a blogbundle or something similar that gets good feedback and is mentioned anywhere in the top lists. I know, Symfony isn't meant to have a solution that just works out of the box and some coding is necessary, but still. All the bundles I can find that seem to be very popular are the ones that do something like parse BB Code, take care of User Management and other things that are hard and tedious to do, but never something bigger than doing only one task.
I hope you understand what I mean and can help me with my problem. Thanks in advance!
A bundle must not embed third-party PHP libraries. It should rely on
the standard Symfony autoloading instead.
This means that you shouldn't copy code of other libraries to your Bundle (directory). Instead that you should add them as a dependencies to your composer.json.
I am looking for a (small) library that helps me cleanly implement a front controller for my pet project and dispatches requests to single controller classes. The front controller/dispatcher and controller classes need to be fully unittestable without sending HTTP requests.
Requirements
PSR-0 compatible
installable via its own PEAR channel
support for unit testing:
checking if the correct HTTP headers are sent
catches output to allow inspection in unit tests
perferably PHPUnit helper methods to help inspecting the output (for different output types, i.e. HTML, XML, JSON)
allows setting of incoming HTTP headers, GET and POST parameters and cookies without actually doing HTTP requests
needs to be usable standalone - without the db abstraction, templating and so that the fat frameworks all provide
Background
SemanticScuttle, the application that is bound to get proper "C" support, is an existing, working application. The library needs to blend in it and needs to work with the existing structure and classes. I won't rewrite it to match a framework's specific required directory layout.
The application already has unittests, but based on HTTP requests which make them slow. Also, the current old way of having several dozens of .php files in the www directory isn't the most managable solution, which is why proper controller classes need to be introduced. All in all, there will be about 20-30 controllers.
Previous experience
In general, I was pretty happy with Zend Framework for some previous projects but it has several drawbacks:
not pear-installable, so I cannot use it as dependency in my pear-installble applications
only available as one fat download, so I manually need to extract the required bits from it - for each single ZF update.
while unit test support exists for ZF controllers, it's lacking some advanced utility functionality like assertions for json, HTTP status code and content type checks.
While these points seem to be nit-picking, they are important for me. If I have to implement them myself, I do not need to use an external libary but write my own.
What I don't want
StackOverflow has a million "what's the best PHP framework" questions (1, 2, 3, 4, 5), but I'm not looking for those but for a specific library that helps with controllers. If it's part of a modular framework, fine.
I also know the PHP framework comparison website, but it doesn't help answer my question since my requirements are not listed there.
And I know that I can build this all on my own and invent another microframework. But why? There are so many of them already, and one just has to have all that I need.
Related questions
What's your 'no framework' PHP framework?
How do you convert a page-based PHP application to MVC?
Knowing Symfony2 well, I can assure you it's definitely possible to use it just for the "C" in MVC. The models and templates are completely free and are typically executed from the Controllers anyway, so if you don't call Doctrine or Twig specifically, you can do what you want.
As for functional testing, which is really what you're talking about in your article, what you want to look at is the WebTestCase class, which is well complemented by the LiipFunctionalTestBundle bundle for more advanced cases.
That allows for some things like this example of testing a contact form that sends an email, where the entire HTTP request is done in process, since the framework is written to allow multiple requests per process and has no global state, this works very well and does not require a http server to be running or anything. As you can see I do assertions on the HTTP status code of the response too, and was able to capture the email without sending it since in test configuration sending of emails is disabled in the standard distro of Symfony2.
That being said, you could also just use the Request and Response classes from Symfony2's HttpFoundation component. It should allow you to test your code, but IMO you wouldn't get as many nice features as you could if you'd use the entire framework. Of course that's just my biased opinion ;)
I would recommend downloading the Symfony 2 framework Routing component: https://github.com/symfony/Routing
Documentation is found here: http://symfony.com/doc/current/book/routing.html
Perhaps it does not satisfy all you requirements, but it's the closest.
If you are familiar with symfony (which I think you are) you should check out silex From their website this is what they say about it:
A microframework provides the guts for building simple single-file apps. Silex aims to be:
Concise: Silex exposes an intuitive
and concise API that is fun to use.
Extensible: Silex has an extension
system based around the Pimple micro
service-container that makes it even
easier to tie in third party
libraries.
Testable: Silex uses
Symfony2's HttpKernel which abstracts
request and response. This makes it
very easy to test apps and the
framework itself. It also respects
the HTTP specification and encourages
its proper use.
I'd add Net_URL_Mapper, it doesn't have the assertions though. Is that why you ruled it out?
Another pretty interesting thing is silex. It also comes with controller tests. I'd use that over Symfony2. But that's my personal preference.
Quite a understandable wishlist. I think we all hate it in testing when we run into dependencies that make testing to havoc. Tests should be simple and short, having many things to solve before and after running each test can be a burden.
From the description of your question it looks like that you pretty specifically know what you're looking for.
My first reaction would be that you use PHPUnit for this. It does not qualify all your requirements, but it's a base you can build on. It's highly expendable and flexible, however it does not support PSR-0 but has an autoloader of it's own so probably that does not weight that hard.
From the information you give in your question I'm not sure if the design of your testsuite(s) or the design of your application are hindering in writing and performing the tests you would love to.
I smell sort of probably both. If your application code is not easily testable, then there is not much a testing framework like PHPUnit can do about. So for example, if your controllers do not use a request object with an interface, it's not so easy to inject some request that was not triggered by the HTTP request, but by your tests. As HTTP is most often the entry-point into a webapplication, it pays to abstract here for tests. There exist some suggestions apart from specific frameworks: Fig/Http. However this is just a pointer.
Similar is this with the database scenario you give: If your application code is depending on the database, then your tests will be as well. If you don't want to test against your database all the time, you need to have your controllers being able to work w/o the concrete database. This is comparable with the HTTP requests.
There exists numerous approaches to cope with these circumstances, but as I read you question you don't look uneducated, but it's more you're looking for a better solution than exisiting ones.
As with every own code, it's pretty hard to find something that matches the own design. The best suggestion I can give is to extend PHPUnit to add those suites and constraints you need to for your application while you use the support of automated tests to refactor your application to fit the needs of how you would like to test.
So you can start with the tests and then develop the controller like you need it. This will keep your controller light I assume and help you to find the solutions you need.
If you find something that is missing with PHPUnit, you can first extend it on your own and additionally the author is very helpful in adding missing features.
Keep in mind that if there does not exist what you need, you need to code it your own. However if you're able to share (part) of the work with others, you most often get a benefit than by doing everything alone. That's a point for an existing framework, be it for testing or the application.
So if as of yet there is no such controller / MVC that does support easy unit-testing out of the box that fits your needs, chime in and develop one TDD-wise. If done right it can exactly match your requirements. However I think you're not alone with this problem. So not a very concrete answer, but I can only say that I made very good experiences with PHPUnit and it's extendability. That includes output tests you're mentioning in your question.
And probably a little differentiation at the end: It's one thing to test code-units and another to test if they all work in concert in the application with it's various requests. The last most often requires larger test setups by nature. However, if you can separate units from each other and clearly define with which other units they interact, then you normally only need to test the interaction between those which can reduce the setup. This does not save you from infrastructure problems, but those are normally not tested with unit-tests anyway (albeit you can extend PHPUnit to perform other type of checks).
A popular framework - even with a bad design - has the big plus that components tend to be better tested by use. That normally helps to go over the first years of your application until design issues in a framework make you need to rewrite your whole code base (probably).
As controllers often are sort in the middle of everything, this can lead to the scenario that you tend to test the whole application while you only want to test the controller(s). So you should think about the design and role of the controllers and their place within the overall application, what you really want to test with your controllers, so you can really make them testable according to your needs. If you don't need to test the database, you don't need to test the models. So you could mock a model returning random data to take it to the extreme. But if you want to test if HTTP handling is right, then probably a unit that abstracts HTTP handling is needed at first. Each controller relying on this would not be needed to test (theoretically) as the HTTP processing has been tested already. It's a question of the level of abstraction as well. There is no overall solution, it's only that frameworks can offer something but you're then bound to those paradigms the framework expects. AFAIK testing in php is getting more and more popular but that doesn't mean that the existing frameworks have good support for it. I know from the zend framework that they are working on this to improve the situation since longer. So it's probably worth to look into the more recent developments in the more popular frameworks to what this leads to as well.
And for the very specifics, you need to test on your own always.
Opting to PHPUnit and own testcases however does look as a practically way to me. Code your controllers as you need them for your project in TDD and you should get what you need.
Probably the more component based approach of Symfony 2 is better fitting your needs than what you experienced with Zend Framework. However, I can not suggest you anything specific as needs highly differ within application design. What's a quick and solid solution for one application is a burden for the other. See Page Controller.
You could take a look at the http://ezcomponents.org/ witch is becoming apache zeta
There are three ways how to make eZ components available for your PHP environment, please read the whole of this article before continuing with the practical part:
Use PEAR Installer for convenient installation via command line
Download eZ components packaged in an archive
Get the latest sources from SVN
I haven't got my hands into it yet but looks like a good solution...
Seldaek: WebTestCase isn't quite the right thing - it's for testing a view directly, and a controller or model only indirectly.
A unit test case for a controller would invoke the controller, likely giving it a mock object for the templating engine (e.g. a mock Smarty object), then check the values that were assigned to that object for display: for example, if you invoked the controller for /countries/south-sudan, you could check that the template variable $continent was set to "Africa". This kind of unit testing wouldn't actually involve any template rendering in most cases.
Is there a way to use Doctrine using the model classes I've already setup for my Symfony applications without having to call Symfony with all that overhead?
This is more to satisfy a curiosity than anything else. For all the scripts I've used, I've just been able to instantiate Symfony (which typically turns out nice since I have all of the features that I'm used to working with on this particular project. But there has to be a way to load Doctrine and use the Symfony model classes without Symfony... Right?
Doctrine isn't dependet on symfony. Doctrine is a "framework" on its own. It has it's own autoloading and can therefore work with it's classes like a regular PHP app. You can integrate Doctrine with other frameworks if you want (like CodeIgniter or Zend). So you have every freedom you need without the need to do some tedious migration of your models/data/... from one system to another.
I've come to the conclusion there really isn't a way to use the model classes from Symfony elsewhere. With a little work, you can port over the classes to a new Doctrine model (even if you use the generator, since the main model class just extends the base which extends sfDoctrineRecord (from the API docs, you can see which functions will need to be removed).
Otherwise, there isn't a practical way of doing that.
Anytime I need to access the Symfony model, I'm making a task or plugin since I do typically need part of Symfony's functionality.
As far as Symfony2 goes, just looking at the documentation makes me want to run screaming. It's not mature in any form or fashion (but, then again, neither is Symfony "legacy"). So, I'm not sure if the process would be any easier there.