jschreuder

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.

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.

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.

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.