PHP Fat Free Framework aka F3(fatfree.sourceforge.net)
fatfree.sourceforge.net
PHP Fat Free Framework aka F3
http://fatfree.sourceforge.net/
7 comments
Also, PHP really needs something like Plack/PSGI/Rack so that you don't have to manually reconfigure the web server for every library you want to use.
The Apache configuration mentioned in this article is pretty generic.
PHP has a standard HTTP interface, unlike the other languages before WSGI/Rack/JSGI/PSGI came around. Of course, PHP's interface isn't function-based, so you don't have the advantages of stackable middleware.
A spec closer to the *SGI's would indeed be nice.
The Apache configuration mentioned in this article is pretty generic.
PHP has a standard HTTP interface, unlike the other languages before WSGI/Rack/JSGI/PSGI came around. Of course, PHP's interface isn't function-based, so you don't have the advantages of stackable middleware.
A spec closer to the *SGI's would indeed be nice.
Actually, it's funny you should mention that. I wrote a little web server in PHP that's basically a port of Ruby's Rack:
http://github.com/dhotson/kelpie
It actually works pretty well, no apache required! It's pretty fast too.. all the init stuff you normally have to do every single request can be done once on server startup.
I also wrote a little sinatra style framework to go on top of it: http://github.com/dhotson/kelpie/blob/master/demoapp.php
Anyway, it's turning out to be a pretty fun little project. :-)
http://github.com/dhotson/kelpie
It actually works pretty well, no apache required! It's pretty fast too.. all the init stuff you normally have to do every single request can be done once on server startup.
I also wrote a little sinatra style framework to go on top of it: http://github.com/dhotson/kelpie/blob/master/demoapp.php
Anyway, it's turning out to be a pretty fun little project. :-)
That's quite cool. That's some of the cleanest PHP I've seen.
When I've tried to write long-running applications in PHP I always get memory leaks. How do you handle this in Kelpie?
When I've tried to write long-running applications in PHP I always get memory leaks. How do you handle this in Kelpie?
Thanks Josh! :-D
Yeah, it's probably going to have memory leak issues. It's pretty much inevitable unfortunately. I've thought about having the server monitor the memory usage and periodically respawn processes. I believe apache uses a similar technique.
I'm open to ideas on this issue though. :-)
Yeah, it's probably going to have memory leak issues. It's pretty much inevitable unfortunately. I've thought about having the server monitor the memory usage and periodically respawn processes. I believe apache uses a similar technique.
I'm open to ideas on this issue though. :-)
Cool, I might write up a little library to provide the same interface to standard PHP CGI/Apache.
This is what I've got so far:
http://gist.github.com/339915
It basically sets all the usual superglobals like $_SERVER, $_GET etc. Doesn't handle sessions just yet; I'm still working on that..
It basically sets all the usual superglobals like $_SERVER, $_GET etc. Doesn't handle sessions just yet; I'm still working on that..
Agreed. It works ok with Readability http://lab.arc90.com/experiments/readability/
Did they fix this? I see white on dark grey.
I've done something similar, inspired by sinatra: http://github.com/soska/microbus but I'm a poor self-promoter.
This is an interesting idea, but I like better my syntax though. But again, I'm not even a real programmer.
This is an interesting idea, but I like better my syntax though. But again, I'm not even a real programmer.
I'm a poor self-promoter.
<snip>
But again, I'm not even a real programmer.
I don't actually think it is better, just different and works for me. Some other attempts try to make PHP act like ruby or python with ugly results. What I've tried to do here is embrace PHP 'classic' style.
if (get('hello')){
// do stuff
}This is exactly what I intended for my "personal framework" when I began writing it's first version about three years ago: unintrusive (all main functions as static methods of a single class to keep the global namespace clean; no enforced directory structure) and lightweight (few files, few bytes).
Too bad mine grew to become a monster, pretty much like all other popular PHP frameworks out there. I guess simplicity really is one of the hardest features to implement.
Too bad mine grew to become a monster, pretty much like all other popular PHP frameworks out there. I guess simplicity really is one of the hardest features to implement.
the license gpl v3 for base framework is pretty limiting ... it could be a show stopper... something like MIT or BSD would encourage people to try out...
Really? I honestly didn't think it was a problem for web apps. What's the issue here?
gpl v3 requires code (even hosted) to be shared upon request by users
with gpl v2, it was a requirement. hence gpl v2 licensed applications such as wordpress and drupal don't need to be shared with site users
code built upon the framework is derivation and thus, has to be licensed accordingly
with gpl v2, it was a requirement. hence gpl v2 licensed applications such as wordpress and drupal don't need to be shared with site users
code built upon the framework is derivation and thus, has to be licensed accordingly
I can't see the requirement to share code with users on request anywhere in the GPLv3. It explicitly excludes interaction over a network in section 0:
"To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying."
it's not an issue, it's in the site:
"Any of the license terms and conditions can be waived if you get permission from the copyright holder."
"Any of the license terms and conditions can be waived if you get permission from the copyright holder."
Another framework based on MVC.
But MVC is just not possible in PHP. Maybe with Ajax it is, but mostly it is a hype people don't understand.
Let Apache (or any webserver) be the controller and you have the most lightweight framework there is.
In what way is it not possible? You can send all requests through a single handler with .htaccess can't you?
You can, but it will not update the view directly as MVC does. You always need to refresh the page for that.
In Java or Flex (or with Ajax) the view is updated by the model. That is MVC. In PHP this is just not possible. So imho it is a hype word people don't understand.
Most (PHP) frameworks that use 'MVC' are just more bloated than Apache + PHP (a single handler with .htaccess could be nice!).
MVC ≠ What your pet framework does
MVC is a descriptive point of view, not a prescriptive implementation plan. It's one of the only software idioms that's actually an Alexanderian Pattern, unlike the vast majority of the GoF that's just reflective of language warts/features.
There are tons of completely different ways you could describe the web as MVC:
MVC is a descriptive point of view, not a prescriptive implementation plan. It's one of the only software idioms that's actually an Alexanderian Pattern, unlike the vast majority of the GoF that's just reflective of language warts/features.
There are tons of completely different ways you could describe the web as MVC:
Model View Controller
URL Response Request
DB Response Request
Response Hypermedia Sub-Requests
LocalStorage DOM Javascript
data:// JavaScript DOM Events
...I agree. But that's not the case with this PHP framework (as far as I can tell). They use 'MVC' as structure for there code (or as you call it: prescriptive). And then suddenly a lightweight framework is not that lightweight anymore. So again I agree with your descriptions of the web as MVC, but MVC in a PHP framework only... I still believe that's just a hype word.
BTW I don't want to start a flame war about MVC. I just got some question marks about using a PHP 'MVC' framework.
BTW I don't want to start a flame war about MVC. I just got some question marks about using a PHP 'MVC' framework.
Am I right in saying you think it's bloated because it's superfluous? If that is the case, may I draw your attention to one of the most important reasons for doing request handling within PHP: testability.
Were it not for that I would be in complete agreement with you; I have absolutely no time for any framework that does not allow you to construct a mock request object, throw it into the controller, and verify correctness of the response object produced.
Were it not for that I would be in complete agreement with you; I have absolutely no time for any framework that does not allow you to construct a mock request object, throw it into the controller, and verify correctness of the response object produced.
I think that the confusion comes from the fact that the original MVC was a prescriptive design pattern, but use of the term has expanded way, way beyond its original intent.
For instance, events between M and V are pretty much required if you're doing it the "old way," but people tend to ignore that and just explicitly route messages through the C. The expression carries a lot less meaning now than it used to.
For instance, events between M and V are pretty much required if you're doing it the "old way," but people tend to ignore that and just explicitly route messages through the C. The expression carries a lot less meaning now than it used to.
Allow him to justify himself before you down-vote him for saying something interesting.
Reading through the 'Getting started', it's quite an interesting approach actually. I might give it a go some time.
What's interesting about it?
It looks like Sinatra for PHP.
Also, PHP really needs something like Plack/PSGI/Rack so that you don't have to manually reconfigure the web server for every library you want to use.