FuelPHP Forums

Harro, Thanks for taking the time to respond to both of my posts. I appreciate it and will try to kill two birds with one stone. But you're correct. Less core features "most of the time" means, tighter, faster and more modular "core." Now, the big challenge the FuelPHP development teams will be the following: 1. The more popular Fuel becomes, the more contributors and the more difficult it is to manage the project. People will be slapping code together that doesn't comply with your existing conventions. Fuel will be more pressured to get fixes and new releases out. Many of these third party fixes will make it into the core. That's just how it goes. I'm sure you know that. 2. You mentioned that you're not funded by any larger conglomerates and don't have a hidden agenda. However, we're all vulnerable when it comes to receiving more and more of the spotlight. Before you know it, as time goes by - FuelPHP still exists but all of the original members are gone. I've had the misfortune of engaging in a lot of Joomla development over the past year. Don't get me wrong. Joomla certainly has it's place. Easy to get customers up and running and most of my time was spend just configuring a brandable back end and plugin development. However, for my own personal endeavors, Joomla just wouldn't work. They might have started as an MVC framework but now, if you take a look under the hood, you have a million different coding styles for each extension. Core hacks, waiting for third party component updates. Try running Joomla in E_ALL or Strict mode. Forget about it. The worst thing, Joomla has become bloatware and eats up overhead like you can't even imagine. Anyway...... That is the reason why I decided to look elsewhere. My search started with other CMS. frameworks I can't even begin to tell you how much time I researched. Well, there was only one CMS that I would recommend at the lower level. I realize there is no such thing as a "one size" fits all. You said it quite well in your other post. It basically decides on the task at hand, time = money and the person's level of experience, etc..... Yii was very appealing to me at first. Then, I started to dig into the documentation and code. As I mentioned before, the existing frameworks not built exclusively for PHP 5.3, are making quick, bloated, ambiguous modifications just to make it look as if they support namespacing and closure. I don't think I've every seen array based parameters as deep and nested. I am talking MASSIVE multi-dimensional associative arrays. You'd need to run a recursive flatten on them just to figure out what goes where.

Matt, I understand where you're coming from, and I know the dangers that lurk around the corner. However, being a developer with 30 years experience under the belt, and having lead numerous large projects, I'm quite confident that we can handle this. For 1.x we've already been quite strict when it comes to contributions that we feel should not be part of the framework (core), or to reject code that doesn't adherence to our coding conventions. Some sneaked in (like pagination), and we've been lax when it comes to unit tests. For 2.0, we've raised the bar even higher. NOTHING will go into the core unless fully documented and unit tetsted. No exceptions, not even from core developers. It will be my job as project lead to give them a slappin' when they don't obey the rules! I've been active in several open source projects (and still am in some), and what you see with a lot of them is that people work on it for personal reasons. That others are using the project, fine, but users are considered a nuisance they can do without. You can identify these projects because they lack project ownership, and they often don't have a project lead that properly manages the project. People ask questions that don't get answered, and they have a long open issue list that doesn't get resolved. It's total anarchy, projects like this will eventually be abandoned by the developers, or by the users due to the erratic and inconsistent behaviour of the development team, and the similarly inconsistent product they produce. We try to do it differently, and approach the development of the framework as any other (professional run) project. We have a project lead that is in charge (what he says goes, he is the only one that does releases), we have a software architect who's job it is to define the roadmap and the framework's architecture, and to keep a very close eye on what was been developed. It's quite normal in any project that people come and go, but as long as you keep this structure in place, you can deal with that. Obviously things can be improved. Because we all have to work for a living, sometimes we can't spend as much time on the framework as we would like. A few more developers would be nice, as would be someone who can be in charge of documentation (and chase everyone to produce it), the forum and the new community website. I don't have a crystal ball, so I can't predict the future. But as far as I'm concerned, FuelPHP is here to stay!

My background isn't even in PHP or LAMP based technologies. I come from a ASP/.NET/SQL server background. I was working for a company in Silicon Valley back in 2007 and gave them my notice because I just couldn't handle working with SQL server anymore. I'm not sure how .NET is these days but back then, to accomplish "simple" tasks required writing "several" lines of code. Okay, it's a compiled "sort of" web framework. I hear that it has an MVC and ORM methodology at present. Still doesn't make me want to go back to it. I will say this much. PHP still has a "long" way to go to be recognized as a true OOP or scripting language. The language has made a lot of progress over the last couple of years but I don't like how they have implemented the entire "magic" getters and setter methods. I still don't even fully understand why and how it works. I hear a lot of talk in regards to the performance hit calling these "magic" methods. That's where .NET or any other native OOP language has the advantage. They should have put a little more thought into the architecture and implemented generic/abstract get() and set() methods that worked with the properties of every object that extended the ultimate "parent" object. It was so much easier and straight forward in .NET. Before the "magic" stuff, it was even worse. Naming a getter and setter for every single distinct property? Makes absolutely no sense to me. Oh well. I'm babbling now.

Open source doesn't work without contributions. That is how the mechanism works. You use something, and if you like it, you use it more. You miss something, so you add it. You contribute it, so the project gets better. Which means more people might start using it. Who might also contribute. Which might be of benefit for you. This is not necessarily about core contributions, it could easily be a package that provides new functionality. Quite a few have been created and published, and some (like Sentry for authentication, Ninjauth for OAuth based authentication, etc) are very popular. And remember, core developers don't get a "dime" either, for us it's a double edged sword as well. We need to invest time and effort in the framework, but in the end we get a better framework in return, as more and more people start using it, test it, find bugs, come with suggestions or feature requests, contribute code, etc. In the end, in most applications a lot of code is boilerplate of some sort, and the goal of the framework is to take care of that, so you can spend your time where it matters, writing the application and business logic. The problem with a lot of CMS and frameworks is, as you correctly observed, that they've become bloatware over the years, by continueously added more and more stuff to it. We try to avoid that, and keep the framework small, fast and clean. 2.0 is taking another step in that direction by not only splitting the framework in kernel and core, but also moving all non-essential core classes (for example Image) out of the core and into an installable package. 2.0 is also moving towards the PSR-1 standard and composer driven packages, which means you can add any composer library to the framework that is compliant, opening up a very large repository of libraries you can use in your application. Want to use a low-level DBAL to access the database, or use Doctrine? Your choice.

You were involved in "CodeIgnitor", correct? You didn't have anything to do with this "Model" is optional MVC direction, right? Of course it's optional because they're still using SQL wrappers and not an ORM. Just giving you a hard time.

The CI documentation states the following (Models are not required) http://codeigniter.com/user_guide/overview/mvc.html "CodeIgniter has a fairly loose approach to MVC since Models are not required. If you don't need the added separation, or find that maintaining models requires more complexity than you want, you can ignore them and build your application minimally using Controllers and Views. " If they are trying to say, that a model isn't necessary "if" you don't need the data layer, then I understand. The wording needs to be a little more concise.
I noticed that FuelPHP has a few spin-offs already. Laravel is almost identical to Fuel. Come to find out, that the guy who started the project worked for CI. Seems llke there are quite a few CI spin offs. Kohana is also very similar.

To start with your previous post: FuelPHP is definately not a spin-off from CI (like Kohana was). FuelPHP was written from scratch (only the DBAL has some kohana components), there isn't a single line of CI code used (if only because the CI license is not compatible). The fact that most of us have a CI background probably only means we know how it shouldn't be done. What I think they're trying to say it that CI allows you to stuff everything in the controller if you can't be bothered. Technically possible, probably in every MVC framework. Smart? No, not really. On to your second posts. I have a feeling reading it that you haven't really grasped how FuelPHP works. For starters, there are only three base classes in the framework, all three controller base classes. Not a single other class can be considered a base class from the applications point of view. 1. Can you explain what you mean, as I don't have a clue. 2. Probably related to my previous remark. They are not base classes, but static helpers. As you correctly observed. So you don't use them in an OOP fashion, you use them as you would use an internal PHP function. Form is again a helper class, Fieldset has nothing to do with the html tag, but with a collection of fields that make up a form. Fieldsets aid in form generation, which build in validation and ORM integration. As correctly observed, the architecture of v1.x is quite static, with a lot of factory, singleton and multiton patterns implemented. Which leads to all kinds of problems, for example Input is a property of a request, which Cookie is a property of the environment. We've learned a lot while working on 1.x, which we have put to use when we designed 2.0. See https://github.com/fuelphp/fuelphp/wiki for some insight into the architecture of FuelPHP 2.0.