I think I get what you mean now. I basically take the "meat" of the hard work I was doing in the page controller, and make a decision whether it deals with generic input. If it does, then I could fatten the controller helper library (in my case Controller::blahblah) to handle this, or use the existing class methods that are there if I have them.
The best way I can describe it without going into article detail, would be: Consider the controller the part that essentially wires distinct parts togather. In passive view implementation of MVC the view and model do not need to know about each other, which is what causes most confusion I think amongst people just starting to use MVC.
Most articles talk about MVC from a event driven paradigm and show the dependencies between them which only leads to wacky implementations of MVC on a web platform.
That being said, The model and view are typically distinct (whether having one dependent on the other is handy is subjective -- personally i find it very rare where this make sense but there are instances) so there are no dependencies between them and the controller is responsible for pulling on one (ie: Model) and pushing data into the other (ie: View).
This is what is typically meant by "The controller provides the wiring" as it pulls on all the variables, initializes anything specific to the context of
that action (global initialization is done in the bootstrap/index.php) and creates the Model object and/or View objects and returns the result, either as a response object, or echo'ing the contents directly to display.
In theory controllers should be "minimalistic" but in reality sometimes it just makes sense to make them fat(ter) than ideal. While it might be bad design according to some, what you understand of the system is always more than some stranger. Budgets are a b*tch.
I see you created a one-level model here with a domain model -- AccountModel. (Sidebar: Perhaps later on you could show me a case where you recently implemented a two-level model tree such as Bank, which holds Accounts and Transactions as children, for instance -- I would be curious to see how you implemented such a thing. I have my own notions, but I like to see what others have done.) And if it does deal with output, then I push the logic to the view.
Not sure I understand. One level model?
The model is a virtual representation of the business object or domain object. Domain model is the collection of individual business objects.
A model can therefore represent more than a single table. A model does not nessecarily map 1:1 with a database table.
A model might manage several tables, a file system and RPC request. Or it can also represent a single table, the model is a high level abstraction. This is why it helps to not think of the model as a class but rather a conceptual layer. This idea applies to most design patterns, IMHO.
Session vars occupy tmpfs (RAM + disk, because shared memory uses that, right?), and we want to conserve as much RAM as possible for everything else, such as database queries and so on, so we use encrypted and slightly compressed cookies instead, but only for storing very tiny things. Anything larger will be database I/O or, yes, we'll consider a Session var.
They don't have to, SESSION data can be serialized to a database or wherever you please just implement the following:
http://ca.php.net/manual/en/function.se ... andler.php
Database is probably fastest and most secure, especially if your app is running on a shared server.
I'll have to read up on that one. Didn't know I should do this, but you make sense.
Yes I made that mistake a few years back with my TexoCMS software. I was under the impression that Apache would not execute files with the extension JPG so that is all I checked. Unfortunately some script kiddie knew better than me and uploaded a PHP file disguised as JPG and when accessed it executed and he hacked my site.
I just use getimagesize() to verify images (I'm not sure if it's bullet proof but it's light years better than checking extensions alone).
The only photo they can find is their own. There is no way to find other file paths to see other profile photos. Not unless they reverse engineer the photo path scheme, and that requires an understanding of how and where I placed the crc32() check, which is hard to determine without seeing the original source. The source I provided here was just an example.
I'm not sure what your doing, but...if your not randomizing the file name...and using a lookup map to translate the userID into a randomized file name...it's probably reversible. Not that random names isn't reversible but it's a lot harder unless I misunderstand.
If you only *absolutely* want to show the images to the select people, you are probably better off using a proxy script to retreive the contents and perform an authorization check before dumping the contents.
If you stored the userID in the session after login, all you need to do is check the ID and if it's > 0 find the images associated with that ID and return them. Because SESSION is much harder (less likely) to be forged (except on shared hosts -- in which case implement a database interface) it's a fairly reliable and secure technique to prevent unauthorizatied users from seeing images which do not belong to them.
Cheers,
Alex