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 )