Nature of Zope...

[Scott]

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

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?

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.

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.

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.

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.

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.

Thanks so much for your help and time…

 

[Diez B. Roggisch]

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.

 

[Cameron Laird]

Scott wrote: .
.
. .
.
.

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

.
.
.
I believe it's also worth emphasizing that it's possible to
use Zope's security (and proxies and ownership and ...)
withOUT your end-users ever seeing the Zope management
screens. Zope's all programmable. You can make your own
computations about who has permissions to do what, and your
own displays for updating security roles. While I *think*
Scott knows this, it's merits being explicit.

 

[P Gentry]

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.