Nature of Zope...

[Diez B. Roggisch]

Scott wrote:

> I'm interested in developing business apps, not just developing a
> content management site.  I'm wondering if Zope is right for me.  My
> programming exposure has been limited to simple PHP and not even from
> an OOP perspective, just simply dropping logic into HTML pages

> 
> I'm interested in building deployable apps with administration built
> into the app itself, not necessarily being administered from within
> Zope.  For example, I would create an app with its own administrator,
> its own staff, and its own technicians.  These being completely
> separate from the Zope management console.  (The users and managers of
> this app would be completely unaware of Zope).

ZOPE has hierarchical folders and can lookup users and their permissions in
userfolders - like this

/myapp
/myapp/UserFolder

Now whatever users are in /myapp/UserFolder only exist under /myapp. There
are UserFolder implementations that don't store themselves in ZODB, instead
they use e.g. ldap or mysql.

> These users would have certain tasks that they can do based on of
> course their ownership and security levels (these also being managed
> by the apps administrator and perspective).  Can these things be
> controlled outside of Zope?  If I did that would it break the core
> "point" of Zope?  Can and should I create a means to tie into the
> ZopeDB from within the app for users and perms or can I store this in
> a SQL database.  If I create a deployable package and distribute it,
> let it run, and simply restore my MySQL database in the event of a
> failure and redeploy my original "Zope Project" after a
> re-installation, could I be good to go?  Or must I store users,
> groups, perms, etc in the ZopeDB, or can I put users and their
> permissions in a SQL DB?

As mentioned above, you _can_ move it out of ZOPE - and as you can access
rdbms and ldap using sqlmethods or python-scripts with the neccessary
logic, you could add management areas that control it. But I think you are
right: you're sort of breaking the point of zope then. You lose a lot of
features - e.g. in ZODB you don't have to create relational-2-object
mappings, you simply add properties to objects and they get stored
automatically. 

I like ZOPE for your usual CMS app - information is in most cases
hierarchical, and thats very well reflected by ZODB. If you _have_
m:n-relations, a relational model might suit you better.  But I also just
stored arbitrary objects in ZODB - I don't remeber what is neccessary for
an python object to be storable, but AFAIK it wasn't more than inheriting
from a base class. Then you could store whole object graphs. However, you
_don't_ have sql or the like implemented on that - but sql also isn't to
good in dealing with strucures with arbitrary depths.

Others on this list recommend webware - I never looked at it myself, but
from what I know it looks more like the "classic" servlet-approach you find
in the JAVA-world. Maybe you can look into that?

> In order to use Zope, is it mandatory to know Python and OOP to build
> complex apps.  The reason for me wanting to use Zope is so I wouldn't
> have to learn another language, so that development could go fast, so
> that a person without extensive programming experience could build a
> logical business application.

At least python is mandatory - for all python webappservers. OOP is just a
paradigm one can follow, nobody is forced to. But I actually recommend
getting a grasp of it, as complex apps these days usually utilize it.

-- 
Regards,

Diez B. Roggisch