[Zope] ZClasses vs Products (extending UserFolder)
Martijn Pieters
mj@antraciet.nl
Thu, 23 Sep 1999 14:58:04 +0200
At 13:45 23/09/99 , Bjorn Stabell wrote:
>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?
Zope is not so much extended, as a framework for your web applications. You
use for its services. PythonMethods and ExternalMethods are just ways of
adding methods to objects.
You can go three ways with your application:
- A Product based on the default objects.
Use only when you application can be expressed in DTML only, and you
want to be able to distribute it to multiple other Zope installations with
some customization.
- A Product based on ZClasses.
Great for applications where you want to model content, where objects
mostly contain data, and all the functionality of those objects is geared
towards manipulation of that data.
- A Product written in Python.
Everything else. Interfaces with other systems, complex functionality,
new DTML tags, etc.
>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?
>
>1b. Should we perhaps use ZClasses and create our own Applicant,
> Application, and JobAd classes. Then, is it still easy to do
> all the logging in? Do we need PythonMethods?
>
>2 Login/Logout - provide user-friendly path for new user
> We're struggling to see how to best implement logging in. We
> don't like the browser's own authentication popup window
> asking you to fill in a username and password as most users
> will be scared by it, particularly since it doesn't say how to
> actually register. Still, I like that the authentication is
> externalized in this way instead of being spread throughout
> the site in the form of small login boxes. But, is it
> possible to have our own web page show up instead of the
> browser login box? Difference being our login page would have
> explanations on how to become a new user.
I'd definetly would go ZClasses here. Did you look at the Zope.org website?
It is based on the upcoming Portal Toolkit (Hey DC, what's the status?),
and logins are cookie based, and it uses an extended UserFolder to store
things like email address and full name.
You could either wait until the PTK is released, or look at UserDB, a
UserFolder that authenticates against a backend RDBMS, and supports
cookiebased authentication. It can be found at:
http://www.zope.org:8080/Download/Prereleases/UserDB
--
Martijn Pieters, Web Developer
| Antraciet http://www.antraciet.nl
| Tel: +31-35-7502100 Fax: +31-35-7502111
| mailto:mj@antraciet.nl http://www.antraciet.nl/~mj
| PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149
------------------------------------------