Registration Class Ideas

Hi all, I’m finding that I’m writing very similar code on a regular basis with user registration, signin, etc. So I’m thinking about writing a class that I could use on each projects to save a little time.

Just got no ideas what methods I would need, etc. If someone would be so kind to give a few ideas and maybe a skeleton structure of the class, that would be hugely helpful.

Batting aside the usual “just download a known framework and see how they do it” remarks.

Essentially, you go and look at two of your last aforementioned projects.

Isolate the code blocks that you spot that are very similar.

Compare them.

Isolate “that which changes” in each one.

Extract what remains, then create code that can be shared which can be de-coupled from “that which changes”.

Else, be brave, put your tin hat on and post examples of the two here if you want some discussion on it.

You may have to do some work, don’t clog up your examples with unnecessary html/css/js code.

In case that was too abstract, this is somewhat pseudo-ish of what I mean.


$config_project1 = array(
'db' => 'mysql',
'required' => array('name', 'username', 'password'),
);

$register = new Registrar( $config );

// somewhere else
echo $register->render('RegForm');

So that later, in another project on the same server you can do this:


// this has isolated "that which changes"
$config_project2 = array(
'db' => 'sqlite3',
'required' => array('user_name', 'pass_word'),
);

// reuse the same Registrar class "that which has stayed the same"

Hey dude, I have started work on a registration class, think it’s coming together, will post the class on here when it’s completed for ideas, changes, etc. Thanks for the pointers :slight_smile:

Great, post some code sooner than later now - and try and keep it to doing just one simple thing for starters.

Don’t fall into the trap of making a God Object (actually, go ahead, its the only way you’ll learn).

Hey Cups, apologies I have been away from my computer for the last couple of days. Please see my class below, this is only as far as I have got. Cheers dude :slight_smile:

<?php

class User {

	protected $db_table = "";
	protected $post_data = array();
	protected $required_feilds = array();
	protected $errors = array();
	
	//Initalize and clean up post array...
	function __construct($post_data){
		$this->post_data = array_map('trim', $post_data);
			
		return $this->post_data;	
	}

	public function error_checking($required_feilds){
	
		$this->required_feilds = $required_feilds;
		
		//Foreach to check each input value...
		foreach($this->post_data AS $field => $value):	
			if(in_array($field, $this->required_feilds) && empty($value)):
				array_push($this->errors, false);
			endif;
		endforeach;
		
		//Check errors array for any false values...
		if(in_array(false, $this->errors)):
			return false;
		//Else return true meaning no errors were found...
		else:
			return true;
		endif;
	
	}

}

?>

So far that is not a User it is an error checker, not even an error checker its an array checker.

Is User a “User”? No.

a User might need an array checker somewhere, or depend upon one but it certainly does not need to contain the code for one or become one.

Perhaps that is where you could start?

Given that you have to handle GET and POST arrays in probably all of your projects, which could be passed 1 or more items that:

a) should just be dropped

  • and silently ignored, or
  • and verbosely added to an error log or something?
    b) should be allowed in by checking vs a white-list
  • should be filtered for absence of null
  • should be filtered vs known patterns (eg email, tel nos etc)

So perhaps an array cleaning class could have this kind of signature, as shown in this use case:


$white_list = array(
'name' = 'reqd|4' , // required min 4 chars
'email' = 'reqd|email' , // required must match an email pattern
);

$_POST['name'] = "Bert";
$_POST['email'] = "correct@emailaddress.org";
$_POST['submit'] = "Submit";

try{
$a = new ArrayCleaner($white_list);
$a->cleanThisSucker($_POST); // its FunkFriday, sorry...
} catch (){
// etc
}

$b = SaveNewUser($a->$getCleanedArray());

// So what should happen if it is passed this?

$_POST['name'] = "Bert";
$_POST['email'] = "bad#mailaddress.org";
$_POST['submit'] = "Submit";


Now, think about all the work that an Array Cleaner has to be able to handle? You may decide that that in turn could be broken up into smaller classes which that simply evokes and uses.

EmailValidator;
MinStringValidator;

I cannot be defensive about what I am suggesting, as I write it I can see chasms and holes opening up but I want it to serve to pique your interest if I can, and then strongly suggest to you that you go out and read some really good OOP books.

I posted this example to simply hint to you that there are quite a lot of OOP Principles you need to grasp and put into practice.

Here is the one of the main rules you are breaking. There are many more, hopefully someone else will pipe up:

Single Responsibility - objects should only do one single thing, but do it really well.

That one thing can be to orchestrate 1 or more other classes to do their one thing, in other words you can delegate responsibility to fire off a chain of events.

If you think an ArrayCleaner could be a good thing to have, then go on and get that coded up if you wish… don’t do too much coding just try and stub the methods, and ask for comments (be prepared to leave your ego at the door though).

Here is a short list of slides which will hopefully get you going and further prod you to learn more (hint: many books you could consider may not use PHP in their examples)

I will also say this on behalf of the many who think that learning OOP may well be overkill. You could have a far easier time by extracting parts of you code into plain functions first. put those functions into files and include them as they are needed. You will still run into a lot of the main OOP rules, DRY and so on, but you will get results out faster. It will all be good because working that way also starts to separate out responsibilities in your code, and that is always a good thing.