Nature of Zope...

[Cameron Laird]

In article <c12bhs$1bvfgs$1 at ID-111250.news.uni-berlin.de>,
Diez B. Roggisch <nospam-deets at web.de> wrote:
>Scott wrote:
			.
			.
			.
>> 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
			.
			.
			.
>> 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
			.
			.
			.
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.
-- 

Cameron Laird <claird at phaseit.net>
Business:  http://www.Phaseit.net