Name: Anonymous 2009-10-24 15:23
http://phpbuilder.com/board/showthread.php?p=10931946#post10931946
Everyone laugh at the retarded OOP ricer.
Everyone laugh at the retarded OOP ricer.
I'm not saying that you are, but these small tips require extensive code. I do not get why everybody thinks I'm being arrogant.
I will give it a go:
This project is probably best being designed in an Object Orientated (OO / OOP) design and doesn't require a framework, but I would suggest it, cause projects like this tend to get complex quite quickly. The following in no specific order...
1.1 - Auth object
1.2 - Validator Object
1.3 - Debugger Object
1.4 - Uploader Class / Interface
1.4.1 - Image subclass extends uploader class
1.4.1.1 - GIF subclass extends Image class
1.4.1.2 - JPG subclass extends Image class
1.4.2 - Compressed_Files class extents uploader class
1.4.2.1 - ZIF subclass extends Compressed_Files class
1.4.2.2 - RAR subclass extends Compressed_Files class
1.4.3 - PDF Class
1.5 - Database Class
1.6 - View Page
1.6.1 - Forms
1.6.2 - Images
1.6.3 - Hypers
1.6.4 - Content
1.6.5 - Menus
1.6 ---- continues forever lol
1.7 - Back End (like view, but only you can view it)
Ok this is just what I can think of at 2am...
Explaining this. lol
The design process of this should be done in 'reverse'. Thinking ahead is important with this style of programming. Start with a gameplan, an overall picture of what you want from your application, then break it down (like above). What do you want each class to achieve, how do we achieve that? What do we need to do? Will a snippet do it or do I have to design a function set for it? If the latter, what functions should I create to achieve my goal? Will this affect anything I've done before? Do I need to extend this class? Will something else work better then what I'm currently doing (which happens more often then you would think). Just a few questions, but so many more after this.
"To know your enemy, is to know the outcome of war"
I have that above my pc on the roof. Gets me thinking about a problem; by whatever means, whether it be research, trail and error, prior knowledge, help from others, I just want to know my enemy.
Database:
Ok your database object will have a handful of useful functions that handle all your db workings. This includes although not limited to, the active db connection(s), queries, fetch arrays, num rows so on so forth.
Validator:
Your validator class will include a function for each of the different inputs, data types and possibly even your cleaner functions, also will be used in close conjunction with your database class because validation and user inputted data going into a database is a law... Functions including but not limited to, is_array, is_numeric, is_bool, strip_tags so on so forth.
Debugger:
Debugger class is what the name says, functions that test your code for errors, elevated error reporting levels and alike are in here. Assure this is not used once the development process is complete.
Uploader:
This should probably be a interface for flexibility, but that’s just me, others will disagree. Although I will explain it as a static class because it covers both types and most that do not know any different won't be able to tell the difference.
This 'parent' class should contain your lets call them, 'global methods' within the scope of your class hierarchy. Meaning, the set of functions within the uploader class will be accessible anywhere within the classes that EXTEND it; in this example, the image (including gif and jpg/jpeg child classes), compressed_files (including zif and rar child classes) and the PDF class.
Now, the functions within this parent class will not be defined, meaning this class is just a 'blue-print' for those that extend it.
Within the Child classes, img and compressed_files (C_F from now on), you will re-declare and define functions pre-defined in the parent class (being what, that’s right, uploader). Thus from this point on, they are functional (working, active, do stuff). These functions will still be somewhat small, maybe just choosing the child to goto, defined paths to directories that you will pass to the child classes from here and data validation & cleaning (validator class coming in again).
Now the confusing bit. These classes (img and C_F) are now the parents to their respective child classes. So img and C_F are now a functional parent class for classes jpg / gif and zip / rar. The parent classes (img and C_F) methods are now within reach of their 'children' using parent::testFunction(); , OR you can re-define them in the children if you wish (now we getting complex :P).
Now within these 'child' classes you will find most of your functionality, including the processing and uploading of the file itself.
PDF is unique due to it being the only 'type' of its kind. Thus it will contain all functions and abilities’ that are describe above, but doesn't extend to any child classes. So if a pdf file is uploaded, clean, validate, define directory paths etc etc all in the one place.
NOW some will argue that the extension beyond IMG and C_F classes are needless. You can make this choice, I just have a rule of thumb "the less flow controllers there are, the better".
Front End (view):
This is where all the magic comes together, what the general user can see despite the countless lines of code controlling it. Get a nice template, work your PHP into it so you do not have to change any your class scripts when you want to change the overall look of the front end site itself.
Back End (admin area):
This is your zone. Doesn’t really matter what it looks like as long as it works. This will include mini-scripts that display all your data that your users have uploaded, where its located, delete, moving, updating, sizes, and probably your own admin based uploading system :P All of this can possibly be done in your front end as well and its handy to have access to commonly used admin options there (delete, hide, move etc).
This was a 'brief' and hopefully non-complex description of classes and class inheritance.
I suggest you read up on Object Orientated Programming / Patterns, Working with files and directories, regular expressions, is_ type functions and I could on and on, I say this not to belittle you because I still have troubles with this sort of stuff
Ok. Now some might say that building a semi-framework for a project this size is overkill. Maybe, but from my experiences these sorts of projects have a way of becoming extremely complex extremely fast and it is always good to have a working, tested and debugged platform to work off and improve. Do the leg work now, save yourself the headache later.
(smoke break) brb 2mins lol
Just note this is a sort of basic example of classes and how they work. Parent classes may do A LOT more then was described in this, and more then likely that will be the case. Whatever the setup is, OOP is the best way to program (imo) and beats the old "top to bottom" style anyday.
Linkage time.
OOP
Regular Expressions
Files & Directories
is_ type functions
Programming Patters Take your pick of hundreds
Validation Tutorials, take your pick
I don't know why I wrote this much, it just happened. Hope this sheds some light anyways. Im going to bed now. Goodnight.these sorts of projects have a way of becoming extremely complex extremely fast
_.-------.
----------------'' ,-.`-----.
( X ) `-.
`-' ,---. |
. `--- ----->
-----------------------. `-. |
`---------` ----+----------
| ctr() :
Can I suck your | a() :
UMLH today? ----+----------
^
|------
1.1 - Auth object
1.2 - Validator Object
1.3 - Debugger Object
1.4 - Uploader Class / Interface
1.4.1 - Image subclass extends uploader class
1.4.1.1 - GIF subclass extends Image class
1.4.1.2 - JPG subclass extends Image class
1.4.2 - Compressed_Files class extents uploader class
1.4.2.1 - ZIF subclass extends Compressed_Files class
1.4.2.2 - RAR subclass extends Compressed_Files class
1.4.3 - PDF Class
1.5 - Database Class
1.6 - View Page
1.6.1 - Forms
1.6.2 - Images
1.6.3 - Hypers
1.6.4 - Content
1.6.5 - Menus
1.6 ---- continues forever lol
1.7 - Back End (like view, but only you can view it)