FuelPHP Forums

vanarie

I'm looking at various php frameworks and found Fuel by accident. I've looked at DooPHP and Yii. Fuel looks like a great contender. I've been basically hand coding PHP for years and have written complex apps without the use of a framework. I've pretty much used one class to generate forms and have a lot of "includes" for misc functions. Works great so far and I think my code is pretty clean, or as clean as PHP code gets. I'm now needing to look into cloud hosting and probably integrating an API of apps that I build. I can see how using Fuel or any framework would make it easier to setup a general API, but outside of that, what are the real benefits of using a php framework? I think migrating some of my current projects to Fuel would be a lot of work but could certainly make life easier in the end. Thanks!

Harro

For me personally, the benefits of a framework are
- you're using a standard, code can be maintained by others
- typically uses several design patterns, promoting reusability and DRY
- all dev time is spend working on app logic, not on "housekeeping" overhead
- development is a lot quicker, either a money saver or maker (depends on the side of the table you're on)
- you're not trying to re-invent any wheels. A framework provides tested functionality for common tasks
- a framework allows you to produce highly reusable code (again, either a money saver or maker)
- multiple developers, large user base = (usually) less bugs, more security. There's so much you can do on your own ymmv... If you search for it, you'll probably find more reasons. And than it's up to you to determine whether or not they are valid in your particular case. Can't speak for you, but I rather work on exciting new code, than on all kinds of housekeeping. Great that you've spend a month working on a state-of-the-art login system. But all your users see is a username/password field and a button. Let the framework take care of the boring stuff, and spend that month on the application logic itself.

vanarie

All good points indeed. Sounds like I should just jump in and test the waters. I was wondering how difficult it is to migrate a more "free form" app with lots of discrete functions() over to Fuel. It looks like some of the legacy functions in my code would be superceded by some of Fuel's core class functions. I really like that Fuel has all these basic class functions to work with - I guess most frameworks have core functions to work with like this. Thanks for the points.

Mattameus

I was in the same boat you were in about 6 months ago. There is definitely a bit of learning curve to understanding the concept of "what exactly is a framework", but once you get past that, its much easier to start distinguishing the good from the bad. I had also tried DooPHP and even a few others, but ultimately my "free-coding" instincts felt too restricted by them. Thats when I stumbled upon FuelPHP. The documentation is good enough and the overall concept they adhere to is totally in line with the way think. I'm certainly not anywhere close to being an expert, but I just thought I'd chime in and let you know that you are not alone. Good Luck! Matt

vanarie

Matt, thanks for the comments. I like to learn by example and wish there were more examples in the source or on the forums, but there are a few under Code Share. I did get the install running OK, but stopped there for now. Q: I have a lot of includes that contain functions, where do you place them in the structure of a Fuel project? I'm thinking that once I understand the general road map for converting "free-form" php apps over to a framwork, that would be 1/2 the battle to getting it done. -A

Harro

Functions, in the form of 'helpers', as best stored in a static class.

// instead of this
include 'helpers/functions.php';
$var = myfunction();

// do
$var = Helpers::myfunction();

where, in this example, Helpers is a class in app/classes.

Mattameus

Yeah, that was hard for me to grasp as well. Not because it was terribly complicated, but because there are so many terms built around this "frameworks" concept that it almost sounds like there is supposed to be an element of magic somewhere. First, keep in mind.. that I am still pretty new as well, so its entirely possible that I might say something that isn't entirely correct. That being said.. Here is the basic roadmap that really unlocked this all for me: * Seeing these frameworks in a more modular fashion was the first step. Meaning... a bunch of classes that I can pick and choose if/when/how I want to use them. I also had to figure out what MVC truly meant with regards to these frameworks. 1.) The first thing I really got a hold of was the Routing concept. I thought it was pretty cool that I no longer had to rely on direct URL's and could instead use the URL as a relative path to a particular page. And furthermore, that I could tack on variables. (I learned this step from DooPHP's documentation & tutorials). Its really all very similar from one framework to the next. I would still recommend checking their docs out in fact.. maybe even going through their getting started stuff. You will find that understanding routing will unlock how each frameworks directory structure works. Here is one of the pages that really helped. http://doophp.com/demos/uri_routing/ 2.) After understanding the Routing concept, the Controller & Model & View concepts started coming alive. Rather than making include files or classes, you create a controller. The basic difference is that the "controller" relies on routing. So without a proper understanding of routing... you will be hard pressed to figure the MVC.
i.e. Basically, you take your include... Extract all SQL & DB code and make a separate include for it, which is referred to as "Model". Then you extract all the HTML or display code and make another separate include for it, which is referred to as "View". Then, all the leftovers in your original include make up the controller. Then your point of entry is the controller, which would then call upon the model, and ultimately either output your html directly or pass things along to the View. (when I say point of entry I don't mean that literally.. routing will explain true point of entry) 3.) In a sense you will have to get over the fact that you are creating more files. But ultimately I think it leads to fewer files or you break even. Anyway.. hopefully that helps a little. That should at least help you understand better what questions you want to ask. Took me a while to know what exactly it was I was stuck on. (I could very easily be wrong, but I think wanwizard may not really understand the magnitutude in which we would use the word "includes". I do understand the concept of a helper class, and he is certainly correct, but I'm thinking you are probably not getting that far yet?) Matt

Harro

It's difficult to comment on someone else's code based on a single statement, without actually having seen any of it. See my statement in that light. In my experience, if you are facing the task of modernizing an old procedurally written application, you are digging yourself in when you decide to simply try to cut up your old app and squeeze it into your framework of choice. You'll end up with a complex and suboptimal application, due to the fact that you're not using the framework to it's full potential. Internal class stucture, routing, form handling and validation, all of that works different and is not reusable. In similar projects I've always ended up redesigning the application, rebuilding the core logic from scratch, and only reusing pieces of business logic if and where possible. You'll end up with an app that's a lot more maintainable.

Mattameus

@wan I certainly wasn't saying anything against your response. I am simply picking up on what "I THINK" is a guy who is looking for the answers I was looking for. Where does a fella who has been writing code in a certain way for many years begin? Its such a rebirth in thought. I know for me I was searching for a way to map things from old to new.
i.e. Where does this function go? How do I handle ajax requests? Do I still need this piece over here? If not, why not? What replaces it. Why are there so many directories? What do they all do? Why would I want to split one file into 3 just to satisfy this "MVC" thing that seems to be all the rage? I'm very proficient with SQL... why all this bloat around something that is terribly simple? etc.. You are certainly right when you say that subpar apps will result from trying to piece old code into a framework. Rewriting is definitely the way to go. But, in the beginning, piecing old code in might be the best way some people learn. Granted, now that you'v pointed that out, he can keep that in mind. Besides... the first app in a framework is probably not going to be 100% correct and efficient anyway. It takes time and a little trial and error since we aren't all being hand held every step of the way. Again, I could be wrong about what's being asked here, but just like you.. I'm simply trying to help.

vanarie

@Wan - I see what you're saying about not just trying to transplant the entire "legacy" functions to a PHP framework because you'll generally get less favorable results. I was generally asking for an approach roadmap that would set me on the right path for going from a pretty clean, hand coded PHP code base to a Fuel. @Matt - not sure you need to be defending your responses - I appreciate your help as you were in the same boat as I am now! I'm sure there are plenty of people just like me, so it's all good. In the end, maybe someone should take the time to write a tutorial called "Tips on migrating your legacy codebase to Fuel". Done the right way, including dos and don'ts, it would increase adoption rates for Fuel.

Mattameus

Actually, it would help the adoption rate of all frameworks. I did most of my learning with DooPHP.. got really frustrated.. found Fuel, and it didn't take more than a day or two to figure it out. The ONLY potential drawback I see to Fuel is that its small & new which leaves me hoping that it doesn't get abandoned at some point. However, I'm going into it knowing that, and I'm fairly confident that myself & others would see to its continuity. Unfortunately, I'm still a little to new to contribute anything. Please feel free to ask questions though.. I'll be glad to do what I can to help you get across the bridge. The more people onboard the better. I'll be curious to know if my suggestion about figuring out routing was helpful. It seemed to be the glue that held everything together. I'm still fascinated by the concept of having a single entry point into an application. It makes ajax a million times simpler. I used to have (for lack of proper term) transport classes/functions that I would use to recieve the direct form submissions, which would then pass the information on by making the appropriate class calls. Now, I can basically interface with my classes (controllers) directly. Granted it does force you to restructure the way you've always done things a bit.

vanarie

I will let you know when I get into it more.

Jelmer Schreuder

The ONLY potential drawback I see to Fuel is that its small & new which leaves me hoping that it doesn't get abandoned at some point. However, I'm going into it knowing that, and I'm fairly confident that myself & others would see to its continuity. Unfortunately, I'm still a little to new to contribute anything.

While Fuel is small, it's also extremely extendable. For example with CI I kept a copy of it on my local drive with which I intergrated some 3rd party libs and updating the whole this for any of those parts was a huge pain. If I were to make a similar collection of libs for Fuel I'd just create a package I could drop-in on top of any Fuel install instead of having to do this in the app dir (or the core in some extreme cases for CI). On the point of abandoment: there's 4 of us main devs, that should already instill a sense of security of continuation. And we're very responsive to pull-requests - though some more complex ones might take a bit to be accepted. As to the suggestion of a guide into Fuel for those without framework experience will be pretty much impossible. For example I used a mixture of classes and functions which I imported from external files and had written some myself and some open source. All of which was bound together with something that was kind of like a Front Controller (what you called a "single entry point" ), but I did have other entry points for specialized stuff as well. I imagine some of you wouldn't have had a front-controller but used a far more intergrated series of libs as backend.
Everybody has their own way of doing things before turning to frameworks, it's impossible to write a conversion guide so generic that it would be usefull for everyone trying to get into frameworks. What is possible however is to write a guide that introduces concepts like Front Controller, Routing and MVC. But I currently don't have the time, and I'd guess there will have been others who've already taken a crack at this but for other frameworks (like CI). Those concepts won't differ much between frameworks.

vanarie

I agree that it would be somewhat difficult to write a one-size-fits-all conversion guide for those MVC noobs out there, but it would certainly help. I have a friend of mine who teaches at a college part time, and she pointed out to me that people absorb new information/concepts in various ways. What works for one person might not "turn the lights on" for another person. I'm in favor of a general overview as you suggest as well as a guide to help those who already have a codebase to start to migrate things over. If nothing else, just a simple guide like: "Generally speaking, functions contained in your func.inc.php will go here, database extracts go here, function calls & logic here, front end design/css calls go here...". I'm sure there's more to it, but that's the idea. As time goes on, I'll be able to speak about it more intelligently. As you mention, once you have a good concept of how the MVC model works, you can basically work with any php framework out there like Yii, CI, Fuel, etc.

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.

Howdy, Stranger!

Categories

In this Discussion