[Zope] ZClasses vs Products (extending UserFolder)

[Phil Harris]

Couldn't you simulate this already.

If you use the advanced tab on the UserDB sql queries you could 'add value'
to the queries by making them use other queries to select/insert other data
based on an external class.

Well it made sense to me ;)

Phil
phil@philh.org


-----Original Message-----
From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Jay,
Dylan
Sent: Friday, September 24, 1999 2:27 AM
To: 'Bjorn Stabell'; zope@zope.org
Subject: RE: [Zope] ZClasses vs Products (extending UserFolder)


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

_______________________________________________
Zope maillist  -  Zope@zope.org
http://www.zope.org/mailman/listinfo/zope

(To receive general Zope announcements, see:
http://www.zope.org/mailman/listinfo/zope-announce

For developer-specific issues, zope-dev@zope.org -
http://www.zope.org/mailman/listinfo/zope-dev )