-- 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.