Show HN: Rails-Inspired PHP Framework
github.com
github.com
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
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');
Where are the tests? Composer?
Next.
It seems to be a rudimentary implementing of the MVC pattern, which is interesting to say the least.
There are many different PHP frameworks already, what makes this one special?
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
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).
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...
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.
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.htmlin 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