My team have to maintain a large php application that was very poorly written. It is a mix of html, javascript and SQL on top of a large poorly designed database (ex. it has a table with few hundreds of columns). The only advantage of the codebase is that it works.
We are constantly bug fixing and rewriting parts of it.
I would like to give a structure to the rewrites we do, so I've though about integrating an mvc framework in to the codebase. Could you suggest any good framework for environment?
Here is a list of things that the I would expect from such framework:
The API must be very stable. We can't afford to rewrite the code on each release.
Custom session management or at least working on standard $_SESSION[] (To be able to talk with old code).
Custom authentication.
Using the raw SQL should be well supported (The database is hard to represent in terms of objects).
It shouldn't assume that I will have a table per controller.
I suggest Zend Framework for this purpose because it is a glue framework. With ZF you are not forced into the harness of how the framework expects you to work with it. You can pick what you want and gradually replace your legacy code with code from ZF. It also supports all the things you mentioned.
In addition, I suggest to run the various QA Tools found at phpqatools.org to support you in debugging and refactoring.
Framework comparisons
http://www.phpframeworks.com/
http://php-frameworks.net/
I'm echoing Zend just to list how it fits your specific requirements:
The API must be very stable. We can't afford to rewrite the code on each release.
As mentioned, the API tends to be stable between minor releases. Major releases with changes shouldn't be hard to integrate.
Custom session management or at least working on standard $_SESSION[] (To be able to talk with old code).
Zend_Session does exactly what you want. The default session store is $_SESSION to which Zend adds a namespace concept. Your existing code should be fine, and any new code can use the Zend object to ensure there are no variable name overlaps.
Custom authentication.
Zend_Auth has a few authentication backends, but it is designed to allow you to implement your own auth.
Using the raw SQL should be well supported (The database is hard to represent in terms of objects).
Zend_DB implements the table gateway pattern which will allow you to access the data via object; however, you can also just use SQL directly and get the results as arrays.
It shouldn't assume that I will have a table per controller.
Zend_Controller and the rest of Zend's MVC implementation make no assumptions about the Model, leaving that completely up to you. I'm sure some people don't like that, but it is the one area of MVC design that varies greatly from project to project - so that's left completely to the developer. You could extend some of the DB classes, or just use the existing DB access code.
That's an example of the pick-and-choose mentality of the Zend Framework. You really can use any of the library by itself. That should work well with your project. For example, you could use Zend_View without the rest of the MVC classes just to move your presentation into templates. Or just use Zend_Auth to replace the existing Auth system. With Zend you can slowly move your project into a more structured state, little by little.
Related
I'm planning to build a single PHP web page that will contain lots of structured data in nested divs, spans, bootstrap elements etc., like:
Hardware
Notebooks
HP
Apple
Dell
Tablets
Apple
Samsung
Software
Operating Systems
Windows 10
...
The list ist really long with far more than 100 elements. The elements will change from time to time, but the structure will be the same for all elements and sub-elements.
Now, I wonder if plain HTML+CSS is the best way to code this page. As the structure of the elements is always the same, so it would probably be a good idea to use templates. However, I'm not sure if I really should set up a database and some kind of PHP framework like Slim or Laravel/Lumen in order to generate the code. After all, it's just a single page without and routing, forms, login etc. So this might be too much.
Perhaps, a templating engine like Plates could be the answer? But where should I store the data?
What would be your choice for such a use case? Single page with lots of structured data?
Any help is greatly appreciated!
Based on your subject line, I want to clarify something and then suggest a solution.
PHP Components & Composer
State of the art PHP development utilizes Composer to orchestrate component libraries. This could be in the form of a full stack framework or in the form of just a few specific component libraries that solve the problems you have.
Datastores
Your sample shows data with simple hierarchy. Certainly for ease of maintenance a datastore of some type would be helpful. A relational database or a document database will do the job. If that is what you want I'm going to suggest you use a specific ORM or at least a portion of it, and that ORM is Doctrine.
Why Doctrine? Because it supports a number of the most popular open source RDBMS, and it also allows you to use it's DBAL layer without the full ORM, if you just want to implement a few simple queries. With that said, if you have the option of using MongoDB, MongoDB collections support hierarchies very well. A great feature of Doctrine2 is that it has support for MongoDB, which differentiates it from most other PHP ORM's.
The only real reason to go to all this trouble is that you also intend to create an administration tool that will let you maintain your hierarchical data. If you don't, you could just as easily have a script that you include that has the data in PHP array form.
Templating
For templating, my suggestion is that you use Twig. As part of the Symfony components, Twig is both self contained and part of the Symfony full stack framework. It's robust and well designed, and has numerous features (although to be fair, Laravel's Blade has similar features in most cases) and includes support for ESI which could be a great feature for a relatively static page like the one you describe.
Templating in twig, vs writing PHP code to do the same, lets you focus on your markup and avoid introducing a lot of PHP code that will turn your view code into spaghetti.
Components
The important thing is that you can simply use the few components you need to support your application, and you certainly don't need either Laravel or Symfony. Since Symfony began its life as components (and was the foundation for the Laravel project in fact) I'd push you towards the Symfony components, although at the end of the day, you could also utilize parts of Laravel (Blade, Eloquent) in the same way that I'm advocating you use portions of Symfony. Symfony simply is the community and stack I prefer, and has a longer history of being used on a component basis in other projects.
Try out the new minimal Symfony4
Last but not least, the newest version of Symfony (Symfony 4) is really worth looking at for a number of reasons. It essentially is now a micro framework, that comes with the bare minimum of components. They advertise it as 70% smaller than v3.
What differentiates this release is the innovation of Symfony flex with recipes and Composer integration. It is now built to automate a lot of the things that you might otherwise have had to figure out on your own for putting these components together into an application.
Take a look at it and see if it might help you get your application built with minimal components and minimal time spent having to learn how to make things work together.
In summary, I'd suggest you consider:
Symfony Components (You might want a few more depending on your
final solution).
Doctrine2
Twig
Symfony4
When do we have the necessity of using the frameworks in PHP. I have heard about zend framework and symfony. I have read about them but still didn't understand that exact point why we use the frameworks in software development.
Frameworks often provide you the boiler plate code that you would have to otherwise use, such as: Session Management, Templating, Database access etc etc.
In terms of proper software engineering, using these frameworks tend to promote proper design with patterns such as MVC(Model, View, Controller). By using this pattern, you can increase code reusability, separation of concern, etc.
By utilizing the database access that these frameworks provide you, you can write efficient models that can interact with the database while promoting code reusability. Another thing to consider with databases is security, such as SQL injections. Most frameworks now-a-days will automatically protect you against these type of attacks. If you were to write your own code(without a framework), you could end up leaving some sort of query wide open for sql injections.
For controllers, these frameworks tend to provide some sort of URL mapping. An example might be domain.com/posts/edit/5. The framework will then parse this url, and call the controller "posts", method "edit", and pass in the id 5. As you can see, if you weren't using a framework, you'd have to write all this code yourself, which would increase the amount of time coding and more chance of mistakes.
For the views, often times templating systems are in place to help reduce the amount of html, css, javascript etc you write. Not only that, they also provide structure for your views. In other words, they help you put your views in directories/locations that make logical sense(in terms of reusability, ease of use, etc).
Summary:
Because of all these features, you can see that not only will this reduce the amount of error/bugs in your system, but also decrease the amount of developing time.
Of course there are downsides to everything, and this is no exception. The main problem is the learning curve of learning these new frameworks. Often times frameworks provide so much that you have to learn all these new features just to get up and running.
Some popular PHP frameworks:
CodeIgniter
CakePHP
Zend Framework
Symfony
Getting Started Guides:
CodeIgniter
CakePHP
Zend Framework
Symfony
In terms of never using a framework before and wanting to get started, I'd highly suggest CodeIgniter. The learning curve is no where near as high as the other ones, however provide enough boiler-plate code and features that it should get you up and running.
If you want to do your own research(which you should!), here is a comparision table of all popular PHP frameworks:
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#PHP_2
Frameworks are usually used to accelerate the development of a project. Imagine having a bunch of extra new functions to help you with things like logins, page generation, database management, etc.. on top of the basic php functions. Basically Frameworks are made to save time and stop reinventing the wheel every time you make a new site/etc...
I have used CodeIgniter to build a few website and web applications.
The main advantage is that you get many pre-built components such as database abstraction, sessions management, email sending tools, and so on in one consistent interface and one package, so you don't have to spend time looking for these components that may or may not work well together.
Each framework has a different feel to it, a learning curve, limitations, you need to try them out and get a feel for it.
Many years ago, I was using Macromedia's Dreamweaver with a 3rd party extension to build my web applications. Since that time, Dreamweaver is owned by Adobe and the 3rd party extension is off the market, so I have legacy code with no support. For me, being messed around my market forces gave me the incentive to seek out a framework that was "desktop independent".
Summary: As a web developer, the primary benefits of a framework are ease of use, reusable components and greater control over rate of obsolescence.
Another point not made (i think) is that regardless of framework, but assuming it is well made, mature and has a community is that it has a structure that is imposed on the developers, whether it be MVC or REST, that future developers can quickly get to grips with when extending or maintaining the codebase.
So the naming convention for classes and objects & structures, the structure of the files and directories , the location of third party code, the templating system, localisation/internationalisation etc. in a well designed (and mature) framework will be well defined and accessible through third party or community maintained documentation.
I'm planning on creating a small web app using PHP. The last time I used PHP was sometime around 2002/2003 where the code tended to be a horrid mash of PHP/HTML and Javascript shoved in a single file. I think I might have even been using PHP3...
I now want to relearn and want to know what's changed and what helper libraries and tooklits exist that might save me from unknowingly reinventing things.
E.g is there a "standard" MySQL library, or do we still use the basic PHP functions (as a side question, do stored procedures work in MySQL yet?)? What do I need to know in order to make a "modern" website that doesn't rely on whole page HTML form posts to send data back to the server, etc.
Welcome back. PHP has gotten better!
If you can, start using 5.3 from the start; be aware though that many web hosts don't support it yet (if that is an issue). If confronted with PHP 4, run away screaming: It is no longer fit for production use.
The major development is finally proper OOP in PHP 5. Getting familiar with that is the only really mandatory thing in my eyes.
Several popular frameworks have evolved that do a lot of low-level work for you. The Zend Framework is a very high-quality code base to work with and my personal favourite because it's also usable as a component library that doesn't force its design principles upon you; there are others. (Here is a comparison site).
PDO is definitely the low-level database class de jour. It has parametrized queries preventing SQL injection and supports a number of databases.
The MVC design pattern is a very popular design pattern for building dynamic web sites and applications, and is embedded as a design philosophy into most PHP frameworks.
Class Autoloading is a great new PHP 5 feature.
A relatively little-noticed new development is the Standard PHP Library that brings clean, OOP solutions to everyday PHP problems. For example the DirectoryIterator that allows for easy recursive walking through directories; the ArrayObject provides an OOP interface to many (but not all) core array functions.
The DateTime class will replace the old UNIX timestamps over time. It provides improved functionality, and can work with dates beyond the 32 bit timestamp's 1970-2038 range.
This is some of the stuff under the hood. There are important client-side developments you want to be at least aware of; namely Ajax to fetch server-side data without reloading the page, and using a JavaScript Framework like jQuery to deal with the details. CSS you will already be familiar with.
Move to Zend framework when you start , first do some good research on OOP. Make sure you are understanding well terms as polymorphizm and inheritance. The last thing you must learn are php patterns like singletone pattern and factory pattern , abstract classes and interface implementation.
Here are solutions:
Use ORM to abstract from SQL >> E.g is there a "standard" MySQL library, or do we still use the basic PHP functions
Use MVC framework >> helper libraries and tooklits exist
Use Javascript for better user experience JS Frameworks >> make a "modern" website
I have ready numerous posts here on SO about framework1 vs framework2 however it seems to be alot of personal opinions that are one sided. Based on the following can someone tell me which framework would be ideal for my needs?
Build a rich featured API where other sites and devices can use the API to use website features and access it's content.
RSS Feeds with both XML and JSON for jQuery interaction.
Ability to use layouts / templates that are customizable.
Use of plugins so that I do not need to duplicate code.
Database querying with relationships.
GREAT documentation.
Actively supported.
Doesn't REQUIRE command line access.
Easy to manage file uploads and move the files around so only certain users can download them.
Customizable access level so users can have different access levels depending on which project/section they are viewing.
Low overhead usage.
SEO URLS that do not require the '/view','/edit','/add' in the urls (depending on which action you want to do.)
Support for jQuery
There have been a few frameworks I have seen that support some of these but not all. I am currently using CakePHP for one project but do not think it would fit my needs as the database querying can get horrendous. I have heard a little bit about CodeIgnitor however it doesn't seem to easily use templating (maybe I just misunderstood what I read).
If you could tell me which framework you think would be ideal for these needs and why that would be very helpful!
I'll just spamvertize my little framework overview table here. The simple table answers a few of your technical points:
http://matrix.include-once.org/framework/simple
Use the detail/feature view to cherrypick your options.
RSS isn't a standard feature even with the big frameworks, use a PEAR library
templates: all frameworks use them
plugins: depends on your concept of plugins, most frameworks are extensible though
look for "ORM"
GREAT documentation: that would limit you to codeigniter or cakephp
Doesn't REQUIRE command line access: except symfony+cake, few do
file uploads: this isn't a standard feature, but I'd just mix and match a library
Customizable access level: practically all frameworks come with a permission system
Support for jQuery: this is surprising. Prototype seems to be very strong, only half the frameworks use jQuery by default
CakePHP database querying doesn't have to be horrendous. (Though, I remember my first few projects were definitely hard on the database)
With the right optimization, normalization/de-normalization of your data, and a few tweaks here and there (persistent models comes to mind), you can accomplish everything you've inquired about with CakePHP, and keep your database load to a minimum.
That said, if you truly want to move to something else, I'd go with Zend Framework.
Symfony is bloated, (and yes, fanboys, this is still true).
Codeigniter is super lightweight, but you're going to be doing a LOT more work to accomplish your listed requirements. I've spun up two codeigniter applications, both relatively simple, and both took twice the work / twice the amount of new code than if I had gone with say, CakePHP.
A lot of religious fanaticism floating around when you talk about frameworks. But take a look at the documentation of Fat-Free Framework. It just might catch your fancy and requirements.
Before I answer, let me qualify that I'm certified on Zend, a frequent user of CodeIgniter, and daily user (and hater) of Symfony.
Zend's setup, especially if you're doing a small-medium sized site can be ugly. Especially using the data mapper strategy, you're talking a thousand or more lines of codes just for the model setup. CodeIgniter is much better setup-wise, but still not insignificant.
Command-line free --essentially-- knocks out Zend. It's doable, but not fun (see thousand lines of code, above) Built-in user auth isn't nearly as good on CodeIgniter as Zend, perhaps that's a serious knock....definitely no templating there. Symfony is flat-out done because of the addition of /view /edit, etc.
Hate to break it to you, but it seems that many users of all these frameworks are not native English speakers. Forget about Symfony, seems entirely eastern-European based. I'd hate to be a new-to-php user of Zend Framework with all the competing tuts with their assumptions of some semi-complex concepts. There's a reason that Zend's training is expensive and full.... Again, CodeIgniter is not horrible, but still can be frustrating.
Simply because of our extensive use of Jquery and desire to avoid a ton of hack-around, my company has dumped the frameworks altogether. Now setup is purposeful, not for a framework...just build a DAL, assemble classes, build views, and done. Established functions are re-purposed as "plugins" that we actually know and understand. Most interaction is Jquery based Ajax (sometimes XAJAX) which really doesn't take advantage of the frameworks anyway--and fights tooth and nail with Symfony. For those who argue that frameworks force MVC, I have a VP of Development who does that just fine, thank you. Perhaps it's not the right answer for you, but we're glad we went this route. It's saved weeks worth of documentation-hunting.
Can someone please derive a concrete example from the following:
http://www.urdalen.com/blog/?p=210
..that shows how to deal with one-to-many and many-to-many relationships?
I've emailed the author some time ago but received no reply. I like his idea, but can't figure out how to implement it beyond simple single table relations.
Note: I don't want to use a full-blown ORM. I like doing my SQL by hand. I would like to improve the design of my app code though. Right now each domain object has its own class full of queries wrapped in static methods. They just return scalar, 1d-array (record) or 2d-array (recordset) depending on the query.
The problem of ORM's (The impedance mismatch, as it's called) is precisely with relations. In an object graph (In-memory objects), relationships are pointers to other objects. In a relational database, relationships are reversed; This makes it impossible to do a simple mapping between the two models, and that is why ORM's are so complex.
If you want to stay close to the database (avoiding an ORM), then you shouldn't try to abstract relationships away. The way I write datamappers is something like the following:
$car42 = $car_gateway->fetch(42);
$wheels = $wheel_gateway->selectByCar($car42);
In contrast to the ORM way:
$car42 = $car_gateway->fetch(42);
$wheels = $car42->selectWheels();
This does mean that the gateways end up in your client-code, but it also keeps things very transparent and close to the database.
If you're looking for a simple and portable DataMapper ORM, have a look at phpDataMapper. It's only dependencies are PHP5 and PDO, and it's very small and lightweight. It supports table relations and some other very nice features as well.
Given your response to Tom's answer, I would recommend that you look at something like Zend Framework. Its ORM has a take it or leave it architecture that can be implemented in stages.
When I came to my present employer, they had an application that had just been completed months previously but had been through one or two prior versions and the current version had been in development six months longer than it was supposed to have been. However, the code base was mess. For example there was no abstraction between the database access logic and the business logic. And, they wanted me to move the site forward building new functionality, extending existing features, and fixing existing bugs in the code. To further complicate things they weren't using any form of sanitation on data inputs or outputs.
As I started to wade into the problem, I realized that I would need a solution to abstract concerns that could be implemented in steps because they obviously weren't going to go for a complete rewrite. My initial approach was to write a custom ORM and DAL that would do the heavy lifting for me. It worked great because it didn't intrude on the existing code base, and so it allowed me to move entire portions of the application to the new architecture in an unobtrusive manner.
However, after having ported a large portion of the user's area of our site to this new structure and having built an entire application on my custom framework (which has come to also include a custom front-end controller and mvc implementation), I am switching to Zend Framework (this is my choice though I am certain that some of the other frameworks would also work in this situation).
In switching to the Zend Framework I have absolutely no concerns about the legacy code base because:
I can build new models and refactor
old models (built on my custom
framework) unobtrusively.
I can refactor the existing
controllers (such as they are) to be
wrapped within a class that behaves
in a manner consistent with Zend's
MVC framework so that it becomes a
minor issue to actually begin using
Zend's Front-End Controller.
Our views are already built in
Smarty so I don't have to worry
about separating controller and view
logic, but I will be able to extend
the Zend Framework so that I can
render existing templates in Smarty
while building new templates in
straight PHP.
Basically, Zend Framework has a take it or leave architecture that makes its a joy to use within existing projects because new code and refactored code doesn't need to intrude on existing code.