Page 2 of 3

Re: Fat Page Controllers?

Posted: Sun Jan 04, 2009 3:56 pm
by Eran
I would like to back Alex on the cookie thing - store this kind information on the server. Optimizing memory usage is all nice and good, but one integer ID per user isn't going to crash your server, and it's much more secure on the server (ie, session). Is memory really so low on your server? or are you preoptimizing?

Regarding magic bytes, there's a PECL extension called fileinfo that handles that. You need a mime library as well, and getting the extension to work is a real b*tch, but it's the best solution currently (PHP 5.3 should have some goodies in this department).

Regarding image files - if you really don't want them to be accessed directly, put them outside the of the document root and serve them with PHP (based on credentials).

Re: Fat Page Controllers?

Posted: Sun Jan 04, 2009 4:50 pm
by alex.barylski
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. :P
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. :banghead:

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

Re: Fat Page Controllers?

Posted: Sun Jan 04, 2009 10:08 pm
by josh
Read Martin Fowlers Analysis Patterns, if you don't currently see the benefit of domain models over ad hoc transaction script controllers, you will if you read this book, I promise. He goes over patterns such as measurements, ranges, explains knowledge vs operational, etc.. Just as important as the "design patterns" ( your wiki link is a 404 btw )

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 2:39 am
by volomike
jshpro2 wrote:Read Martin Fowlers Analysis Patterns, if you don't currently see the benefit of domain models over ad hoc transaction script controllers, you will if you read this book, I promise. He goes over patterns such as measurements, ranges, explains knowledge vs operational, etc.. Just as important as the "design patterns" ( your wiki link is a 404 btw )
With no cash coming in December (fixed bid overruns suck), I'm on an extremely tight budget. I did manage to get a $50 Amazon gift certificate. I want to spend it on the *best* book for the money on design patterns. Haven't figured out what that is. If anything is academic as, say, reading a C. J. Date SQL manual, it won't get my cash.

And what about this link below, which is free?

http://en.wikipedia.org/wiki/Design_pat ... r_science)

P.S. How many raindances and prayers does it take for a late project to get completed while I sleep? It's 3:39am EST, and I'm still coding...

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 5:33 am
by josh
"Enterprise" ( framework ) Patterns ( ORM, Domain Models ) ="POEAA"
Design Patterns = "Gang of Four"

I'd recommend those 2 in that order, and then "analysis patterns", and "refactoring" after you've read those. The wiki does a good job summarizing, but unfortunately the very nature of abstracting is that you miss out on all the detail, which could mean the difference between "being familiar" with something and "understanding it fully".

I actually read that page and a lot of the sub-pages, before purchasing the books. Let me tell you I thought I understood it after the wiki but I didn't, I'm not the sharpest tool in the shed but it took me a few months to let all this knowledge sink in, this isn't something you're going to master overnight you know.. Good luck with your finances.

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 8:32 am
by allspiritseve
volomike wrote:With no cash coming in December (fixed bid overruns suck), I'm on an extremely tight budget.
Go to your library, ask about InterLibraryLoan or something similar (ILL is national, here in Michigan we also have MelCat). Depending on how big your library is, it might be free, or you might have to pay a couple of bucks. I get most of my programming books through my college, and then buy them if I still deem them useful enough. For purchasing, you probably won't get more than a single programming book for a $50 card if you buy new... check out dealoz.com. I buy all my textbooks online, and dealoz is basically a search aggregate of a ton of used bookstores online, including half.com, amazon.com marketplace, ebay, etc. I was lucky enough to snag PoEAA for $15 off ebay, when it was selling for $35 on half.com... you just have to time these things right.

If I had to recommend the most bang for my buck from a book I've gotten, I'd recommend Refactoring by Fowler. PoEAA is awesome, but a lot more theoretical and harder to just jump in and start applying.

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 8:44 am
by Eran
Refactoring FTW! :)
Get it first

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 5:08 pm
by alex.barylski
FTW...what does that mean?

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 5:11 pm
by Eran
for the win? :P

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 7:24 pm
by volomike
It means For The World

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 7:25 pm
by allspiritseve
volomike wrote:It means For The World
Eh... pretty sure it's win. :D

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 7:26 pm
by alex.barylski
Ahhh...for the world? Weird.

I always thought you guys were being funny and saying WTF but backwards. :lol:

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 7:27 pm
by Eran

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 8:37 pm
by volomike
Didn't know that. Okay, thanks.

Either one works, though.

P.S. I had fun with the Sitepal ad on that site you just posted, making the Sitepal lady say obscene stuff. I should probably be ashamed, being 41 and all, but man that is hilarious in a second grader kind of way.

Re: Fat Page Controllers?

Posted: Mon Jan 05, 2009 8:54 pm
by Eran
:lol: