We are currently looking joining an open source PHP farmework project instead of continuing to work on our own PHP MVC code. Likely candidates are Yii and Solar, because they appeal to our own coding style, have tackled issues that we feel need tackling.
I realize there are plenty of PHP frameowrk related questions on SO already. However, I'm having a really hard time finding people that actually use one of these (esp. Solar) in a real world environment.
So, my question: did anyone work a real life project with one of these? How did it work out for you? What were the major issues?
I'm not looking for benchmarks or excitement about the theories behind each of these. It's clear that their creators of both frameworks did a tremendous job. What I want to know is:
did you use it?
did you like it?
pro's and cons based on real world use?
I use Solar daily for internal applications at work and personal projects at home. It is a top-notch, solid framework that I can highly recommend to anyone. It is in beta3, but stable should be coming along in the next couple of months.
A common criticism is the lack of documentation. I am happy to say that that is changing rapidly. New documentation is being written daily. In fact, two new chapters are already up.
A great way to get involved in Solar, or to get questions answered is to visit the IRC channel #solar-talk on freenode, or join the Solar Talk mailing list.
Visit the Solar website for all the info.
I can't comment on Solar or Yii because I've never used them. When I've given both a cursory look, they did not seem as stable as frameworks I've used before. I've developed with CakePHP for years and have run into the PHP 4 barrier with it, where continuing to develop for PHP 4 does not make sense any longer. Ultimately, it just costs more money.
If you are looking for a framework to build upon, I would recommend looking into the following:
Zend Framework
Lithium
All are very modular by nature (including Solar and Yii), with support for integrating excellent tools like the Doctrine ORM. Some assume Doctrine is your ORM of choice. Honestly, it should be.
ZF is decidedly PHP5 only, which I like. I also appreciate the modularity of it. I can create a base "project" and then add individual "apps" to it, each with their own models/views/controllers. You can also use its classes/features individually without the entire framework bootstrapping process. It is backed by Zend, and is very mature -- I'm assuming because so many trained eyes have used and improved it. The consequences of this are fantastic: just browse through the web site, follow the quick start and look at the available components in the reference guide and you'll see what I mean.
Lithium was forked off from CakePHP's Cake3 project, aiming for a framework with support only for PHP 5.3 and PHP 6. It is decidedly PHP 5.3 only, which means it has hitched its wagon to the newest stable PHP with the most features, such as anonymous functions, a native MySQL driver, and much more. Worth looking into if you are able to move your team to a PHP 5.3-only environment, especially if you have people who know the value of more modern programming techniques found in languages like Python or Ruby. It is a young framework, but has much of the same talent behind it that CakePHP has had, so that gives it a huge thumbs up in my book.
I've used Yii a bit now and have found that it's worked quite well for me. The main con against it is that it's still relatively new and most people haven't heard about it.
That said though, if you were to pick it up as your main framework, that would help it become better known and you might even consider helping Qiang with some development work.
Just when you are deciding, make sure you've had a look through the issues list to make sure that you are aware of what the current bugs are, and what the upcoming features/changes will be.
I can't comment at all on Solar.
I've worked for a handful of digital and new media design agencies in the North East of England for a couple of years now and have yet to come across an instance of the development team using a framework.
Most web design and development agencies these days favour creating their own framework or CMS; I guess it's a form of validation for them. They don't feel they're worth their salt unless they can develop their own systems and solutions from scratch. Hell, I'm the same and have build my own CMS!
The advantage of using an existing framework is that development time is reduced as commonly-used libraries and helpers are already pre-built and ready to be implemented. However, the use of a framework can easily become a con if the framework used isn't commonly known.
So for instance, if you use an obscure framework like Solar that not many developers are familiar with, any other developers working on your sites are going to have an additional learning curve, which in turn increases development time; the opposite of the desired effect.
Hope this helps you. Commonly-used PHP frameworks out there at the moment include CodeIgniter and CakePHP.
Related
Do you guys have any experience with the new PHP framework Jackal?
http://www.jackalphp.com
It is fresh, just-released and I was wondering if it is a good one. Can it be a substitute of frameworks like Kohana, Symphony or Zend? Well Zend has too many pre-biuld modules and functionality. Maybe a comparison with Kohana is better.
I am asking cause I am looking for a framework to use in my future projects.
Thanks
This looks more like a hobby product than a serious framework.
A sure sign it's not production ready is the lack of Unit-Tests. There are none in the downloadable package. Any refactorings and additions the developers apply to the framework are high risk. Without Unit-Tests, they cannot guarantee change does not break existing functionality. You do not want to build an application on top of that.
I also could not find any license information. There is none in the source code. The ToS link on the website is empty. Without a clearly defined license agreement, you are putting yourself in danger of infringing on IP.
There is also no information regarding how the development updates are handled. Can minor version upgrades contain BC breaks? And why is there no public repository when Sourceforge and Git are free to use. I couldn't find a bugtracker either.
I'd stay away from that unless they professionalize.
We probably released the framework a little prematurely, but we are very serious, and this is not a hobby project. We have been using it in commercial application development for over a year now.
You do raise some excellent points about things we are missing. We are currently using Assembla as a repository, but we will soon be moving to something else so that we can make it public.
Unit testing and licensing information are also on the way.
If those are the only things you are concerned about, that's great news =). Our biggest goal was to build a framework that leverages the advantages of a procedural language like PHP, speeds up development, and just makes sense. We have used a lot of frameworks before, and while they all have their strengths... none of them are what we, as developers, need in a framework. While that is a very subjective statement, I believe Jackal makes some serious improvements on other frameworks that developers will come to love.
In short, we really appreciate you taking the time to give Jackal a chance, and hope you will continue to follow our progress as we add more "professionalization" to our framework. =)
Best Regards,
Jackal Team
I already have v1 of my webapp written in Codeigniter/PHP.
I'm now working on v2, which will have some significant changes to all MVC components.
I'm pretty comfortable with CI and I like it. Very intuitive for a C coder like me.
But I am wondering if it is worth it to rewrite the app in Rails?
Will the productivity gains be worth the cost of learning another framework from scratch?
I want to be practical and not chase something just because it's cooler or more fun.
Here are some productivity criteria:
HTML and CSS generation is fairly labor intensive. Does Rails have anything distinctive to help with this?
I'd like to reuse other people's code for commonly implemented functionality (e.g. interfacing with FB, Twitter, and other social sites). How much more 3rd party code reuse would I get with Rails?
How much more benefit would I get from the Rails community vs. CI community?
Make automated testing easier. I test manually today, which is labor-intensive.
I'd appreciate specific benefits vs. idealistic/religious arguments.
Thanks!
Codeigniter is obviously a framework built on PHP. While there are fundamental differences between PHP and Ruby, all of your criteria can be met with either of the two languages. Migrating to Ruby would seem to be a waste of time considering your requirements. There are plenty of ways to automate HTML/CSS in PHP and there are numerous open source Facebook/Twitter integrations (just check FB and Twitter developer sections). There are also plenty of open source PHP testing options available. Google is your friend! IMO it would be a big waste of time to rewrite your entire application for the sake of your criteria when there are plenty of PHP solutions to your problem.
I think the better comparison here would be CI to Symfony. Symfony 1.4 is a PHP framework pretty much on par with Rails functionality - as far as I can tell through my research, anyway (I'm not a Ruby programmer).
If you were to switch to to Symfony, you would gain a lot of productivity tools. Symfony 1.4 + Doctrine has the ability to generate a lot of your code/interface for you. Symfony/Doctrine likes to keep you away from repetitive tasks such as building models and data validation.
If you want to do your research ahead of time, I suggest reading through Symfony's free e-book Piratical Symfony to give you an idea of how things work in Symfony.
Now, with all that said I feel obliged to mention that the Symfony team is working on Symfony 2.0 which will not be backwards compatible with Symfony 1.4. The expected release date is March of 2011. I expect that maintenance on Symfony 1.4 will continue in the future.
-- Edit --
I also think that sticking with your native language would allow you to develop with the least amount of overhead. Changing to a new language means having to learn it's up's and downs in order to be truly productive.
IE to be at a point where you're not coming back in 6 months to fix a bug that an experienced Ruby developer would have known to avoid.
To me, this is more a question of how big your current web app is. If it took you a couple of weekends and you do not have a tight deadline, I would switch to Ruby/Rails.
However, if it's significantly large and you actually want to come up with R2 in a timely fashion, I would suggest sticking with PHP.
As to your specific questions, I'm not too familiar with PHP, but I don't think Rails will give you a whole lot more in the HTML/CSS department. Not sure about the next two bullet points. Ruby does have much better automated testing tools, with new stuff coming out all the time.
Here are a couple links about Derek Sivers, who switched from PHP to Rails to PHP and now likes Rails again. It might help your thinking.
http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_switched_back_to_p_1.html
http://railstutorial.org/ruby-on-rails-tutorial-book#foreword
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm about to begin building a huge clinical healthcare application with PHP, and I'm looking for some advice on a framework. I need to be able to come up with a quick prototype, so it's important that the framework takes care of many mundane tasks; therefore, I've narrowed it down to CakePHP or Symfony.
I'm hoping to get a few developers opinions that have worked with both frameworks.
Thanks, Pete
IBM published an article here on both those frameworks along with Zend in a comparisson, see:
http://www.ibm.com/developerworks/opensource/library/os-php-fwk1/?S_TACT=105AGX44&S_CMP=ART
I personally use CakePHP, it's pretty awesome compared to just straight out PHP. Easy to build things in, very MVC focused, reasonable integration with third party components. I did have some issues with the lack of any sort of discernable upgrade path between versions though. I can't speak for Symfony, but I believe it's more heavyweight than CakePHP.
Take a look at the screencasts for CakePHP as well, they give a good overview:
http://cakephp.org/screencasts
I'd like to counter some of the arguments presented above. I've worked extensively with Zend Framework and symfony, and I've had a brief look at CakePHP.
First of all, compared to symfony, the ZF documentation is not "extensive" - its on the other hand quite superficial. Second, I think that the symfony community is much more available and helpful than the ZF framework in general, and the development process is much more transparent.
However, I agree that Zend Framework enjoys the advantage of being supported by Zend, which might be a powerful argument for enterprise projects.
In my experience symfony is more of a framework than ZF. In symfony you use the whole package - or the whole frame, while you in ZF is able to use tools to your liking, making it more like a "toolbox" than a framework.
Also remember that if you like some of the tools in ZF, you'll be able to use these in symfony (and probably also CakePHP) projects, alongside symfony/CakePHP.
This is not really an answer but more like a general comment to the answers given above.
I recommend reading the right answer for this question. It mentions Zend Framework as the best choice, and presents some correct points to justify it.
Let me begin by saying I have no prior experience with CakePHP or Zend other than having browsed around in the framework code and their documentation. I started using Symfony about 15 months ago and I researched before what framework to use. I decided to go for Symfony because I found the Symfony core to be written in a nice and orderly way. It felt like I could easily understand the framework by reading the code itself. Besides that I found an enormous amount of documentation that is really focussed on working with the framework to produce certain functionalities. Very pragmatic so to say. CakePHP just doesn't seem to fit my personal style and I perceived the core to be very hacky. Again, I might be wrong but this was how I felt about it back than. After 15 months of coding with Symfony I'm still very satisfied. Often you read comments or blogs that say it's too complicated. I think these people insult their own intelligence. It indeed takes a while before you get a firm grasp of the frameworks internals and approaches to problems but once you are past that point it really is an awesome tool. The community is very helpful and the future looks bright. All in all I can only advise you to go with your gut feeling when you look at the approaches taken by the frameworks and their code and coding styles. You'll spend a lot of time in these frameworks so you must feel at ease when you look at their code and their solutions for common problems. Every framework out there is terrible if you start fighting it, going along with it will make every one of them a great tool. Some might in the end turn out better than the other. I guess you'll know the answer to that yourself after finishing your project with it.
Good luck:-)
I've had minimal experience with both frameworks, but all i've ever heard about symfony was complaints (even though it seems to be used a ton!). Probably just that people don't spend the time to fully learn the framework.
From my experience both seem to be decent frameworks, but like any good developer you must understand at least the level of abstraction below what you are using to be effective.
Probably Zend Framework.
If you want something different try codeigniter.com
or it's oo version in php5 www.kohanaphp.com
I have not used other frameworks, but I use Zend Framework and it is great. benefits are:
clean and standard library, coding style, conventions, etc.
enterprise support: it is supported by Zend, the company that every PHP programmer knows
comprehensive manual, many blog posts and tutorials, at least 2 well written books
has packages on most open source operating systems, so easy to install and maintain
a very live open source project, updates come so soon you can't keep up to them.
open license: ZF uses BSD-like license so you won't have many licensing issues
My framework decisions boil down to this (note that I primarily use Cake, little Zend, and have fiddled around with CodeIgniter and symfony).
Zend is the most enterprisey. You get the folks # Zend supporting it -- I think it's development timeline is the most solid moving forward. It also has some great modules like PDF readers, etc.
CakePHP's focus (IMO) is rapid development. But it's consistently one of the worst performance-wise -- if you're going to have a heavy-use app, I think that Paul M Jones has some posts on benchmarks. Zend is about 2-2.5x faster than Cake, IIRC. If you don't have MVC experience, Cake can be a good choice b/c it def. locks you into MVC. I find myself constantly needing to think outside their pattern, though -- which is why I'm slowly moving to Zend.
The other frameworks have different strengths, too. At PHP|Tek in Chicago, CodeIgniter was the talk of the conference, so it might have a lot of momentum over the next year or two.
Cake and Zend also have super tight integration with some other enterprisey stuff like unit tests, etc.
Definitely Yii, we used it several times for the enterprise and were very satisfied with the result. I especially like its extensions like backvendor, coco, bootstrap.
For me Yii has been quite easy to learn and implement. Tried cake php but yii seems much clearer. Anyway whatever framework you use, you must continually improve your core language skills in parallel. This helps to take the maximum advantage of the framework that you`re using.
There are several questions about PHP frameworks, but I'm curious as to which one(s) are used in the commercial world when developing web applications with PHP. At my first web-based job, they didn't have a framework for the PHP codebase. Is this common when dealing with PHP? If not, what frameworks to companies producing a product (either a site that provides a service of some kind or a web-based product that can be purchased) using PHP tend to use?
Is this common when dealing with PHP?
In my experience, unfortunately it is. This is of course a gross generalization, but people who tend to learn PHP as their first programming language don't learn the essentials of maintainable software development and often don't really know how to write good code. I think this is a failing of the PHP community, where historically most learning resources don't emphasize good practices (probably because the authors didn't know any better!). You can of course write good code with PHP, as long as you understand underlying programming principles.
Companies will often start out with a hap-hazzard code base of PHP scripts that get re-used and gradually extended from project to project (often without source control!). The companies that know what they're doing and take it seriously will evolve this into some kind of in-house framework, or I have often found they'll move onto something without the historical crapness of PHP, like Django or Ruby on Rails.
If you're just starting out, there are several decent MVC frameworks that will form a good base for all your developers to learn and use. In no particular order:
CakePHP
CodeIgniter
Zend Framework
There are of course others as well.
That said, as always it depends on the project. Sometimes a framework either won't make sense or will be overkill, othertimes you're better off using a pre-built product (like a CMS) and building extensions to it.
Most frameworks are strongly focused on the presentation layer. Now, "corporate" is of course a rather vague term, but I assume you mean for more typical IT tasks, such as accounting, CRM etc. For these tasks, the presentation layer is a much smaller part of the entire application. Not only does this make said frameworks less important - it actually disqualifies them somewhat, since you don't want the restrictions on your model layer, that they impose.
I think it gets more and more common to use a framework. A few years back most programmers developed their own framework. But the cost to train a new employee for such a framework gets higher and higher. Therefore many companies are moving now to well known frameworks.
I guess that Zend is currently the most used Framework in the corporate environment. One reason is that it does not give you any restrictions on the model layer.
I can not predict the future but I guess that Flow3 will be used in the future too. It is the new Framework behind Typo3. And many Typo3 developers (web designers) who need to write web applications will probably use Flow3 then.
In last two three places I've worked the company had their own (private, built in-house) framework.
According to a PHP Framework Popularity at Work survey by Sitepoint in 2015 (7554 survey participants) the five most used frameworks are
Laravel (22%)
Symfony2 (14%)
Nette (9%)
CodeIgniter (8%)
Yii 2 (7%)
Furthermore survey results indicate, that
5% use a company internal framework,
3% use no framework at all,
3% use a CMS for everything,
1% use a simple MVC framework.
There seem to be continent specific framework preferences: In America and Asia, Laravel seems to be the framework of choice (except for Russia: Yii 2), whereas in Europe you'll find more Symfony2.
(Be aware that this is just referenced from one source -- see links above.)
The only enterprise-level framework I can think is Zend Framework. CakePHP, Code Igniter and others are only focused on RAD development.
Having experience with CI , yiiframework and calephp (not much, really) my opinion is that CI is not flexible as ohter 2, so I do not recommend it on larger-scale projects.
Anyone who disagree, just can try a demo project with cakephp and Yii and he will see how things are easier with them as crud,form validation etc.
Of course all have their disadvantages :)
recently i talked with a CTO of a company, offering a e-lecture solution and we talked about PHP for a while ... we both agreed, it is not the best language for rock solid solutions, but he pointed out the symfony framework, they used just before moving to java ...
also, flow3 mentioned by raffael is quite powerful ... most interesting thing to me is, it brings AOP into PHP ...
greetz
back2dos
You may want to look at www.flow3.org, it's a pretty comprehensive approach to PHP application frameworking and is rapidly approaching its first mainstream Beta release.
I'm not sure if PHP has gone into the enterprise market in the US yet but when i worked in a corporate office the language what they use is Microsoft .NET.
PHP is yet to enter the corporate world IMO. It is popular with the hacker world and maybe micro and small software/web companies.
We have been going back and forth a lot around our office lately about abandoning a proprietary framework that was developed here a couple of years ago and move to something that is larger and community supported.
Our current solution was built to include only the things we need and is very flexible, by flexible i mean that it is loose and the developers that have built sites with it over the years have take liberty in that, so a lot of sites we manage and have built and not to any standard at all. Here at the office I use the framework somewhat but prefer to use other tools. Over the years I have used a lot of PHP frameworks ranging from Code Igniter to CakePHP and have been a big fan of Zend Framework for all my personal projects so I am heavily biased and that is why i am asking here for advice from people who may be able to give me a more objective opinion. In the office a lot of work has been done on our framework so I can understand why some people might be hesitant to abandon it but the way i see it is this:
We don't currently spend a lot of time keeping our framework current and checking it over and over for bugs, we fix them as we find them. Which we should be doing
Any work done to improve our framework is directly put into our overhead column
We have a application built on top of our framework that is subscription based and closed source that we sell and I feel could be better if built to a better standard using a popular, community driven, framework that would require or encourage these things.
I searched and found this thread, Why do I need to use a popular framework?, that was similar to what I am asking but not quite. What i am asking for are opinions on as to why you would do one thing or the other, i don't really want to start a conversation about which framework is better, that will be the next step for us if we chose to switch.
Here are some of the reasons i see switching to a supported, open source framework as helping us in the long run:
As PHP puts out new versions the core of the framework will be updated to take advantage of those things without us having to do the work.
Security concerns with the libraries will be found by the community and patched without our involvement other than updating our code base with the current version.
Lots of information on the internet and exisitng code that can be used as reference
Ability to hire outside programmers that know the framework already, instead of hiring people and expecting them to have to learn how to use our proprietary one.
Ability to give back to the community through patches, plugins, helpers, and support.
Here are the negatives that I have come up with:
We will have to port all the existing code we have in our custom application to the new system
Our employees will have to be allowed a certain amount of time to learn a new framework and it's ins and outs
Our current framework is very flexible and loose which allows us to build things how ever we want and this keep our developers from having to follow and obey and conventions, which some developers seem to hate. I personally like conventions
Again it is probably obvious that I am biased and this is the reason I am asking here, I am open minded to what anyone might have to say.
Your question is really devilishly biased, because all pro's are long-term and all con's short-term development pains. :) But if the situation is even half as much as you describe, switching is the right thing and will save a lot of money in the long run.
My company is in the same sort of situation. We have a custom developed framework in Perl that never seems to get quite as much attention paid to developing new features and fixing bugs as the open source frameworks do. I and most other developers would love to switch to something open source for the benefits you mention, but nobody has the budget to spend the time porting code over. Our current plan is to use an open source framework if we have any small, new projects come up, and if that's successful consider moving older apps over.
I've mostly worked with Perl and Ruby, but a trend I'm seeing more of these days is frameworks allowing you to mix and match framework core components. For example, we're considering integrating parts of our custom framework into Catalyst. That way we can still use some of our custom developed code components (our own DBI class and some Mason templates) and porting our applications won't be as difficult. Ruby on Rails is also moving in the direction of being more modular.
Perhaps there's a PHP framework that might allow you to use some of your code, or at least make it easier to shoehorn some of your code into the framework instead of starting from scratch. Googling I see most of the PHP frameworks claim to be modular, but some appear to just allow you to develop add-ons, not swap out core components.
Sounds like you're doing some good analysis and I wish you luck in your search.
I think the most important points you highlighted here. The decision now, should be based, on numbers. Technically your analysis is perfect. What i would ask now is: How much it would cost for your company,to:
* keep your app to take advantage of new php improvements without break your old code (it means: architecture analysis, development and test, test, test).
* Do you have any developer/analyst focused in security development? (it means: security development life cycle, test, test, test).
* Do you have a development methodology? Normally those frameworks are kept under a good distributed development methodology.
I had the same question than you sometime ago, and my company decided to choose a framework, migrate our code, allocate 2 developers 1 day per week to work on the framework. To put our team to work with the framework development team was good, because we learned more about the framework, we helped the community (demagogy :-)) and we could add some business requirements in the framework features road map ;-)
I and my team are nearing completion of porting an existing application across to run on Zend Framework and it's gone quite well.
The old application had a lot of issues that were going to be big problems to fix and we decided to take the plunge and rebuilt it in ZF.
It has however taken a long time to port, I would estimate for our application it's taken us a good 4-5 months of dev to port everything across (we have taken the opportunity to rejigg the database and other areas of the system).
If you do go for it then be prepared to explain to your bosses why you need to spend a good chunk of time porting rather than working on income generating work. We were lucky to be able to use a new project as the impetus to carrying out all this work.
I see a couple of cons of switching over.
First, of course, there's:
We will have to port all the existing
code we have in our custom application
to the new system
Followed by:
We will have to port all the existing
code we have in our custom application
to the new system
and, last, but, not least:
We will have to port all the existing
code we have in our custom application
to the new system
You were talking about "money in the overhead column", and rewriting working tested code in to new working tested code doesn't add a whole lot of value.
If you're talking about introducing a new framework for a brand new, unrelated project, or one that uses little of the existing code base, then, sure, knock yourself out. That's a fine opportunity to switch frameworks, platforms, languages, etc.
But an existing, shipping, mature code base with existing knowledgeable folks working on it?
That's a hard pill to swallow, personally.
If you want folks to follow standards and conventions, then ... follow standards and conventions. Since you have a system that allows folks the "freedom to what they want", make "following standards and conventions" something they want to do.
It's always better to transition a system incrementally that throw the whole baby, bathwater, soap, basin and towels out the window just to go back and redo the exact same thing again.
Everyone wants to rewrite code, I want to do it. Our framework needs a "do over" here. But then we go "yea, but..." and what do we get in the end? N Months of effort to get back to where we are now. That doesn't do much in a world where time to market matters.