If you want any new framework in PHP to be taken seriously I would start with a) a new concept instead of just another Rails-clone, and b) adhering to common standards and practices (tests, namespaces, PSR, Composer, etc).<p>Or in other words, neither reinvent the wheel nor ignore its existence.<p>Alternatively, since innovation isn't generally rooted in conformity, have some kind of reason to ignore all of the above.
Instead of focusing on making a PHP framework that's like Rails, you should focus on "how can I boost developers' productivity in a unique way?" This is how libraries and frameworks become popular. If you try to model your software after existing software, it'll only ever be second-best, at best.<p>Rails became popular despite few people knowing Ruby because it took full advantage of the language's expressiveness and ergonomics and had innovative abstractions.<p>Today we're slowly shifting towards things like Meteor, which combine back-end and front-end development and make it super simple to write dynamic single page web-apps.<p>The primary issue with your framework is that the PHP ecosystem is already saturated with traditional MVC frameworks. Most experienced web developers who care about their craft have been shunning PHP for a while now [1], and those who do use PHP will probably stick with a more stable, documented and in-demand framework like CakePHP.<p>The pragmatic thing to do would be to contribute to your favorite framework instead of making a new one, unless you can start something that boosts productivity in a unique way. Contributing doesn't have the same glamour as leading your own thing, but remember that this is open source -- we're all on the same side.<p>[1] <a href="http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/" rel="nofollow">http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...</a>
Thanks for all the comments so far. It's true, this project is not currently under active development. I would love to put more work into this project to make it into something that serves an unmet need out there. What's missing from the frameworks that currently exist?
This is a work in progress that I think could turn into a better CakePHP, but also has the potential to become something more similar to Sinatra and have the relationship to CakePHP that Sinatra has to Rails. Would love to get feedback on these two routes of development.
Just so if any one is interested, yet another php framework: <a href="https://github.com/oguzbilgic/hivli" rel="nofollow">https://github.com/oguzbilgic/hivli</a>
Good luck with this.<p>I started my own php framework as an experiment (no public repo yet.) I'll have to try this out and see how it works.<p>Apart from being 'rails inspired' what problems specifically are you trying to solve with this?
It's a good idea to use example.com domain in example URLs instead of mysite.com or other "real" domains.<p>EDIT: Other tip for the readme: change the name to README.md and Github will render your Markdown formatted readme properly.
It's great if you are making it for the sake of studying.<p>Designing a framework AND building an application using it will teach you many valuable lessons and surely will make you a better developer.<p>Have fun.
I pretty well matured PHP5 based "Rails-inspired" framework is SilverStripe.<p><a href="http://www.silverstripe.org/framework-introduction/" rel="nofollow">http://www.silverstripe.org/framework-introduction/</a>
Out of curiosity, but is there a design-reason why the controller names are tied (by naming convention) to HTTP convention?<p>i.e.<p><pre><code> public static function show_GET($params=null) {
self::render('show',array("layout" => "default"));
}
public static function index_POST($params=null) {
self::redirect('/auction/show');
}
</code></pre>
As opposed to how Rails does it (controllers are defined in their own file and associated with a HTTP protocol in a routing file):
<a href="http://guides.rubyonrails.org/routing.html" rel="nofollow">http://guides.rubyonrails.org/routing.html</a><p>in routes file:<p><pre><code> get 'photos/show'
</code></pre>
in controller: photos_controller.rb<p><pre><code> class PhotosController < ApplicationController
def show
# render stuff
end
end
</code></pre>
Seems like it's an unnecessary coupling (also, I think in Rails, you don't have to define protocol unless you feel it's explicitly needed), but my main nitpick was seeing a naming convention that featured the kind of letter-case-changing that has made PHP a difficult language to enjoy