symfony vs cakephp [closed] - cakephp

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.
What is conceptually the difference between symfony and cakephp?

Just to balance out this thread, this is why I like symfony:
uses PHP5
it runs some really big sites like Yahoo! Answers, delicious, and Daily Motion.
good documentation. the jobeet tutorial on the website is awesome. walks you straight through all of the features, and after you are done you feel like you can build anything.
is highly modular; many of the symfony components work on their own.
allows you to choose either Propel or Doctrine as your ORM. Doctrine is really great and easy to use.
you can define your models with YAML or in PHP, its up to you. Some people don't like configuration files, and you can really limit their use if you want to steer clear of YAML.
the updated symfony cli (as of 1.2) is awesome. I agree with abales, before this version it was a little wonky, but now it is very well documented and follows a predictable format.
there are a lot, and i mean a lot, of similarities with ruby on rails, except that of course PHP isn't quite as pretty or flexible as Ruby(!). But, if you talk to a cake developer, they will probably say the opposite :)
the symfony admin generator, which is a step up from CRUD (which also exists in symfony), is a huge time saver. Using your data model it will generate customizable admin interfaces complete with list views (index), create, and edit pages. It's not like basic crud where it generates the source and you go in and modify it... You actually can define how each field looks, which fields you want to include, what additional actions you can perform on each object, and so on.
Conceptually, I'd say the difference is this:
CakePHP has a smaller learning curve. If you have never used a MVC framework, Cake will be easier to pick up and run with in a short amount of time.
Symfony feels bit "bigger," not to say that it is slow, but that there is a lot of code back there that will let you do a lot of really advanced things when you need to.
The best advice I can give is to quickly try to set up a your own simple data model in both, and experiment with some basic interfaces, and just see which fits your own coding style the best. I think both frameworks have very active and passionate user communities and you won't regret your decision either way.

CakePHP philosophy is similar to Ruby on Rails.
CakePHP is better for medium projects.
CakePHP is faster to learn.
CakePHP is lighter than symfony.
CakePHP's Database Interaction uses CRUD.
CakePHP uses the test system PHPUnit.
Is interesting in CakePHP Bake and scaffolding.
Symfony's philosophy is each version is different.
Symfony's is slower to learn.
Symfony's is best for large projects.
Symfony's Database Interaction uses Doctrine.
Symfony's uses the test system PHPUnit.
Is interesting in Symfony's Bundles and templates.

A big difference is in how models are created: CakePHP models are written in PHP, and Symfony models are written in YAML and powered by Propel. CakePHP's approach is more similar to ROR's ActiveRecord (although it isn't exactly an AR implementation). CakePHP, in general, is more rails-esque.
CakePHP's documentation and tools, in my opinion, have a wider target audience and the syntax and helpers are easier, but thy have yet to embrace PHP5 as their exclusive target (to autoloading isn't really there). In general, I prefer CakePHP's approach because it sort of follows an established standard, and I applaude it's organization. I'd also recommend Kohana for it's PHP5 goodness.
There's another post on stack overflow about this question, although its a bit different in focus.
Edit: I revisted Symfony to find the reasons I said 'no' and came up with these — your opinions and mileage may vary:
CakePHP also offers dead simple scaffolding and easy to understand CLI tools. Symfony's CLI syntax is a bit wonky to me, and 'CRUD' in Symfony just isn't the same. Combine that with Symfony's (awkard) action syntax and throw in Symfony's poorly designed (and challenging to understand) website, and preference for 3rd-party paid documentation (books on Amazon) and you have more ticks in the cons column.

Some of the claims about CakePHP and limitations above simply isn't true. The query is possible. You just have to know how to make it. The "automagic" of CakePHP is SUPER nice so you can hit the ground running FAST. It is BY FAR the FASTEST framework to development (hence why it's so closely modelled after RoR which obviously was a big success and buzz). There are more advanced behaviors to get data returned differently and make some of those more complex queries with a few short method calls and array parameters specified.
However. As far as I can tell, no other framework has as many "automagic" methods and classes. Cake takes the most common of tasks and provides an easy way to get it done. If you're really clever, you'll do most of your coding at the model level and make use of the app_model and app_controller file and have an extremely efficient application.
The console is great and always expanding. The community is truly amazing and there are many many contributions to help you get things rolling even faster. You can literally architect and then move "pieces" into place to build an app very quickly because most of what you'll need is available. You do not get that with any other framework. You have to spend a LOT more time coding usually.
Lastly. While the documentation was lagging, it is much better now and while Cake also got some harsh reviews during this lack of documentation and version 1.1 period...It was STILL good, just severely overlooked. With 1.2 and now Cake2 and Cake3 on the horizon...You're going to see a lot of opinions changing.
I have used CakePHP since 1.1. I'm a firm believer in it. I have used it for huge corporate sites. That receive millions and millions of hits per day...We're out of the realm of things like WordPress and Drupal for solutions. When you get to that level for a CMS type site, I am super glad to have CakePHP on it. Likewise, Symfony and CodeIgniter will help you with the scaling. I can't say anything bad about either of those frameworks either. I can only say that you will spend less time coding and find a larger community (and a super friendly IRC channel) with CakePHP.

I'm going through and documenting some of my responses to the above comments about CakePHP and some of it's (in some cases rightly) perceived faults.
Big websites are run using CakePHP, some being Mozilla Addons, Scratch by MIT, and Hot Scripts. There is a bigger list right at the bottom of the CakePHP website (http://cakephp.org). Regardless, any good developer should be able to build a scalable website using a framework as long as the framework isn't completely silly (CakePHP isn't too silly :D ).
It is true that there isn't one very good (free) CakePHP tutorial that goes through every feature of the framework, but the documentation is extremely well laid out and verbose. Anything that isn't clear can be cleared up through the Google Group and on IRC, and we welcome any and all changes/corrections to the documentation. Documentation is not just a core developer issue, as many things are application specific and people come up with interesting tips and tricks, and so thusly everyone is invited to contribute (Not just comment!). Of course it is all moderated, so most of the cruft/spam is not added.
The code is modular in that you can add in new code that supercedes core functionality. Much of the code is simply PHP classes. It is true that writing such functionality may be a burden, and I have not tried using alternate classes as fillins. Yes, it does not handle other ORMs, so you are stuck with the default, but this should be fixed in Cake3, which will be able to mix and match any other PHP classes at will (that includes Propel and Doctrine support).
The CLI is very good, and it is easy to extend for App-specific support. One example is that I recently developed a shell plugin that would automatically install any other CakePHP plugin that I have indexed from github. Took about 5 hours to build something extremely usable and flexible. I'm sure such functionality exists for Symfony, and it DOES exist for RoR :)
As for being Rails-like, it is and it isn't. Many things are similar, they are MVC frameworks after all, and CakePHP goes for the "Conventions vs Configuration" approach. PHP4 support mucks with a nicer syntax, which Symfony doubtless has because of PHP5-only support, but it is still extremely usable and intuitive. The framework does not provide EVERY feature of Rails out of the box as it isn't a straight clone. CakePHP is a framework, not a library (hi Zend), so it won't provide everything out of the box.
Generation of views is, I agree, a bit wonky in CakePHP. It is being greatly enhanced in CakePHP 1.3 and 2.0. It will support custom templates for each and every Model, View and Controller (as opposed to just a type of view as it does now). Also, there exists a set of shell tasks on github by a user going by neilcrookes that auto-bakes only certain types of views (including only admin views) which can be used in combination with custom templates to produce exactly what you want. CSS styling also helps :) but this is definitely something that can be improved.
CakePHP takes many varied parameters in it's Model::find methods, although in certain cases it may be useful to use raw SQL queries. The Model::find() method is very flexible and has not failed me insofar as creating complex finds. I suppose that is related to being comfortable with the ORM, which inevitably always takes time.
Form validation should logically be in the model layer, as that is where any action related to the database is being performed. You can specify alternate validation in a specific view I believe, or swap validations (there is a behavior for this but it wouldn't be hard to do so without it).
Multidimensional arrays are a bit silly, but you'd still likely have multidimensional objects. PHP4 had a broken Object Model and so that is why CakePHP does not use objects. This is being corrected in a future version of CakePHP (as I pointed out above in a previous comment), but it is useful to have a framework that supports PHP4 in some cases. Again, YMMV and I agree that full PHP5 will be a great boon, both in speed of the application and of development.
Databases can be swapped out at will. CakePHP does not allow functionality that is inherent in only one type of DB (hence the dropped support of ENUMs that are only in MySQL), so that the ORM is always supported and can always build valid queries. You can have multiple databases in an application, one per each Model if you wanted, and can swap them at will or even not use a database at all for a specific model. So no, it is not tied to a specific database.
In the end, your choice is your own, and I wholeheartedly suggest looking into both and reading through the documentation, checking out the Groups, IRC channels, blogs and any forums for both and seeing which framework suits your development style the best. Reader beware, I'm a CakePHP developer so my post has some bias.

Further to the existing answers, you should try both if possible. I use both quite a bit, and over some time, have come to prefer symfony.
but I'm fairly convinced that its not because one or other is better, but because symfony happens to suit the way my mind works better, its closer to what I do when I write software outside a framework, so feels more intuitive. I expect that others may find their mind fits the paradigm of another framework.
Having said that, I do think that cakephp's objects are a weakness, through the use of arrays rather than objects. (This is something that periodically develops into an intense hatred inside me whenever I need to do something that it makes hard ... ! ) They could do exactly the same, but return objects rather than arrays to represent data, and I think most of the issues I have would go away - you'd be able to add extra functionality into the data objects to achieve the things I want to do, rather than writing functions in the existing model class and passing them an array.

The model layer of CakePHP is a mess. Try doing simple things like a many-to-many relationship between a Category and an Item object and then retrieve all the Items in a Category that have a specific property set.
Like:
SELECT items.* FROM items, categories, item_categories WHERE item.available=1 AND category.id=1 AND item_categories.category_id = category.id
Something so trivial is not possible in one statement in cake with the find() method of a model.
There is also no way in the core API to add a single many-to-many relationship as in one item to the item_category table above. There are a couple solutions online including a behavior that someone posted in the bakery (http://bakery.cakephp.org/articles/view/add-delete-habtm-behavior), but that's just stuff that any good ORM framework like Propel, Torque(Java), Hibernate(Java), SQLObject(Python), SQLAlchemy(Python) support right out of the box. Basically you're either going to have to write a lot of PHP code to add those missing features or use raw SQL queries but the main purpose of a framework is to avoid doing those things so that you can focus on the application that you're writing so you're not really gaining much with CakePHP.
There are a bunch of other problems and they all really have to do with the model layer including the form validation being tied into the model layer, having to deal with messy multidimensional arrays, having to use raw sql and tying your app to a specific database.
I would say use symfony. It's a bigger framework might take a few days longer to learn but it will be well worth it. I was going to use CakePHP for a project that I am working on, after running to too many of those types of issues I switched to symfony and it's been smooth sailing.

One difference more is: Symfony separated to 3 environments: Development, Production and Testing - CakePHP can not!
It's easy to develop and test product at same time

Cake 2.0 nicely autoloads most of the classes you need, whereas I found in Symfony 2 that every class had to have numerous imports at the top of the script. Attempting to memorize all those imports is near-impossible, so you always need a reference handy.
eg. Symfony 2 controller code...
namespace Acme\HelloBundle\Controller;
use Symfony\Component\HttpFoundation\Response;
// bunch of other imports accumulate here...
class HelloController {
...
Argh, yuck. While that may be good OO technique for the purists, it lengthens development time (bye bye RAD). At least with Cake I can code most of the simple stuff quickly from memory now.

Related

Opinion - custom build website framework vs CakePHP

I have little by little built a website over the course of the past year and am now at a stage where the whole thing can go commercial, which means that I will face some tough questions regarding security, privacy, etc.
Since this is a situation where a hobby turned into a possible professional product, I am now rethinking how far I have to take this in order to really provide a product that is considered "safe" and stable.
The website was put together based on a Bootstrap 3 theme design, runs mostly on HTML, JavaScript, jQuery, PHP with Mysqli interactions and naturally has a SSL certificate. About a dozen plugins from various websites such as datatables, PHPmailer, jQuery-bootstrap-upload, blueimp gallery, etc. do the things I need them to do and I have always paid attention to properly mysqli_real_escape input values and write error handlers for all interactions. In short, there is no real framework here, things are more thrown together.
I am now being challenged that this is not considered a safe/stable solution and instead should recreate the whole website based on the CakePHP framework, which is something I am not familiar with and will take a fair amount of time to get used to and will definitely screw up my timeline.
So in short what I am asking is this: How important is it for a small and relatively simple website (i really dont do any complex code here...) to be built on a framework such as CakePHP in order to be perceived as safe and secure?
I understand there is no real answer to this, but I was just wondering whether building on an established framework like CakePHP is considered the only way to go or if a custom made framework is acceptable.
Thanks for the advice.
I was in your situation a couple years ago. I had started a site that, in the first year had about ~50 unique visitors. The second year I had about ~1500 unique visitors. What does this mean to a developer.
Optimize the response time - caching.
You need to optimize how you fetch data. Can you cache some queries? - CakePHP comes with caching Redis, Memcached etc.
Multiple Datasources - ElasticSearch, Mysql, Redis
Now that my website is huge, visitors might start to demand more functionality from the website. How do i deal with multiple datasources? CakePHP offers ways to interact with multiple datasources like ElasticSearch, Mysql, Redis
Code maintenance - Raw code vs a Framework
Do I need to google, and stackoverflow to reinvent the wheel? CakePHP comes with the best templating system and helpers.
Cutting down on development time.
If I am coding everything myself - I will spend more time developing. Using CakePHP I spend more time improving my website's data.
Decoupling
Does my data need to be managed by Cakephp, can I use Django, REST APIs etc. In the end I decoupled my website. I use Django to manage data entry, and CakePHP to present the data to visitors using Django REST framework.
No one can tell you definitely use CakePHP. However CakePHP3 , in my professional opinion, has a short learning curve. Using namespaces you can still use your current code in CakePHP and transition slowly into using CakePHP fully. CakePHP documentation is very good. You should be able to get a basic site wrkoing within an hour.

Easy to use/learn PHP framework? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I need to build a php app, and I was thinking about using a framework (never used one before). I've been browsing around some but most of them seems kinda complicated, I really liked what I saw about Symfony, but it looks like I will have to spend like a month until I really understand how to use it, and in one month I could code the app I have in mind 5 times without a framework. But I want to use one to "standardize" my code and prevent bugs.
So I was wondering if someone could share with me which php frameworks you think are easier to learn how to use.
My application will use mysql, and it will have some sort of "search engine" to search data that will be populated on the database using a few "scraper scripts" (that I also wants to code using the framework).
There are many questions answering this question here on StackOverflow and I was recently just in your position researching many different frameworks as I want to standardize my code as well.
I ended up choosing Codeigniter because I wanted something with good documentation, and that was very light (lighter == easier to understand IMO), and something that was not too strict. In Codeigniter if you really want to you can just code regular PHP and it lets you do that. I like this option because if I really get stuck on something, I just code it in raw PHP the way I know I can. I've only been using Codeigniter for a few weeks but the learning curve isn't too difficult and this is my first framework I've used.
Read through some of the previous discussions, and look out for ease of use advises:
https://stackoverflow.com/questions/2648/what-php-framework-would-you-choose-for-a-new-application-and-why
https://stackoverflow.com/questions/249984/php-framework-decision-analysis-paralysis
Why do I need to use a popular framework?
https://stackoverflow.com/questions/717836/kohana-or-codeigniter
If you want something easy to get started, you might want to look into the minimal frameworks:
https://stackoverflow.com/questions/694929/whats-your-no-framework-php-framework
https://stackoverflow.com/questions/141945/lightest-possible-php-mvc
https://stackoverflow.com/questions/3023818/any-procedural-non-oo-php-framework
But actually the big dozen are advisable if you want good documentation. Symfony and CakePHP are complex, CodeIgniter and the newer Kohana fork are beginner friendly. While there are many more to choose from. Pick a nice API, and maybe look out for one that explains the difference between MVC and MVP. Also for a lengthy list: http://matrix.include-once.org/framework/
My first choice would be cakePHP. Easy to learn, great documentation, api and a few good books:
Beginning CakePHP: From Novice to Professional – David Golding (good; start with this one!)
Super Awesome Advanced CakePHP Tips – Matt Curry (good and free :-))
Refactoring Legacy Applications Using CakePHP – Chris Hartjes (not read yet)
Practical CakePHP Projects – Kai Chan, John Omokore & Richard Miller (not so usefull)
CakePHP is the best solution with a small learning curve.
I was in your shoes just 2 years ago. I personally chose to use Zend Framework. It's important to understand that ZF is built by the same guys who maintain and improve PHP itself! Just that gives it a lot more credibility.
When choosing a framework you should consider the following:
Size and Quality of the community - Being one of the most widely adopted PHP frameworks, Zend Framework (aka ZF) has the biggest PHP framework community; hence, most of the problems you will encounter will have already been answered. There are frameworks out there that are supported by just a few developers and if they happen to quit working on it, you're stuck with the latest version of the framework. This not likely to happen with ZF.
Documentation and Beginner Friendly - The ZF docs are pretty good, full of examples and beginner friendly. There's also a ton of tutorials and [quick start guides][2]. It's extremely easy to start up a new ZF app.
Investment - Sure you have to invest sometime learning how it works, but everything's like that in the software engineering world. You have to understand [OOP][3] and [MVC][4] before hand as well. Many people don't understand that using a framework to develop procedural-like code (instead of OOP) is defeating the purpose of... using a MVC/OOP framework! Therefore, it's important to grasp and master these concepts so you develop the best code possible. And by best code I mean
a) code that works
b) code that's easy and fast to understand and maintain.
This investment is well worth it since it will drastically increase
a) speed of development
b) speed of debugging and maintenance.
Also, take advantage of this moment in your programming career to also adhere to other common best practices (if you haven't already done so) by using:
a) Unit Tests - incredibly easy to integrate within ZF. Look into [Test Driven Development][5] as well.
b) An IDE - VIM, [Netbeans][6], etc
c) [Design Patterns][7]
d) Source Control - [Mercurial][8], Git, SVN, etc
e) Finally, keep yourself in the loop by [following what's going on the PHP world][9].
You'll thank yourself yourself in your near future! I know I did.
As no-one has voted for Symfony here i will and here's why. There are two types of frameworks, well a whole range actually but in the PHP/MVC area which is where we are in this thread there are Glue and Full Stack frameworks.
Zend and CodeIgniter are Glue and Symfony and Cake are FullStack.
Glue are the ones where you can pick and choose which components you can use and how much "standard" code you can use. These tend to have a gentler learning curve as you can pick the bits you like that help and fill in the more difficult bits with code you know.
FullStack means you need to use the lot and so the learning curve can be quite steep. Also with FullStack there can be a tendency to balk against the way something is implemented rather than just accept and flow with it.
Coming from a write everything myself background i initially favoured the Glue's but have now migrated to FullStack using Symfony 1.4 and 2 and Sinatra and Padrino. The extra speed and power the fullstacks give is not something i would like to give up.
One downside of CI is that it is built for php4 compatibility and so does suffer in a number of structural ways when you come to push the framework, Kohana is a fork that addresses this issue. And i dislike Zend because there are so many ways of doing the same thing that after a while the Framework seems almost irrelevant (Sorry personal rant)
At the end of the day use of a Framework is good because it adds a structure and can be a great aid to learning and the one to choose is the one you feel comfortable and are productive in.
There are many frameworks and several really cool frameworks.
After trying so many of them I think you should not start using any of them before finding best suitable to your needs.
You may find any other after choosing one so do not act quickly before choosing right one.
Before creating an application with a framework you should make exercises.
For me I started with CodeIgniter created one application and left second one in the middle, then passed to Kohana and started second application according to the needs.
CodeIgniter is the one that I prefer
The framework must have little learning and easy to expand. I am using http://sourceforge.net/projects/naanalframework/ for all my projects. There is no installation. Just has to point the frameworks naanal.php in your application's index.php and run it. The framework will guide you what to do. For the beginer, this framework is very useful to develop PHP applications. A sample application also available at http://sourceforge.net/projects/naanalframework/files/sample%20applications/wordpress_plugin_builder.zip/download

Ways to get past the Inner-platform effect while still building highly customized web apps?

Feel free to answer the question in the title as generally as I posed it, I offer some more details and specifics below.
Currently I develop and maintain a somewhat legacy business app (ASP/SQL) that is highly customizable allowing for moderate to full customization on: custom fields, forms, views, reports, actions, events, workflows, etc. This customization is necessary in the domain we develop for and has allowed us to build a niche.
I have been reading up on the inner-platform effect and ways of implementing high level user defined customization and have concluded that we do suffer from many of the inner-platform effect problems because essentially we have created a high level abstraction on top of the SQL. The organization of custom fields is implemented in a similar way to the approach found here
http://blog.springsource.com/arjen/archives/2008/01/24/storing-custom-fields-in-the-database/
We use something similar to the meta database method described in that article. All customization is built around this approach and in many ways we suffer from database on top of a database.
The end result is something that looks fantastic on paper yet the more features are added and custom coding is done for clients the more of a mess everything becomes. It seems that the more I read the more I realize this is somewhat of an anti-pattern. It also seems that the more I try to read the more I find so little has been written on the topic. Anyways, I am trying to learn modern approaches to this problem and trying to find more discussion/articles on the topic. Are Database systems such as CouchDB relevant to this type of application?
My question is clearly pretty general. It seems like there is a lot against this kind of application in favor of just "knowing and defining your domain better". Are there any good/better ways to implement this kind of application? I'm not looking for black and white answers, and any further readings on the subject would be fantastic. Thanks for any help.
My answer is be conscious and clear about what is for a plugin to do and what is a user setting. In that case, your platform and your settings are different. Your application provides basic services and is unabashedly a platform. It may also provide an application built on that platform.
So in that case you focus on programmer interfaces instead of implementation possibilities.
The standard advice in CS is to create another level of abstraction, not sure if that's not the problem here.
The only advice I could give is to push as much functionality onto the database, given it's the platform. SQL Server supports custom functions, fields and stored (SQL) procedures.
Either that or try to pull repeated functionality into separate functions in ASP.

What new features and improvements does Lithium provide over CakePHP?

I've used CakePHP on several projects in the past, and have more recently started using Ruby on Rails, but there's a new project I'm about to start that will require PHP. While refreshing myself on CakePHP I learned that there is a new framework called Lithium that is essentially what CakePHP 3 was going to be. It's being developed by a group of former core CakePHP devs.
I haven't found a whole lot of information about it since it's still under development status, but I was wondering if anyone knows (or has a link to) some information on what benefits it provides over CakePHP. Hopefully something a bit beyond the quick overview shown on the official site. I'm trying to decide whether to use CakePHP for my upcoming PHP project or to wait a bit for Lithium to release a non-development version and try that out.
Hope this answer doesn't come too late, (and as the lead developer of Lithium, I'm a little biased :-)), but I will say that this is a hard thing to sum up. Lithium is the culmination of over 4 years' experience building and working with CakePHP, and while it retains many of the same designs and conventions, it was built to correct CakePHP's many architectural flaws.
In brief:
Framework features are grouped into loosely-coupled "packages" that are easy to use independently.
Tangentially, everything in Lithium is a "library", including your application, and Lithium itself. Support for integrating 3rd-party libraries is vastly improved, and all classes are namespaced, so you can finally have a model called File.
It is very easy to swap out core classes with your own custom implementations.
Lithium has a unique "filter" system that allows you to hook into many methods in the framework, which allows you to design your applications in an aspect-oriented fashion. These features work together to make Lithium the most flexible PHP framework, bar none.
Everything is lazy-loaded, and the architecture has been designed for maximum performance.
Lithium supports the latest tech, especially new databases like CouchDB and MongoDB.
I could go on for a while, but that's the gist of it. If you have any more questions, feel free to drop by #li3 on Freenode, and someone will happily give you a tour.
There is very little documentation so far. Here are some brand-new slides from gwoo though, that might be a good overview:
http://www.slideshare.net/gwoo/li3-ocphp
See the Lithium about page in their wiki. It lists all the features it will provide.
http://rad-dev.org/lithium/wiki/about

What is better CakePHP or pure PHP for a huge Project?

I just know pure PHP, never worked with a framework before, but my boss wants me to create our next project, which will be a lot bigger than everything we did before (means bigger than a page that needs only 5 scripts to work, more like 100 or something like that).
But I'm not sure if I can realise it with pure PHP, now I heard that CakePHP could be helpful for that (structure etc.).
Should I learn this or just use my pure PHP way?
As noted, your definition of the scope and complexity of this project is a little vague, but I'll respond with the general observation that larger projects benefit from more "top-down" structure than smaller ones. I suspect that pretty much every PHP developer on the planet started by hacking straight into index.php, then wrote some code for guestbook.php, and so on. Then you realise how much you're repeating yourself and start refactoring to classes and libraries.
Frameworks are the natural next step up from that. The term covers quite a range of products; some that tie you very closely to a specific way of working, and some that are more a library with some loose front control.
I'd advise you to choose a loose MVC framework, which gives you a good structure to work within, but doesn't overly constrain you, and should allow you to use existing libraries. I've not used CakePHP - my experience is with Zend Framework, which I like a lot (not that it's flawless). However, I have worked with another developer to compare the functionality of Cake and ZF, and from what I've seen Cake has many of the strong points that ZF displays. In fact, in many places it almost seems you could convert code from one to another by changing a few classnames.
I suspect Cake's not a bad choice at all, but I can't recommend it as I don't know enough about it. ZF I do know, pretty well now, so I can recommend it - and the docs are now pretty good.
Before you dive into either Cake or ZF, you'll need some understanding of the MVC design pattern. Jason Sweat's book is a good, if slightly dated introduction, and the ZF manual is also pretty strong.
By the way, it's not a choice between "Cake and Pure PHP". Cake (and ZF) are both "Pure PHP". The difference is between "PHP I wrote", and "PHP someone else wrote" (so I didn't have to). From this, the important bit is that you trust the quality of that "someone else's code", which in this case you'll have to do by recommendation and reputation.
But don't just go asking "What's the best PHP framework?" - that's like asking for the best text editor ;) And I'm sure this response (or question) will get tagged 'subjective' in mere moments.
I've been using Cake for a couple of years. I'd say if you haven't used any MVC framework before, you should definitely learn one to expand your horizon.
It's not really about using the framework for your convenience. It's about seeing how things are done in the framework-land. You'd really gain some insights that you can carry over even if you later decide not to use a framework.
Your description of the project didn't sound too huge. However, learning an MVC framework is some serious learning curve there. Basically you'll feel like you're learning a whole new programming language. So for your situation if you really do decide to try a framework, you might want to factor that in your schedule.
To get you started, I personally think CakePHP has a more elegant solution and has tighter design philosophies. CodeIgniter, on the other hand, seems more natural to "pure PHP-ist" because it's less abstract so it might be easier to pick up.
To answer the titled question though, I'd think any huge project should roll their own from the start instead of using a framework. The whole point of using a framework is because you want to leverage some of the stuffs they have built in for you. But for really huge projects, many of the parts should be customized anyway, so you might found yourself restricted by the framework more than leveraging it.
But then again, I really don't think your project (by your description) is anything near huge. As a ballpark estimate I'd say any project under 50k - 100k hits a day can safely benefit from using a framework.
I do not say CakePHP. But any framework will do. The major benifit will be you will get a default folder structure, skin, language framework (oscommerce etc. do). You will be customizing this framework. Most features will/may there be by default, like email sending, page creation, Menu generation etc.
You did not say what kind of application you plan (may be because of NDA). More details, more accurate answers.
I agree that it shouldn't be a decision whether to use CakePHP, but whether to use a framework at all. There are a multitude of PHP frameworks out there (Cake, Symfony, Codeigniter, Zend, etc.) and each has it's advantages and disadvantages.
If it was me, I'd use a framework just to strictly enforce some MVC rules... with a large project, keeping things structured helps down the road when someone else inherits the system.
The key here, is don't get lulled in by the "code generation" aspects. If you don't know the framework (or don't know the language as well as you could) down the road, the code generation could be more of a headache than it's worth.
Using a PHP framework like cakephp will reduce the amount of code you need to write. In cakephp there are many things that will save time like using elements to display snippets of code that you use often. If the project is really big, it will help tremendously because your code will be shorter and much more clean and organized. It will be much more easy to maintain as well.
I think that pure php would be the best option because if you use a framework you are restricted to their boundaries,
whereas without framework you are free to design anything, if you think that you have the best capability of solving problems and making algorithms then you must go with php not any kind of framework
and if you just want work to be done then you must go with framework i haven't worked on framework by have some knowledge of cake php i didn't liked it as i think i am tied with some rules, i prefer writing my own code and in case you want to do less work in future just write you own rules (its like making your own framework) just save every thing you created in small files and then use them in you other project just like one of the benefit of OOP(Object Oriented Programing)
If you know PHP, you'll learn more about how to implement common design patters if you start reading other peoples code. The more you read, the more you'll get perspective on what good code looks like, and what bad code looks like.
It is tempting to "code-your-own" because you will understand it more fully, but remember, you're not going to be the only one working on this, and one day, you might actually want to work on something else, and having a system which is widely implemented and understood can make it easier to move on.
As far as whether cakePHP a good choice for your particular project, it's hard to say without knowing more than it's going to be "bigger".
Everything depends on the project and the project stake holder. If there is going to be a lot of modification, either during development or after the project goes live, a framework can be pretty limiting to someone without a strong grasp of the theories behind the framework (not a judgement on the programmer, just a statement.)

Resources