Your point is accurate but your tone is deplorable. To you this is just another post about just another Github report, but to the author this is something they spent several months on.[0]
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.
I am from time to time involved in the development of the CakePHP framework, at least often enough to have strong opinions on specific weak parts of the framework. I think your project might have potential, but the lack of tests and composer support is a serious flaw.
Your priorities should be tests, and documentation, before anything else.
I think that your efforts might be better spent on improving CakePHP; the developers have no particular concern for backwards compatibility in the upcoming major version (3.0). I would be interested to discuss all of your ideas related to this, please contact me at tenebrousedge @ gmail
you should probably get rid of the evals as soon as possible. there are other ways to test for a class and method (is_readable(), class_exists(), method_exists() or the reflection api which I don't remember the syntax of offhand)
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?
Out of curiosity, but is there a design-reason why the controller names are tied (by naming convention) to HTTP convention?
i.e.
public static function show_GET($params=null) {
self::render('show',array("layout" => "default"));
}
public static function index_POST($params=null) {
self::redirect('/auction/show');
}
As opposed to how Rails does it (controllers are defined in their own file and associated with a HTTP protocol in a routing file):
http://guides.rubyonrails.org/routing.html
in routes file:
get 'photos/show'
in controller: photos_controller.rb
class PhotosController < ApplicationController
def show
# render stuff
end
end
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
Ah good to know. Wasn't being completely snarky...I'm interested in how the difference between Ruby/PHP imposes different constraints/style in how opinionated the framework can be. Good luck!
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.
Rails became popular despite few people knowing Ruby because it took full advantage of the language's expressiveness and ergonomics and had innovative abstractions.
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.
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.
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.
People keep bringing Cake up as some sort of state of the art PHP framework - it's not. It's right there next to CodeIgniter and Symfony1: best left to rot and not used for any new projects.
Look to Zend Framework 2, Symfony2, Silex, hell even Laravel 4 for quality products.
* One of the biggest contributors to the community edition left and wrote a nice blog post about it [0]
* CodeIgniter uses some very untestable patterns [1]
* The way it allows loading classes is horrible [2]
* It feels like a first-generation PHP framework because it is a first-generation PHP framework
* It tries to do almost everything. A framework should have the bare minimum, and use outside libraries or libraries that were developed without the framework in mind.
Well since I am technically running my site with it (which i'm also not posting since it's just some bootstrap pages right now) I should probably get around to it sooner or later...
I guess people will need another excuse to post Veekun's manifesto.
It's not 'rails inspired' though since I don't know Ruby/Rails.
Everyone should write their own framework, no one should release it.
The reason is that by rolling your own framework, you learn the ins and outs of a number of things. It's even better if it's a framework you've derived from a functional app.
I've rolled a number of my own frameworks including one for mobile (WAP) and the one underlying my open source project. The first was never shared publicly, the second is still the core of the app.
That said, the question I have for (both of) you is: What?
- What makes your framework better than X?
- What were your priorities in the architecture? What did you de-prioritize?
- What features did you consider absolutely mandatory? What did you decide to leave out?
probably nothing. Ill be adding links to the frameworks you'd probably rather be using in the readme anyway. it's entirely meant to scratch my personal itch.
What were your priorities in the architecture? What did you de-prioritize?
Easy static page generation and header control, and reasonable security out of the box. I like to think of it as a static site framework since its primary purpose is doing the MVC process but resulting in static pages. I don't know how well it does this to scale with complex taxonomies yet but it'll run Bootstrap.
I de-prioritized elegance and abstraction to a degree. If anyone ever sees it, they'll probably think it's kind of ugly.
What features did you consider absolutely mandatory? What did you decide to leave out?
Twig as the template engine and htmlpurifier. Every view is run through twig, then markdown (so even though the views are twig files they can be entirely markdown and still work fine), then htmlpurifier with a whitelist before being either saved statically or sent. So certain things like adding forms to a page and script tags and such are made purposely more difficult because htmlpurfier will just strip them out.
I left out complex asset handling (you specify .js and .css dependencies in the routes if you want them.. which is probably breaking best practice but oh my god is it convenient) and routes in closures because at the time I wanted to tie every route to a controller and method. There are no html helper classes because I wanted nothing but data going into the templates, so nothing that generates html. A lot of things are 'left out' just because I haven't gotten to them yet.
What made you take the approach you did?
I couldn't stop messing around with Laravel and I realized I didn't really understand what was going on like I wanted to. I just wanted a lightweight framework that would generate a site statically and not load a bunch of libraries and whatnot if they weren't needed. Because I'm on a cheap shared server and there don't seem to be a lot of solutions that don't assume I'd be running on Heroku with unlimited bandwidth or something.
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).
Or in other words, neither reinvent the wheel nor ignore its existence.
Alternatively, since innovation isn't generally rooted in conformity, have some kind of reason to ignore all of the above.
Plus, please use docblocks and document methods and classes.
Given there are some good PHP framework out there already, I would focus on something really new, something missing on the market. Personally, I'm putting down some concepts of a light PHP framework for Mongrel 2
45 comments
[ 3.3 ms ] story [ 65.9 ms ] threadThere are many different PHP frameworks already, what makes this one special?
https://github.com/fuel/fuel/commits/1.5/master
Although this is the 1.5 branch, the other branches are also similarly inactive (it appears to have ended about a month ago).
Where are the tests? Composer?
Next.
It seems to be a rudimentary implementing of the MVC pattern, which is interesting to say the least.
[0] https://github.com/mgauthier/php_diamond/contributors
Your priorities should be tests, and documentation, before anything else.
I think that your efforts might be better spent on improving CakePHP; the developers have no particular concern for backwards compatibility in the upcoming major version (3.0). I would be interested to discuss all of your ideas related to this, please contact me at tenebrousedge @ gmail
i.e.
As opposed to how Rails does it (controllers are defined in their own file and associated with a HTTP protocol in a routing file): http://guides.rubyonrails.org/routing.htmlin routes file:
in controller: photos_controller.rb 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 enjoyhttp://www.silverstripe.org/framework-introduction/
Rails became popular despite few people knowing Ruby because it took full advantage of the language's expressiveness and ergonomics and had innovative abstractions.
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.
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.
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.
[1] http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de...
Look to Zend Framework 2, Symfony2, Silex, hell even Laravel 4 for quality products.
* One of the biggest contributors to the community edition left and wrote a nice blog post about it [0]
* CodeIgniter uses some very untestable patterns [1]
* The way it allows loading classes is horrible [2]
* It feels like a first-generation PHP framework because it is a first-generation PHP framework
* It tries to do almost everything. A framework should have the bare minimum, and use outside libraries or libraries that were developed without the framework in mind.
[0] http://philsturgeon.co.uk/blog/2012/12/5-things-codeigniter-...
[1] $ci =& get_instance()
[2] $this->load->library('typography');
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.
Apart from being 'rails inspired' what problems specifically are you trying to solve with this?
Looking forward to seeing your public repo, apparently you can get a great discussion going on HN by putting it out there :)
I guess people will need another excuse to post Veekun's manifesto.
It's not 'rails inspired' though since I don't know Ruby/Rails.
Everyone should write their own framework, no one should release it.
The reason is that by rolling your own framework, you learn the ins and outs of a number of things. It's even better if it's a framework you've derived from a functional app.
I've rolled a number of my own frameworks including one for mobile (WAP) and the one underlying my open source project. The first was never shared publicly, the second is still the core of the app.
That said, the question I have for (both of) you is: What?
- What makes your framework better than X?
- What were your priorities in the architecture? What did you de-prioritize?
- What features did you consider absolutely mandatory? What did you decide to leave out?
- What made you take the approach you did?
probably nothing. Ill be adding links to the frameworks you'd probably rather be using in the readme anyway. it's entirely meant to scratch my personal itch.
What were your priorities in the architecture? What did you de-prioritize?
Easy static page generation and header control, and reasonable security out of the box. I like to think of it as a static site framework since its primary purpose is doing the MVC process but resulting in static pages. I don't know how well it does this to scale with complex taxonomies yet but it'll run Bootstrap.
I de-prioritized elegance and abstraction to a degree. If anyone ever sees it, they'll probably think it's kind of ugly.
What features did you consider absolutely mandatory? What did you decide to leave out? Twig as the template engine and htmlpurifier. Every view is run through twig, then markdown (so even though the views are twig files they can be entirely markdown and still work fine), then htmlpurifier with a whitelist before being either saved statically or sent. So certain things like adding forms to a page and script tags and such are made purposely more difficult because htmlpurfier will just strip them out.
I left out complex asset handling (you specify .js and .css dependencies in the routes if you want them.. which is probably breaking best practice but oh my god is it convenient) and routes in closures because at the time I wanted to tie every route to a controller and method. There are no html helper classes because I wanted nothing but data going into the templates, so nothing that generates html. A lot of things are 'left out' just because I haven't gotten to them yet.
What made you take the approach you did? I couldn't stop messing around with Laravel and I realized I didn't really understand what was going on like I wanted to. I just wanted a lightweight framework that would generate a site statically and not load a bunch of libraries and whatnot if they weren't needed. Because I'm on a cheap shared server and there don't seem to be a lot of solutions that don't assume I'd be running on Heroku with unlimited bandwidth or something.
EDIT: Other tip for the readme: change the name to README.md and Github will render your Markdown formatted readme properly.
It actually looks like a blend of asciidoc and... something...
Or in other words, neither reinvent the wheel nor ignore its existence.
Alternatively, since innovation isn't generally rooted in conformity, have some kind of reason to ignore all of the above.
Plus, please use docblocks and document methods and classes.
Given there are some good PHP framework out there already, I would focus on something really new, something missing on the market. Personally, I'm putting down some concepts of a light PHP framework for Mongrel 2
Designing a framework AND building an application using it will teach you many valuable lessons and surely will make you a better developer.
Have fun.