[Zope] Q: How are interactive web apps done?

[Michel Pelletier]

> -----Original Message-----
> From: Robb Shecter [mailto:shecter@darmstadt.gmd.de]
> Sent: Friday, January 21, 2000 3:08 PM
> To: zope@zope.org
> Subject: [Zope] Q: How are interactive web apps done?
> 
> 
> Hi,
> 
> I've done lots of servlet programming, and am finally checking Zope
> out.  It looks -very- interesting.  I'd like to use it but I'm still
> trying to figure out how I'd use Zope in all the ways I use servlets.
> 
> For example:
> 
> A typical servlet-based web app uses the servlet API to automatically
> generate a session object for each user.  (The API maintains the
> session by either a cookie or url rewriting.) 

Similar mechanisms are employed by current Zope Session Products.

> A small inheritance
> framework can easily be written to make some servlets do
> authentication in their base classes before allowing the user to
> continue. 

Zope begins to differ at this point, subtly.  Although there is nothing
stoping an inheritance relationship from participating in
authentication, and in some situations it does, in Zope, authentication
is primarily acomplished using Acquisition, which is a containment
relationship, not an inheritance relationship; meaning that instances
acquire authentication information (or mechanisms) from the environment
around them, aka, all the other instances in the system.

Inheritance ususaly takes a part in the definition of the genetic
material of the various authentication components, like Users, and 'User
Folders' (which are a bit poorly named, often they don't have any
'Folder' like interface).

> The subclasses then can get the session object, which is a
> hash table of objects.  One might then define a User java object that
> gets put into the session after authentication in the base class.  Now
> all of the user's attributes can be accessed by the servlets.
> 
> What is the equivalent way of doing things in Zope?  I've read about
> the various user permissions, but I'm not sure how that'd be used in a
> web application. 

I suspect Zope provides a much higher level framework than you're used
to.  For example, Zope automaticly inserts the current User object into
the web request.  Zope authentication mechanisms takes care of
authenticating the user and constructing the user object (of course, you
can create your own kind of user objects with Python code).  All you as
a content manager need to are create Roles that define the various
'groups' of your users, map a collection of permissions to each Role.
The actions a user are allowed to do are the union of all the
permissions of all their Roles.

You can get down and dirty, in Python.  You can completely discard
Zope's authentication and acquisition mechanisms and just use it's
object publishing ORB and some database modules to simulate what Java
Servlets give you.  This is much lower level than sitting in the Zope
managment interface.

> For example, how would an interactive banking
> application be implemented in Zope?
> Where would you define what info
> you want to save about each user? 

A relational database could be a good place if you used UserDB, which is
a Zope authenticator which works against RDBMs.  I'm assuming this would
be the method you are acustomed to with Servlets.

> How is the ODB used in a more
> database-like way, as opposed to a transparent web document source
> way?  Or, is there no difference?

There is a difference, and that's when all the research we're doing
right now starts to come into the discussion.  Whereas we and others
have come up with various hackish ways of working with dynamic user
schemas and how users look in various system contexts, no generic,
reusble mechanism has arisen because the problem is so hard, and I
suspect many of the Java platforms punt on a generic reusable mechanism
for the same reason.

For example, lets say you had a whole Suite of applications.  In this
environment, you want to maintain an identy accross all applications,
possible across multiple remote platforms.  Each application may want
each user object to look or act completely different.  Some applications
may consider the information they want to store about the user to be
confidential, while other applicaitons may have a lower security barrier
and authorization may be necessary for certain applications to allow
other applications access to the information they are concerned about in
the user.  Is there a central LDAPish user repository?  Both?  Do
individual applications keep localized user information?  How do users
synchronize possibly remote data?  How does user managment propegate
then to the distributed sources?  Does the user or the application
control the security between applications?  What if two applications
define two semantically identical bits of information but uses them in
wildly different ways?  What if you want to use legacy data (LDAP,
RDBM). etc...

We've been asking these questions for about a year now, and there's been
alot of head scratchin'.  What we're conceiving is a generic reusable
mechanism which addresses at least a few of these questions.

-Michel