I took Java / AP programming classes in high school so OOP isn’t completely new to me. It’s just been a few years. It’s coming back quite fast.
Plus I’ve dabbled in Ruby which is purely(?) MVC (from what I worked with) and I’ve had help from @ParkinT with explanations of MVC. I just have never “implemented” it myself.
Sorry, I don’t think I explained myself very well, what I meant about avoiding isset is that it’s good practice to check that global vars are set before you try to use them, otherwise you get a PHP warning. It’s common to use isset for this:
$email = (isset($_POST['email']) ? $_POST['email'] : null;
but I think that’s a little messy, so I find it neater to use filter_input:
$email = filter_input(INPUT_POST, 'email');
this does the isset check for you, plus of course you can add filters to santize/validate the data.
Regarding MVC/separation of concerns, I’m just saying that it’s better if classes such as your login service don’t care where the data comes from… as far as it’s concerned, it has been passed an email address and a password to verify, and santizing that input is not its concern.
Without jumping straight into full-blown MVC patterns (as TomB said, that can get complicated pretty fast) a good general principle is to keep your classes as ignorant as possible about the outside world… only your top layer (roughly speaking, your controllers) should be fetching/validating user input, and then handing it off to specific classes to do the work.
Right - so looking at my login class from post 12, it looks like if I just move email/password to the top (above require once / login=new login) and filter input that, that would be the best option since it’ll just return false on failure (skipping the rest), and doing so would allow me to remove the issets and (agreeably) keep the program cleaner.
I do understand about keeping parts of the program ignorant; I’m just unsure of how strict we follow that rule. Like, I manually set database connections / call the login based off user input, but I just wanted to make sure that was the proper way. I don’t want to fall into bad habits.
Other than that, this program is pretty reusable and could be used elsewhere (not that I recommend it) as long as the PDO call and DB fields were all the same.
Probably the reason you end up doing some things manually is because a complete OOP solution requires more than just one class. You’d probably have a service container class, a validator class, a password encoder class, a repository class, a form class, some entity classes, and so on. But in this topic, everyone is focused on just one piece of that. That one piece won’t look or feel like a complete solution, because it isn’t, nor should it be.
So, is your goal here to create just one of the above classes? Or are you trying to make the complete OOP solution?
This application will have more classes in the future but ultimately you have to set your db credentials somewhere right? There has to be an initial input by you.
I agree. It is difficult to just consider a single piece of the puzzle because they are all so important.
Pretty much just go over to the Laravel 5 landing page and look at the topics in the left menu. Doing it right requires supporting all that.
I agree with that but if this is a learning exercise then blindly doing it right because someone told you how to do it is probably less valuable than doing it wrong and then understanding why that was the wrong approach.
In that regards it would be more valuable of an exercise to convert your existing website over to Symfony or Laravel than it will be to *hack together your own, ranky dank “MVC” solution. If learning MVC is the ultimate goal than you can’t go wrong with sailing the seas of Symfony and/or Laravel. Some of that code can be very difficult to understand but using a tool like xdebug to step through it will help. I think that is MUCH more valuable than what you’re doing here.
The ultimate goal is to give me something to do so I don’t go crazy. Coding crap from scratch is a pretty good solution to that.
We can now use filter_input() to replace $_SERVER
eg:
filter_input(INPUT_SERVER, ‘HTTP_HOST’)
so I woudn’t rule it out completly. $_SESSION should be added soon enough…
If you are autoloading though then just take the drive and learn how to use the The HttpFoundation Component (The Symfony Components)
Safer, more secure and used in more than one framework.
Unfortunately as nice as that is, it doesn’t work if you’re using a fastcgi implementation of Apache which makes it unfeasible if you want your application to be portable. See https://bugs.php.net/bug.php?id=49184 http://php.net/manual/en/function.filter-input.php#77307
Shame, although I personally would be willing to sacrfice a little portablility I guess you could always fallback to the Super superglobals and just wrap them in a similar way. Good to know Get/Post & Cookie is safe at least 
That’s all fine and well but how do you write a unit test against that?
Wouldn’t that depend on it’s application? For the most part I treat it the same way as I would testing superglobals you would wrap them in a class that would satisfy your needs and test that.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.