Logic of creating new classes

[leatherback]

Hi,

I am working on setting up a site, for the first time using OOP. I am now a bit stuck on how to organize my classes, from a logics point of view. And after filling a few noteblock with different setups, thought I'd ask for some input..

What I have done:
I have a user class, which sets and gets user information such as role, name, email. But also runs the login
I have a class that produces forms (Using PFBC class)
I have a class that produces complete forms (JF_Forms Extends PFBC class)

In the last, I have set up a method that produces a loginbox. As I was working on it, it seemed like a good idea to link that with the user class: $user->LogIn: If the user is logged in, return a div stating user logged in; If the user cannot be logged in, return the form. However, now I realize that what I am building in the JF_Forms really is coming together as a full user authentication system.

Advice I am looking for
How would you structure this, what makes sense on the long run?
- Create a separate authentication class to log in, log out, create new user, edit users ($auth->user->DisableAccount() ).
- Should this class be an extension of user class, or should user be an extension of authentication?
- Should user & authentication be the same class (e.g. $user->Authenticate(), &user->New(), $user-> GetStatus()?

Hope you can help me with some ideas of how you wouold organize this.

[johanafm]

To me it would make sense to keep authentication at two levels. Controller which handles decision based on the results of authentication, while the actual implementation of authenticating the user would be in the User class.

As for linking the loginform with the user class, it sounds as if you go about it backwards. Let your controller ask the user class if the current session belongs to an authenticated user
- If it is, display whatever you wish: "Logged in" is one option, an ad is another… and you may wish to change what you use that area for later on. If you keep it separate, it's easy to do without affecting the login form.
- Otherwise display the login form.

[NogDog]

Yeah, I'd probably follow an MVC sort of pattern, essentially as johanafm describes, where your controller calls User::authenticate() when it's processing a login request, and would include logic in its constructor to validate that the user is logged in (if it's not an actual login form submission), and if not, call the login view, which might then use your form-builder class.