ignace

Wow, my worst days are like accidentally wipe clients database with no back-up. But everyone has done that once or twice. And that's about it

There is no reason you should have one class that does and knows everything. It's far better to create specialised classes for your pages. It's also far better for performance as you'll quickly be loading too many unneeded classes.

As a side note I want to point out that MVC does not mean create a Model class, a Controller class, and a View class. It means separation of concerns, where the important bits are Model (Business Logic) and View (Presentation Logic). The Controller is the part that binds these two together. A simple (W)MVC example would be a contact page: // contact.php if (isset($_POST['submit'])) { mail('[email protected]', $_POST['subject'], $_POST['message']); } include 'views/contact.html';Believe it or not, but this is really an (W)MVC implementation. Where: - contact.php -- is the controller (model and view are unaware of each other, yet together they achieve a specific goal, contacting the owner) - mail() -- is the model (hiding how mailing works and providing a simple interface) - views/contact.html -- is the view (hiding the interface how the user will enter the required data) - Apache -- is the frontController (like your App.php, translate a route to a controller) It's important that the model is unaware of the view and the controller otherwise it would severely limit it's re-use. Your LoginModel is also not correct because it violates the Single Responsibility Principle. It finds a user based on user and pass, and it stores a session cookie. You'll also have to duplicate the "find a user based on user and pass" every time you need it thus violating the Don't Repeat Yourself principle. class UserMapper .. { private $pdo; function __construct(PDO $pdo) { $this->pdo = $pdo; } function findByNameAndPassword($username, $password) { // implementation } } class Session .. { function set($key, $value, $lifetime) { // implementation } function get($key, $default = null) { // implementation } } class LoginService { private $userMapper; private $session; function login($username, $password) { // $user = $this->userMapper->findByNameAndPassword($username, $password); // if (null !== $user) { // $this->session->set('loggedin', true, 86400); // } } function isLoggedIn() { return $this->session->get('loggedin', false); } }As an example. You would use the LoginService in your controller as it hides how a user is logged in and is completely re-usable in another project if needed. Controller and View are considered to be project specific and thus (mostly) throw-away-code. The Model however not so much. This kind of programming will help keep your controllers thin and your (model) code re-usable.

I would definitely tell them. Not sure what the laws are in the US but I haven't run in any trouble so far. It's not like your hacking their software plus it gives them an incentive to choose you now and in the future. I found they can appreciate someone with proper knowledge of things, someone they can trust and build their business on. That's what you do as a freelancer after all, build relations.

Packagist is a web interface to the packages available on composer. You can search for packages just like with composer search and then composer browse. If you develop packages yourself you use it to register and manage your packages.

No hotdogs for you, mister!

Now you made me curious, link?

Symfony2, Zend framework 2.0, .. Look for a framework that does not constrain your modeling in any way. To give an example in CI & CI2 you need to extend Model and call it through their Loader interface for it to work. That's a BIG no-no

JetBrains PhpStorm -> http://www.jetbrains.com/webide/