Nature of Zope...

P Gentry rdgentry1 at cablelynx.com
Fri Feb 20 01:35:02 CET 2004


mailslayer99 at yahoo.com (Scott) wrote in message news:<cd29768.0402180920.35b6aeab at posting.google.com>...
> Greetings everyone,
> 
> I have a couple general questions regarding the nature of Zope?
> 
> Also, please forgive me if this is not the proper forum for this type
> of question.  If so, please disregard.
> 
> I'm interested in developing business apps, not just developing a
> content management site.  ...

The CM site packages you see are add-on Zope Products, not central to
Zope itself.

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

Just the sort of person Zope was meant to help out, by providing
pre-built infrastructure and a means of taking advantage of it.
 
> 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).

Already done!  You're confusing the Zope Management Interface (ZMI)
which is designed to help manage Zope _installations/sites_ with the
CM management interface meant to manage the CM app.  You can
use/extend the facilities of Zope's ZMI to delegate the management of
the site or any fraction thereof, and your users don't have to use
Zope's web ZMI if you provide something else.  But _you_ can take
advantage of the underlying facilities.

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

Why?  Zope already provides _precisely_ this facility (and things like
proxy roles and acquisition that you'ld likely find _very_ useful).

> ... If I did that would it break the core
> "point" of Zope?  

Well, it won't break Zope as you seem determined to hide it as
completey as possible in every way possible.  And, "Yes, IMO it
ignores the whole point of Zope!"  It's as if you're saying you want
to use Zope precisely to ignore every feature that makes Zope a unique
solution.

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

Completely up to you and how much work you want to put into it.

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

Zope already provides backup/recovery mechanisms (of sorts) that you
can use to suit your situation no matter how you decide to to handle
authentication/authorization.  Most people use the facilities provided
by Zope/ZODB, but some db based apps use  the apps db storage.  It's
up to you.

> If Zope is well suited to do this, what is the next step?  I've
> installed and ran through the tutorial, but It doesn't get into the
> nitty gritty, I have no Python experience and no OOP experience.

What you propose will not be easy then.  You need to take advantage of
every pre-built facility possible -- regardless of product/language. 
Zope just happens to be designed with the goal of helping a "regular
joe" get a big jump start.  But there is no magic in Zope -- just
Python!  (Which some of us find just as good as magic)

> I plan on designing apps that have a lot of logic tied into it?  I
> have no idea where I can find out how to do certain things, for
> example, making database modifications based on certain criteria that
> a user does in the app, modifying the DB schema, creating the actual
> HTML forms based on SQL data, dropping in the logic behind the scenes.
>  The best way I've learned in the past is with tutorials, which
> explain things step by step and why.

The "core" of Zope provides just these facilities.  All the more
reason to select a software base with a community that will support
your efforts with aid and advice -- one that _you_ are comfortable
with.

> In order to use Zope, is it mandatory to know Python and OOP to build
> complex apps.  ...

Not to mince words, but Yes!

>... The reason for me wanting to use Zope is so I wouldn't
> have to learn another language, ...

What other language?  PHP?  Perl?  C?  Visual Basic?

> ... so that development could go fast, so
> that a person without extensive programming experience could build a
> logical business application.

Do you mean "end users"?  Again, this is what Zope's design goals are.

> If it helps, the three apps I'm working on are:
> 
> One, an asset management database, with admins making schema changes,
> and assigning groups and users to modify add certain pieces.

Sorta depends on the nature of the assets, doesn't it?  And the db
backend?  Experience is to _never_ let the well intentioned near the
schema and choose admins _very_ carfully.  You can use Zope's
facilities to help (a lot!) or ignore them and roll your own.

> And two others, one a change management system and the other a trouble
> ticket system, once again admins creating and managing users (staff
> and tech), staff members creating and managing tickets and assigning
> them to techs, and techs managing their assigned tickets.  Everything
> is queue based with ownership.

This sounds much like a work flow product.  Zope has several such
beasts available for your pleasure, some fairly "complete" and others
just a framework.

> Thanks so much for your help and time?

You might get a better sense of what your up against trying to do all
this by posting to the Zope mailing lists:
http://www.zope.org/Resources/MailingLists

OTOH
Why on earth are you wanting to use Zope to effectively duplicate the
infrastructure functionality that Zope was _designed_ to provide?  Any
number of other software packages will provide web publishing without
you having to replicate features (because they are not there) or
database access such as PHP provides.

Most every item you lisedt is _already_ provided by Zope -- some
almost "out-of-the-box".  Take a look at _all_ the products available
(literally 100s) that already provide pieces of what you want.

For someone whose "programming exposure has been limited to simple
PHP", the tasks you've set yourself are no easy thing to pull off --
even, in fact,  by those working full-time and with greater
experience/skills.  That's what Zope is for -- take advantage of the
work others have provided for you as well as the experince of a
community much more familiar with Zope and its innards than you.  They
are a quite helpful lot.

Only you can decide if Zope is a comfortable fit or not.  From things
you've said above, I don't think you have a very good idea of what
Zope provides -- either in the core product or by way of add-on
products.  The tutorial is notoriously incomplete and inadequate as a
means to get familiar with Zope.  Read the Zope book.  If that's too
much for you, then Zope is _not_ for you.

Whatever you decide, good luck,
prg
email above disabled

To the NG -- sorry for the long post.



More information about the Python-list mailing list