CODEWITHSUNDEEP
phpclass
hvy
hvy

Reputation: 13

Handling validations inside a class

I'm trying to make a class that handles all errors form other classes and stores them into session.

It looks something like this:

class ErrorMessages {

    public function add {
        add message to _SESSION
    }

    public function display() {
        display _SESSION messages
    }

}

Which is the best way to integrate this with my other classes?

Let's say that I have the class User:

class User {
    function login() {
        if(everything is ok) {
            login
            add ok message to _SESSION  
        }
        else {
            add error to _SESSION
        }
    }
}

Should my User class extend ErrorMessages?

class User extends ErrorMessages {
      bla bla bla
}

Should I pass an ErrorMessages object into User class constructor?

$error = new ErrorMessages();

class User {
          function __construct($error) {
    }
}

Should I create an ErrorMessages obj inside every class I need it?

__

What is the best practice? I'm planning to use the ErrorMessages class inside every class that validates data and also use it to access the _SESSION messages from my frontend views.

Is there an other practice for handling validations?

Upvotes: 0

Views: 41

Answers (3)

max
max

Reputation: 102423

Best practice would be any solution that is flexible and secure enough for your application. Although the idea of storing validation errors in the session is questionable since its really just another form of global state and will complicate testing. There are many ways to skin a cat:

Rails (or more specifically ActiveRecord) handles validations in the model and stores errors in a hash (array in PHP) on the model. If validation fails you pass the model back to a view which renders the error message. A flash message which is stored in the session can be created which tells the user that the form was not valid.

Symfony2 takes a different approach where input params are bound to a FormBuilder class which handles validation and then can render the form.

Upvotes: 0

GouxLord
GouxLord

Reputation: 86

If you want a class that save elements to a session, you could use a class with a static method:

ErrorMessagesClass::storeInSession("$message");
ErrorMessagesClass::getMessages();

This is for what you need now. But depending on what you want in the future, they are other possibilities.

An errors model object with a data_mapper is good to stay adaptable. One object to manage the information, an other to store it.

Upvotes: 0

GolezTrol
GolezTrol

Reputation: 116190

I don't know if there is a single best practice here, but one good practice would be this:

  • Make a class or even an interface that can collect messages, like your ErrorMessages class.
  • Pass an instance of this class to your other classes.
  • Create a different class that can read the error messages and display them.

Reason for this is the single responsibility principe. The way you display the messages can differ, based on the situation. The way you collect them as well. So if you just have an abstract class or interface to define a collector, you can create an instance of any kind of collector you want and pass it to the class. That way, you can also use a LogFile collector, or a nullcollector if you don't want to collect errors at all.

The same goes for processing those errors. You might have a processor that shows the errors to the user and lets them correct the information, but you can also have one that just stores the errors in a file, or applies some AI correction on them.

All of that might not be relevant for now, but by keeping this structure, you can easily test your application and change it when you need to.

Extending from ErrorMessages is not a good idea. There will be a lot of basic functionality, and it's unmanagable to build a base class that contains all that information.

Upvotes: 1

Related Questions