I get your point but there is one problem with that approach that has lead me to advise some clients to use such a filter. People like most of us reading here know quite well the evils and shortcommings of IE6, but by far the most people still using IE6 don't. I know it is hard to imagine for anyone here but I have friends whom I had to explain that some non-functional website was due to their prehistoric browser. Telling the public their browser is way too old is far better than presenting them a partially functional non-marked up website. It may annoy you and me, but we're not the public most webdesigners should care about.
Now to our own site disallowing IE7 while being targetted at web professionals. Pretty much no-one doing serious web development will be limited to IE6/7 - let alone use it as their primary browser. If you do and your employer is short-sighted enough to keep at IE6, you'll be part of a very very tiny minority which will most likely still not have access to PHP5.3 either.
I would like to clarify something: We're not exactly (or pretty much exactly) like anything. Some small parts may have been taken from other frameworks but the whole application flow (Request, Response), autoloader and most of the classes were written from scratch. Being (partially) responsible for classes like Validation, Form, Cache, ViewModel and packages Auth & Orm I can be very clear that while inspiration may have been drawn from many sources they were build specificly & uniquely for Fuel without being ported/rewritten/copied from anything.
We do use slightly modified versions of Kohana's querybuilder & View classes (something we're very upfront about, and from Ko3 btw not Ko2.3) but the framework by and large was build by us originally. And if parts were taken from other frameworks it is mentioned explicitly in the code, but those are the exceptions rather than the rule.
Apologies if I am misrepresenting the project (as I said, I know very little about Fuel, just discovered it via this thread) -- didn't mean to put you on the defensive.
I didn't look at the underlying code at all, just browsed through the docs and to my eyes the "API" or "structure" of Fuel looked very similar to Kohana, which is a HUGE compliment coming from me, as Kohana is (was?!) my favorite PHP framework. Definitely not accusing anyone of stealing code -- just trying to answer the guy's question. I don't think anyone could argue that if you compare Fuel to Kohana and Symfony [as was the question], Fuel is WAY closer to the Kohana end of the spectrum.
Anyways, I'm really looking forward to trying this out on my next non-CMS project -- thank you for creating this.
I think you got him wrong. We've been at this for some time now and did some heavy development on this. Sometimes a person comes in and comments with a single line like "I WANT MORE NAMESPACES" and seems to assume that we picked our current setup without giving it a second thought. When someone comes around and all they can say is something as unmotivated and useless as that we won't have a lot of time for the assumption we didn't think of it.
If you completely disagree that's fine, move on to something else then - no hard feelings either way I hope. Just don't assume we just created this at random. Dan's remark was spot on, we chose the way we handle namespaces and autoloading very deliberately and we'll take the time to explain our motivations if you ask. But if you come in telling us that our setup sucks because we should be all-something because product X has that as well: don't expect we'll spend any time on you. There are lots of others with a more open-minded approach whom our time is far better spent on, and of course especially those actively helping out being the community you refer to.
Actually we have something along those lines: using our command line utility you can install "packages" which should be a collection of classes for added functionality. Currently we have some well known libraries already available through the CLI by using "php oil install package htmlpurifier" for example, they're taken from Github and installed in the fuel/packages/<packagename> dir.
Of course if you don't want CLI you can just download them and copy them to the right directory yourself.
We intend to create a repository for packages and classes installable through Oil directly into your Fuel install.
At this time we are still using a single Github profile to fork any repo into that will be available through Oil package install: https://github.com/fuel-packages (install the packages without the "fuel-" prefix as their name)
PEAR and PECL are great, but they add requirements to your application that live outside of the system.
You have to worry about your application being compatible with the version installed on the server and all sorts of other madness. Through this incredibly simple system (which will shortly become more powerful with its own interface) we can basically just install a package into your application in the same way most people would normally download, unzip, etc.
php oil install foo
Then add it to git, push and you're all good. Otherwise you have to run around installing dependencies and all sorts of other junk.
We actually keep pretty close to that, but have two implementational differences:
1. Namespaces are linked to a specific directory instead of just translated to a path
2. Our paths are fully lowercase
And I stand by those. The first allows for more flexibility when it comes to code organization and the second makes mistakes in classloading a lot less common. You can disagree with these but we have documented them clearly. Also it's quite easy to add another autoloader, ours won't even do a filesystem check when trying to load from an unknown namespace so it should add hardly any overhead to attach a Zend (or anything) compatible loader.
Sorry Phil, going to correct you a little bit here ;-) It actually wasn't ported over. It was written by Alfie and I did a big rewrite on it before committing.
Right you are, but Alfie based this almost directly on CI. You recoded some of it, but the initial purpose and feeling of the class remains as essentially a copy of the CodeIniter Helpers. The sort of thing that is so similar it was just easier to call a port. :)
There will be a Parser lib in v1.1 which will allow you to plugin pretty much any templating engine.
Also you won't need to "hack" anything to use Twig with Fuel, the Views aren't loaded when not used. Just use Twig to create your HTML output.
The most direct comparisson is CI:
CodeIgniter was a great framework for PHP4 but it is still very much based in PHP4. They may have started to move towards PHP5 with CI2, but they didn't rewrite it with PHP5 in mind. As such the whole architecture is still dictated by PHP4. Also CodeIgniter doesn't have classes autoloading, HMVC, modular seperation, build in ORM, migrations and a lot of other things we felt were very much missing.
The comparisson to Cake & Zend is a bit apples and oranges. Both are hugemongous frameworks in comparisson, especially Cake has a pretty big footprint. Zend is even a whole other approach in the sense that it is more like a collection of loosly coupled classes, while Fuel is a more intergrated framework. I know for example that some have already been using Zend classes with Fuel, combining the large offerings of Zend with the development base we offer.
Now to our own site disallowing IE7 while being targetted at web professionals. Pretty much no-one doing serious web development will be limited to IE6/7 - let alone use it as their primary browser. If you do and your employer is short-sighted enough to keep at IE6, you'll be part of a very very tiny minority which will most likely still not have access to PHP5.3 either.