in reply to Class Questions, OOP, and mod_perl -- HELP

It sounds to me like you are using OO code with a procedural model. For example, why would a User know how to handle cookies and deal with sessions? That would involve the User class knowing a bunch of stuff about your application and data storage that probably belong elsewhere, maybe in some kind of generic web framework code.

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.

  • Comment on Re: Class Questions, OOP, and mod_perl -- HELP

Replies are listed 'Best First'.
Re: Re: Class Questions, OOP, and mod_perl -- HELP
by nmerriweather (Friar) on Apr 29, 2004 at 17:30 UTC
    -- 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.
[reply]
[d/l]
      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.
[reply]
        I struggled with that.. but this user/class is just for mod_perl applications, and this seemed the easiest way to get at the specific data i needed into the user object (ie, the cookie/get/post input/session ids) for a while I had: 
        $r = apache request;
$session_and_form = new myPackage::session_and_form( \$r);
$user = new myPackage::User(\$session);
$page = new myPackage::Page(\$user)

        [download]
        but it seemed more right just sending the apache ref to the user, and have the user create internal refs to the session/form info it needs on init
        im new to mod_perl, as is very evident by my questions and approach. i'm bound to be doing manny things wrong... but its working.
[reply]
[d/l]

In Section Seekers of Perl Wisdom