[Zope] ZClasses vs Products (extending UserFolder)

[Jay, Dylan]

> -----Original Message-----
> From: Bjorn Stabell [mailto:bjorn@stabell.priv.no]
> Sent: Thursday, September 23, 1999 21:45
> To: zope@zope.org
> Subject: [Zope] ZClasses vs Products (extending UserFolder)
> 
> 
> Hi guys,
> 
> There are a lot of ways of extending Zope;  Pros and cons of Products,
> ZClasses, PythonMethods, ExternalMethods, just to my feeble knowledge.
> Maybe too many.  I'm not sure which ways are best in which cases.
> Anyone identified the pros and cons?
> 
> Specifically we have an application in mind.  It and our design
> decisions are described below:
> 
>         An HR application, letting users register their resume
>         and personalia, and while browsing job ads, just attach
>         a cover letter to apply (your resume is already in your
>         user record).
> 
>         The HR person should be able to post/unpost as well as
>         add/edit/delete job applications, as well as review
>         job applications (resume/personalia/cover letter).
> 
> From an OO perspective, it seems natural to extend UserFolders by just
> adding resume information to the User objects.  That way we'll inherit
> all the user registration code.  I guess the job ads should be
> implemented as objects in a folder.
> 
> The design decisions we're faced with are:
> 
> 1 UserFolder vs ZClasses
> 1a.     Should/can we easily extend the UserFolder as described above.
>         That would essentially mean making a new product called
>         ResumeUserFolder that would inherit from UserFolder and extend
>         the relevant functions.  Looking at the code for UserFolder,
>         however, it seems it's pretty hardcoded to support only the
>         properties it already supports.  If we add any properties, how
>         do we make sure they'll be persistent?

I think the ability to extend User objects is long overdue. I use UserDB and
then just have other tables in my database with all the user info and user
other sql queries to update/retrieve. This is not a very elegant solution
however. The OO way is to put the info into the user object as described
above. Basically a user should be a folder so that we can attach our own
ZClasses or what ever to a user. This should also work with sessions, ie
having storage in the user object that expires when the user logs off, or
after a period of inactivity.