• You can rebless the object into one of the subclasses, once you actually know which class the object should be of. There's no technological reason why you shouldn't, but many people frown on it because:
  1. This is nowhere near pure OO
  2. If not done right, it's damn-near unmaintainable
• You can have a Registration object that you pass to the $user object. The $user object would then delegate to the appropriate object, as needed and if available. So, when you know, you'd hand a registration object to some set of standard delegates. You'd ask every $user to register, but only some would actually be able to.
• You can rewrite your code so that you only create a $user when you actually know what's going on.
• You can continue down the path you're on, which is perfectly fine (and probably the most common).

Just a thought - you using CGI::Application or some similar framework? Those can save a lot of time and headaches ...

-- rebless the object
Sounds messy.

-- You can have a Registration object that you pass to the $user object.
This sounds good.

-- You can rewrite your code so that you only create a $user when you actually know what's going on.
I'm a bit partial to what i've got right now -- creatng the user, then managing their session/state based on form/cookie data, then doing whatever things they desire. unfortunately, that means i don't know what kind of user i have until i do $user->what_am_i()

-- You can continue down the path you're on, which is perfectly fine (and probably the most common)
Glad to know i'm not crazy!


I'm going to opt for the Registration Object. I really want to keep the pages themselves abstracted from the functions, so I can reuse this and subclass for new projects. I hadn't seen CGI::Application -- i've looked at a dozen frameworks, and gave up out of frustration, deciding to roll my own -- so right now i'm building 1 framework and 3 sites that use it.

My frustration in perl is that there are so many modules and frameworks that the signal:noise ratio is pretty low in terms of what you need/dont, and well coded / not. Too many options isn't always a good thing!

I spent 3 days making a Session object to handle Session cookies (provided by Apache::Cookie), AutoLogin Cookies (provided by Apache::Cookie) and session ids from Get/Post data -- because I couldn't find anything that did all three -- usually just sets of two. Then, looking into my registration class issue, i find a Session Manager object that does exactly what i want PLUS session IDS tacked into the path. Ugh.

A more standard design for the kind of thing you seem to be doing would be to have your User class just model a user and the things that a user can do, with a separate class like UserManager that performs operations involving User objects. Registering a User should not change the basic identity of the User.

It sounds like you are kind of heading this way already. I would encourage to continue with that, and to read some stuff about OO modeling. In general, things that a user can do belong in the User class, while things your application can do with a user belong somewhere else.

-- In general, things that a user can do belong in the User class, while things your application can do with a user belong somewhere else.

Yeah, thats what I'm going for. I just saw the cookie/session stuff to more of a user type thing than an application -- because the cookie/session stuff would affect the loggedIn/virgin status of the user.

I do have a bit of a procedural model in here (psuedocode below, as I'm at work and the real code is at home):

$r = apache registry;
$user = new myPackage::User(\$r);
$page = new myPackage::Page(\$user)
$r->send_headers()
$r->print( $page->getContent  )
[download]

So i instantiate a new user, who contains various methods, variables, and refs to their particular get/post and session data

Then i instantiate a new page, which contains a ref to the user who requested that page. An internal subroutine decides which page to show based on the user's get/post data , checks whether the user has enough privileges to process that page, and returns the html representation.

That seems to work well for my needs -- splitting the logic behind a user and a page into separate trees.

I don't know anything about your application, but passing an Apache request object ($r) to your User class sets off all kinds of alarm bells. You usually want your data model classes to be totally independent of the environment they run in, e.g. you should be able to call your User class in a cron job that does some batch process on Users.

"So I created Register and Privileged subclasses..."

Hmmmm ... since that seems to be the only difference in users, registered and non, why not instead add an attribute to your user class? Just a simple boolean flag, is_registered should suffice. Now, i do, however, make seperate classes for "users" and "administrators" ... but then again, i also only allow "users" to access the files in a directory called /user -- whereas "admins" get full run of the board.

You might want to consider how Anonymous Monk is handled here. All users who come to this site are Anonymous Monks until they login. That is ... they are already a user, that user simply has less priviledge to do things, like post to the CB.

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

-- since that seems to be the only difference in users

it's not. there are different levels/types of users. I think 5 right now. Each has a different set of functions.