keeB
-
Posts
1,075 -
Joined
-
Last visited
Everything posted by keeB
-
Slightly confused about how to do something in OOP
keeB replied to ordinaryToucan's topic in Application Design
Your explanation makes me feel like whatever you just did is not OK. While you can pass objects around, child objects aren't supposed to care about their implementation, just use them to accomplish their own goals. Objects should be very selfish. $this->user->login($this->input->sanitize($this->input->getPOST('username')) This is a classic case of no! Why should your user object care about how to authenticate? It should only know some basic things, like first name/last name and any real associated attributes. You could then have an Authentication module which accepts a User object to do the login. Here's an example <?php //model object, which is really just a namespace with accessors class User { private $firstname; private $lastname; private $username; private $password; private $userId; //associated getFirstName() and setFirstName() methods.. etc } class Authentication { public static function authenticateUser(User $user) { // do whatever authentication you want done here. } } ?> Next, and this is a minor gripe, but data should be passed around sanitized, and you're going to realize you're going to have $input->sanitize($some_data) All over your code. You should have a private sanitize method which sanitizes any type of input for consumption in the Input class. That's awesome. But make it transparent and done whenever the data is set. If you have any other questions we'll be happy to answer them. -
No. Here's the pseudo code: Request comes in for player $user (could be someone browsing his profile, attacking, I don't know your game, so bear with me) Code loads up entities associated with $user - User table and Hospital table: select * from user u left outer join hospital h on u.userid = h.userid If user entries are in hospital table (you have the record set if so, check what a left outer join [1] is if you don't know) If user is in hospital: check HOSPITAL.EXPIRE_TIME (this was set when the user died) If HOSPITAL.EXPIRE_TIME > TODAY() DELETE FROM HOSPITAL WHERE USERID=$USERID $user->dead = false; ELSE redirect to inventory page $user->dead = true; [1]: http://www.sqlnation.com/ansisql/sql_leftouterjoin.htm
-
Well then, you're both wrong. Why decrement a value for EVERYONE every minute when you can just set EXPIRE_DATE in the hospital table? When the user is queried, left outer join on hospital to get his information if needed. if EXPIRE_DATE > TODAY() he's no longer dead.
-
Any design which requires database cleanup so frequently is silly. Your thoughts on database normalization are correct, but your implementation of normalization leaves a bit to be desired. Basically, instead of a cron job, you should only check to see if the player is alive and well when needed, not on some scheduled interval. I think that is the complexity the user was referring to. Your solution doesn't scale well at all.
-
I don't think anyone said they loathed them. I think people are just saying that sometimes they are a Necessary Evil -- like (potentially) your case.
-
I use Singletons for one real application: The Abstract Factory [1] pattern. I've never thought to instantiate an object in the actual .class file. I guess I am really against that because it really would confuse me. Readability is so huge to me. [1]: http://en.wikipedia.org/wiki/Abstract_Factory
-
Yeah. It's common when ordering matters to add a 'listIndex' or something similar column. If you remove one of them and forget to update the indices, though, it's a pain in the ass.
-
Yep! Have a blast.
-
It isn't.
-
I wish you luck. There's some great OS Application frameworks I use quite frequently. Will you be focusing on Windows programming?
-
Your session_start(); is commented out.
-
define the header file as a function header.php <html> <head> <!-- some head information --!> </head> <?php function header($userId) { echo $userId; } <!-- the rest of the header in html --!> ?> index.php <?php include ("header.php"); $userId = get_current_user_id(); //i dont know, i made this up. header($userId); ?> This is PHP Help related code though, so I won't delve any deeper.
-
Point taken
-
Don't think you need to worry about Singletons at this part in your OOP learning. I also think the class mentioned above is particularly damaging. Why pass an array of input parameters when you can just as well specify it in the constructor? Because you want to cause yourself and anyone using your code a headache. <?php class SQLException extends Exception { public function __construct($msg) { parent::__construct($msg); } } class MySQL { private $connection = null; private $database_name = null; public function __construct($host, $username, $password, $database_name) { $this->connection = mysql_connect($host, $username, $password) or throw new SQLException("Could not connect to database"); mysql_select_db($database_name, $this->connection); //set the 'name' of the database $this->database_name = $database_name; } public function getName() { return $this->database_name; } } ?>
-
Short answer. No. Long answer. Hell no. I'll be a bit more helpful though You're on the right track. Taking an interest in making yourself a better programmer is step 1. Step 2 involved a lot of trial and error, and a ton of reading. It will take a long time to make the shift, to start thinking about low level components instead of the big picture. Some helpful material are: The tutorials on the main page: http://www.phpfreaks.com/tutorial/oo-php-part-3-uml-classes-and-relations Design Patterns : http://en.wikipedia.org/wiki/Design_Patterns Start reading peoples code in this forums and ask questions about things that don't make sense. We offer a lot of help, and thankfully we're not at the point of redundancy like the PHP Help forum.
-
While you're still looking around.. you may want to take a look at Tango [1] or, if you'd like to branch out and try a CMS built on Python/Zope take a look at Silva [2] [1]: https://launchpad.net/tangocms [2]: https://launchpad.net/silva-project
-
Unfortunately not everyone thinks like you do my friend. A few years ago in my student days I developed an eCommerce client for a company. After a few months of providing support they found someone who would do it for much cheaper so cut ties with me and kept the software. Now days I include a self-destruct sequence in all my code just incase that happens again! I'm totally new to PHP code encryption so if any one could point out some good tutorials or concepts I should learn about that would be great! If I do get anything I'll post it here. I think thats ultimately your fault. Or, I have a different/better sense of business. If you planned on having a managed service you would get in to contract for product fee + support for X period. If you didn't plan on having a managed service, the price of your software should go up. If they come to you for more business, awesome. If they don't, you should have still made money. I'll let you guys play in your sandbox, though.
-
Amen! I hope you realize, and I am not trying to convince you either way, but -- Can be done with a pretty simple cron job. I have exported fairly sizable database, sometimes between 10-15gb of data, relatively quickly using pg_dump.
-
http://en.wikipedia.org/wiki/Foreign_Key
-
I think it's pretty useless. If you write anything of any value, it would come with a support contract. From a business perspective, it makes so much more sense to pay the creator than to pay someone who works for me to: a) learn the framework/code and b) confident enough not to break anything when making an update. As an employee, I don't want that responsibility, either. I would much rather have the vendor support the product because he is liable for breaking old functionality and ensuring proper cycles are invested in the new stuff
-
I think it always depends. The reason I don't generally use pre-built frameworks is because nothing generally does what I want it to. Funny enough, my main focus in PHP is writing things you'll never see. I don't like writing HTML, or care much about the Web in general. Most of my work in PHP is related to systems integration via SOAP, Sockets, etc, or for generating dynamic reports from a database or files. These are highly dynamic from day to day, so I tend to write code which can be used in that way. If I ever were to focus on writing a 'Web App,' I would probably use a framework like Symphony + Propel. I like the idea of having an ORM tightly coupled with the framework.
-
As long as the Context is not initializing anything, I don't see any harm. But, you should be careful about *what* you want to expose. Exposing too much is not a good thing
-
I don't like that. Standardize, standardize, standardize. I can understand why you do it this way -- because PHP lets you, but, reading that is a mess and a half. First this line $class = $this->getClassName($this->rq->getParams()); $controller = new $class($this->rq); $controller->init(); These should be updated to use an Abstract Factory pattern [1]. The idea is to create the object for you and to return a 'known' type based on input. What if, $this->rq->getParams() was tainted and $class doesn't exist? I would prefer to see it like this: <?php interface Controller { public function init(); public function generate(); public function afterLoad(); public function afterRender(); public function setContext(Context $context); } class ActionController { private $args; private $context = null; public function __construct($args) { $this->args = $args; } public function setContext(Context $context) { $this->context = $context; } public function init() { //i assume this sets local variables, etc } public function afterRender() { } public function afterLoad() { } public function generate() { $this->afterLoad(); $tpl = new Template(); $tpl->setAll($this->context->getParams($page)); $tpl->setOutput($tpl->render($this->context->getPageTemplate())); $output = $this->afterRender(); return $output; } } class ControllerFactory { public static function getClass($type, $args) { switch ($type) { case 'viewAction': $a = new ActionController($args); $a->init(); return $a; case 'viewSomethingElse': $p = new SomethingElseController($args); $p->init(); return $p; default: throw new ActionNotFoundException('Could not find requested Action'); } } } // client code try { $class = ControllerFactory::getClass($this->rq->action, $this->rq->getParams()); $output = $class->generate(); if ($output == NULL) //do something ; echo $output; } catch (ActionNotFoundException) { //generate some error } ?> [1]: http://en.wikipedia.org/wiki/Abstract_Factory
-
Where would it normally call viewAction() ? If you could post that code, I'll help
-
Great use of the context! Looks like you have a bit more abstraction to do in the viewAction() method. I have prototyped my approach below. The idea is, generate() should be moved to the Controller object, and this way you 'enforce' (via abstract functions in Controller) the use of: afterLoad(), afterRender(), and viewAction(). This is all choice of style, of course, but I like to be as strict as possible to ensure everything is implemented that should be. <?php class MyPageController extends Controller { function init() { $this->loadPlugin('nav'); $this->context->setRequest($this->rq); } function afterLoad() { $page = Page::loadByRequest($this->context->getRequest()); // load any plugins attached to the page (as set up in the database) $this->loadPlugins($page->getPlugins()); $this->context->setParams($page); $this->event('afterLoad'); } function afterRender() { $this->event('afterRender'); $out = $this->context->getOutput(); return $out; } function viewAction() { $tpl = new Template(); $tpl->setAll($this->context->getParams($page)); $tpl->setOutput($tpl->render('page.tpl')); } function generate() { //cant think of a better name right now $this->afterLoad(); $this->viewAction(); //call it here $output = $this->afterRender(); } } ?> Does this make sense?