Dr Livingston, can you please expand a bit on these two paragraphs. For instance why not got the MVC route? Too complex for my newbie brain?Further too this, don't design your framework around the Model View Controller pattern, whatever you decide to do. If you are looking for inspiration, look at how you could create a smaller, generic framework to help data transfer between a source and a target, which would be used as the foundation for your ever growing framework.
Do the simple things first, and you will be surprised at just how much you can do with so little later on. This is what I done, and still today when I refactor and add to my own framework, I am taken aback at what I can achieve with those early foundations.
I am intrigued please explain.
A system architecture should not only be based on a design pattern, such as MVC, it should also be based on different programming paradigms.
In theory, putting the models in the models/ directory, the controllers in the controllers/ directory and the views in the views/ directory makes perfect sense, but in practice it doesn't; the only thing you are doing is organizing your files and folders, and not establishing a proper system architecture.
Building a system architecture is not simple, it adds more complexity to the system, but it offers much more advantages that just organizing your files and folders.
The complexity of systems (websites) has increased, and support for more and more abstract concepts in programming languages and environments has also increased. So, I still don't understand why PHP frameworks can't see beyond the OO and MVC approach, it doesn't make any sense.
I use CakePHP, in my opinion, its more flexible than CodeIgniter, but not as professional as symphony....
Both of those could be wrong, as I've only used those frameworks for short times, but I would 100% recommend CakePHP...
Expect it to take you anywhere from a week to a few months to understand MVC fully, but when you do, it's great!
My biggest problem with Cake has always been the Session Component. For 2 years, they've used the eval() language construct to get values out of the SESSION array. Cake developers minimized this issue saying that the use of eval() is not dangerous and that using it to get values out of the session array is completely normal.
But, the PHP manual clearly says:
When I hear the word eval() I get paranoid, and specially when I hear that people are using it to get and write values to the session.The session module cannot guarantee that the information you store in a session is only viewed by the user who created the session. You need to take additional measures to actively protect the integrity of the session, depending on the value associated with it.
There are several ways to leak an existing session id to third parties. A leaked session id enables the third party to access all resources which are associated with a specific id. First, URLs carrying session ids. If you link to an external site, the URL including the session id might be stored in the external site's referrer logs. Second, a more active attacker might listen to your network traffic. If it is not encrypted, session ids will flow in plain text over the network. The solution here is to implement SSL on your server and make it mandatory for users.
Ok so I already have a collection of classes that I use in my cms's. They're used as tools for the procedural scripts. The problem is it aint evolving! So I want to nudge it along myself.Originally Posted by McGruff
Maybe I start with taking some of the more common procedural scripts and building them into a class or classes. I'm not sure. Am pretty confused as to what step to take next.
> I am intrigued please explain.
Okay, I will try. There are two issues with the Model View Controller in my view. The first one is that for a lot of people, they are looking for the holy grail, and for some reason they seam to think they'll find it in this pattern.
The problem is for a lot of people is that to understand this pattern, you need to have a basic understanding of layering. Without this understanding, you will without a doubt make a complete a*se of your MVC implementation.
With software design, it isn't about MVC only. What I mean is that your application for the most part, isn't particulary split three ways; There is a lot of things that go on in between the layers that are not projected efficiently enough in most implementations of MVC that I see a lot.
So that is one problem, a malformed MVC implementation, which is to be used for what? A foundation for a framework? So off you go with your Model class, your View class and of course not to forget your Controller class and it's like your set for life huh?!
That isn't a framework mate, and don't kid yourself either. Like I said, start simple and keep it as transparent as possible. The other problem is that there is far, far more to web development other than what this pattern represents.
People get tied up in this pattern, and honestly, it has been this one pattern that has caused so much trouble for so many developers, and been the source of many headaches, and for what?
I can understand why so many people put so much behind this pattern, as I fell into that trap myself a few years ago, when PHP developers first discovered what design patterns where, but now I know better.
If you want a viable framework, which can grow organically (from within it's self) then avoid using this pattern as a starting point. What you want, is a framework that already has the tools available to allow it to grow, to allow it to achieve incredible things, with a minimum of fuss, and with a minimum of bloat.
Keep it simple, start simple. Like I said earlier, I started with an abstraction and interface to allow data to be transfered easily between a source and target (objects), and it's grown from there. This simple interface and abstraction, along with a couple of others (Composite, Visitor) allow me to leave my framework to grow at it's own pace, when required.
A lot of times, I've never had to script a new implementation, as I've been able to take advantage of what is already there, within the framework. You don't need something like PEAR to have a framework. You wouldn't want to anyways.
To start you off, think of something that is basic, simple and that you have used on a regular basis. Keep it. Then repeat, but on each iteration, don't just implement what you already have, but implement it in such as way, and in such a manner, that you can take advantage of what is already there; In your framework.
It ain't going to be easy, in fact it won't be easy but don't give in. Keep hammering away, and you'll find that you'll sculpture something out of it
It isn't so much about ignoring the pattern as such, but more that it is a bad starting point, in regards to framework design and development it's self. By that I mean the framework, and not MVC as an implementation.
My thinking is, as I've stated earlier is to keep things simple, to start simple. With that in mind , the MVC isn't simple by any stretch of imagination. With all the discussions that we have here on Sitepoint about this one pattern, I'm sure you can understand where I'm coming from?
There must be a new thread started ever other week; That is what I was referring to in regards what I said about searching for the holy grail earlier. For those with lesser experience, they read about MVC and are led to believe that it'll solve all their problems.
But it doesn't, and they end up on a forum, asking for help and advice. They are left asking if this (their implementation) is MVC
This is why I said a few posts back not to begin with this pattern. The Model View Controller isn't simple, there is no clear cut, standard approach for an implementation, nor will there ever be.
There is just way too many variables that need to be considered, too much to be considered to use MVC as a basis for a framework. At least a badly layered implementation of MVC isn't going to be a great foundation to let the framework grow.
Also, how would you allow your framework to evolve freely if it's restricted to MVC as a starting point? MVC to me, is something that is set in stone, it's solid, whereas a framework needs things to be more abstract. Otherwise, what you already have, you are stuck with.
You are left with having to refactor around it, rather than refactor with it.
> The problem is it aint evolving!
What have you got? Post something here that does just one thing, and lets see how it goes from there
Ahhh I see where your coming from Livingston. Thanks for taking the time. I have a few processes that I can see becoming a foundation so I'll go away and work on those.
Thanks everyone for throwing your two cents in and being so encouraging its very inspirational.
>Post something here that does just one thing
Everytime I mock something up. I find that sticking to one thing very hard as the class unfolds all these methods keep popping out at me!
For instance heres something that began as a authorization process.
(please dont mind the pseudo code)
As you can see it already seems to be getting away from "just" authorizing.<?PHP
var = $user;
var = $pass;
var = $email;
//construct connect to db and grab variables
//encrypt pass for checkinig against db
//check to see if user exists
//check pass against db
//return error msg if any of the above fail
I can't recommend Symfony more. I've now built two public applications on it and I just love it. I did give CakePHP a try first and hated it... kept running into problems and not finding any documentation or help. I've got a copy of the Symfony book (the same as you can view free on their website) on my desk now.
That's exactly my point. If you look at today's php frameworks, they all followed your advice: they were having troubles figuring out how to implement things and deciding what goes where (controllers, models and views), they looked at other people's implementations... and bingo, everything looks like RoR nowMVC is very simple. The trouble comes in figuring out how to implement things, and deciding what goes where; and there's no better way to learn than to look at how other people have done it.
The problem is, like I said before, what works in RoR not always works in PHP, and vice versa.
I don't think Symfony looks like RoR. It looks more like Struts I suppose.
2) Out of all the popular php frameworks, the only one that really set out to copy rails was cake, and the end result is quite different, IMO.
3) In any case, it's smarter to copy something that works than to try to reinvent the wheel. Yes, some of the stuff in RoR can't be done in PHP, but you can still understand the problem that was being solved and figure out other ways of approaching it.