- Zope - Zope lists

MSWord Product...
by Magnus Heino 03 Nov '99

03 Nov '99

Hi. I have a bunch of MS Word 97 files that I want to put onto the web, into Zope. They can be converted to html, pdf or remain as doc, I dont really care. But I want to keep the layout, fonts etc. Saving as html in word doesnt do that very well. Is this possible somehow? I guess I want a catalogaware MSWord Product or something... but is there any way to provide a search interface? /Magnus Heino

6 6

Re: [Zope] Pointer-to-Object Properties
by Thomas B. Passin 03 Nov '99

03 Nov '99

From: Michael Bernstein <mbernstein(a)profitscape.net> Subject: Re: [Zope] Pointer-to-Object Properties >"Jay, Dylan" wrote: >> >> From: Thomas B. Passin [mailto:tpassin@mitretek.org] >> > >> > From: Toby Dickenson <tdickenson(a)geminidataloggers.com> >> > > >> > >I think the key observation here is that the additional information >> > >should be sufficient to identify the foreign object.... then the >> > >pointed-to object can be located by searching a Catalog. >> > > >> > >> > <stuff about SQL snipped> >> > >> > Also, you want to make keep the properties of the two types >> > of objects in the >> > many-to-many separate, to minimize coupling. In the case of >> > books, one way to >> > do this is to have a book maintain a list of its authors, and >> > each author to >> > maintain a list of its books. Then a book and an author only >> > need to know about >> > lists, not about authors and books. You can delete a list >> > item without deleting >> > its parent object. But now, if a parent object is deleted, >> > how do you make sure >> > all references to it in various lists are also deleted? Not >> > so easy! Back to >> > data integrity again. >> > >> > My point is really that object encapsulation and data >> > integrity are very >> > important, and it is easy to jump to a design that does not >> > provide for them. >> > If we're going to come up with a Zope-ish way let's make sure >> > its design is well >> > thought out in these areas. >> >> What you say is very true. Zope's absence of object referencing is a big >> omission and one that makes its OO claim somewhat tenuous (along with >> independent object identity but thats another issue). As you say doing >> referencing well is quite important. >> >> I think the current tendency to use a central ZCatalog is a good idea. Many >> to many references can be made by each object have a search criteria rather >> than a list. Then again this means the onus of inclusion is then on the >> referred to object rather than the referrer, however the deletion of either >> is ok as long as they unregister themselves from the catalog. The referred >> object will have to maintain a property/state that means it is included by >> the search. > >There is a problem with letting reffered-to objects manage their >incoming pointers. It means that a user that wants one of their objects >to point to another object must either have management priveleges on the >referred object or must get another user who does to do it for him. You >could add a special permission 'Add incoming pointer' could be added to >the object and made widely available, but the equivalent 'delete >incoming pointer' permission would still have to be tightly controlled >for obvious reasons. > >Hmm, I guess you could jigger things so that pointers to objects could >be managed by the owners of the referring object, even though they're >contained within the referred-to object, but that seems to be getting >needlessly baroque. > >Ha! I've got it! Proposal outline and handwaving follow: > >Create a bi-directional 'relationship' object (in two flavors; >one-to-many, and many-to-many) that both the referring AND the referred >object find through ZCatalog, and add a simple 'manage relationship' >permission to the referring and referred-to objects which grants them >access to it. Add a standard 'Relationships' tab to the management >interface. > >Relationship objects should not be contained in either the referring or >referred to objects, and perhaps should not be visible in the management >interface at all, except through the 'Relationships' tabs of objects. > >Define names and types of relationships in the ZClasses (maybe also >whether they are required or optional) as well as what Meta-types each >side of the relationship may be. > >Relationship enabled objects get 'manage relationships', 'view >relationships' and other associated permissions. > >In this way, objects can manage their relationships with other objects, >no user needs to have permissions on another users objects, properties >are not bent out of shape, and objects are not required to be >ObjectManagers. > >What do you guys think? Would this work? Can we also get traversal to >work through the 'alias' of a relationship name? >... >Michael Bernstein. Any kind of "list" or "catalog" or "bidirectional relationship object" should be an object of its own, not property of another object. If we stick with books and authors for the sake of a concrete example, we could 1) subclass book and author to add a reference to the catalog/relationship; or 2) let the catalog/relationship hold object references to its books and authors; or 3) let the catalog/relationship hold ids or names (as opposed to pointers or object references) to its books and authors; Now let's walk through some things we might like to do: A) Find out the authors of a given book 1) Ask the book to ask the catalog/relationship for its authors. 2) Find which catalog/relationship holds references to our book, then ask it for the corresponding authors. 3) FInd which catalog/relationship refers to the title or id of our book, then ask it for the corresponding authors. B) Add a new book to the list of books written by a particular author 1) Ask the author for its catalog/relationship of books, then tell the catalog/relationship to add the new book. 2) Find which catalog/relationship holds references to our author, then tell it to add the new book, linked to our author. 3) Find which catalog/relationship refers to the name or id of our author, and tell it to add the new name or id of the book, linked to the id or name of our author. We also need to think out whether a book should know its authors or an author should know its books. Now everyone else, help me out here! How do these scenarios relate to the permission and acquisition questions people have raised? For 2) and 3), how do we find the catalog/relationship in the first place to get started with the search? What other important and different scenarios need to be considered in the context of Zope? While we're at it, remember that an object might participate in numerous many-to-many relationships, which might rule out approach 1). Who would like to add their thoughts? Tom Passin

1 0

RE: [Zope] Pointer-to-Object Properties
by Brian Lloyd 03 Nov '99

03 Nov '99

> > It would be very beneficial to be able to 'point' to > > arbitrary objects as if they > > were sub objects, thus enabling one-to-many, many-to-one, and > > many-to-many > > relationships not constrained by the object heirarchy. > > > > Classic example: Many author objects, many book objects. > > Authors can have written > > several books, and certain books are collaborations with more > > than one author. It > > does not make sense for books to be contained within authors, > > or authors to be > > contained within books. > > > > While this simplistic scenario would allow us to either > > assign a list property > > with book titles to an author object, or a list property > > containing authors names > > to a book object, and live with the small amount of > > duplicated data I'd like to jump in and play devil's advocate for a moment. Note that this is not to necessarily refute the idea of pointer-to-obj properties, but more to start brainstorming and to help me get a better idea of the core problem here... Historically (or hysterically, as Jim would say) properties have had some basic traits that distinguish them from "subobjects": o They are generally "simple named values" of simple types. o Being simple types, they have either no or very limited behavior. o They have somewhat less of a sense of "identity" than full Zope objects. o They are not protected individually by the security machinery. So to summarize, properties were really designed to be supporting players rather than lead actors on the Zope stage - they should be thought of as metadata about an object more than as objects themselves in most cases. Looking at your books and authors example: > > Classic example: Many author objects, many book objects. > > Authors can have written several books, and certain books > > are collaborations with more than one author. It does not > > make sense for books to be contained within authors, or > > authors to be contained within books. The important thing in this example is the relationships, not the actual "place" of the objects. From a design perspective, the details of where the actual objects come from would be best hidden behind a set of interfaces anyway: # get a book object theBook=someMethodToGetABook() # get a list of author objects authors=theBook.getAuthors() for dude in authors: books=dude.getBooks() Having interfaces like these would give you an extensible architecture - books and authors could later come from a relational db or other source as the system grows. The core problem (it seems to me) is that Zope currently makes it hard to do the many-to-many relationships that are needed behind the scenes to implement these interfaces. Rather than do a lot of work extending the meaning and capabilities of properties, it seems to me that this could be handled if we had some sort of "reference" object. What if, for example, you could do a "copy" on an object then go to some other folder and do a "paste reference"? Assuming we had this, you could implement your interfaces over a Zope design where you have 2 Folders: "Books" contains Book objects and "Authors" contains Author objects. Both Book and Author objects would be ObjectManagers. Though a Book would never contain an _actual_ Author object directly, it could contain any number of _references_ to Author objects and vice versa. A Book object's getAuthors interface returns a list of Author objects - these could be obtained either by sorting through objectValues on the Book itself or, better yet, each Book may have a Folder "Authors" which it uses as a collection to store Author references. Such a design would (IMHO) have a number of advantages over going the property route. You would have much more flexibility in designing your system because you could traverse right through a book into its author, use acquisition and all the other benefits of the containment heirarchy. Perhaps most importantly, you would have fine-grained access control over the objects (properties would be all-or-nothing). While there would be some issues to work through in implementing reference objects, I suspect it would be much less than would be required to make properties meet your needs. There is also some amount of prior thought that has gone into this; the IETF WebDAV working group has been working on a "bindings" spec and they have a pretty decent object model that has come out of dealing with all of the issues of bindings/references. I've found that model to be a good place to start when thinking about bindings in Zope. Well, I've rambled on long enough - let me know if any of this has the ring of truth to you or if you think I'm totally missing the point... Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

4 3

(no subject)
by Joshi, Sunit 03 Nov '99

03 Nov '99

I did all the steps as noted in the How-To. However when I do http://rpa/cgi-bin/zope.pcgi I get this error : The resource you requested is temporarily unavailable - please try again missing publisher: E:\RPA\pcgi \pcgi_publisher.py thanks Sunit

1 0

more password problems?
by Daniel G. Rusch 03 Nov '99

03 Nov '99

Hey all, Does any know why neither of these work????? <dtml-call "REQUEST.set('name','TestVictim')"> <dtml-call "REQUEST.set('password','1')"> <dtml-call "REQUEST.set('confirm','1')"> <dtml-call "acl_users.manage_users(submit='Edit', REQUEST=REQUEST)"> <dtml-call "REQUEST.set('name','TestVictim')"> <dtml-call "REQUEST.set('password','1')"> <dtml-call "REQUEST.set('confirm','1')"> <dtml-call "acl_users.manage_users(submit='Change', REQUEST=REQUEST)"> DR

1 0

Re: [Zope] Zclasses derived from ZCatalog
by Tres Seaver 03 Nov '99

03 Nov '99

Tom Schwaller <tom.schwaller(a)linux-magazin.de> wrote: > http://www.zope.org/Members/Zen/tips/tip_ZCatalogInZClass > > shows nicely how to add a ZCatalog in a ContainerClass. > How does one implement the same functionality > when deriving a class A from ZCatalog: > > A(ZCatalog) -- B(CatalogAware) Check out my How-To, http://www.zope.org/Members/tseaver/inherit_ZCatalog > How to modify > <dtml-with "Catalog"> > <dtml-call "manage_addColumn('area',REQUEST,RESPONSE,URL1)"> ? Just call the method (of the ZCatalog-derived class): <dtml-call "manage_addColumn( 'area', REQUEST, RESPONSE, URL1 )"> > <dtml-with _catalog> > will not work. Right, attributes/methods starting with "_" are invisible to DTML. > Then I'd like to add B-Objects, > which are CatalogAware, to the A-Catalog. > > Right now I use only one instance of the A-class (Books) > and add the Books (type B) by writing: > > <dtml-with "Book.createInObjectManager(REQUEST['id'], REQUEST)"> > <dtml-call "propertysheets.buchdaten.manage_editProperties(REQUEST)"> > <dtml-call unindex_object> > <dtml-call "manage_editCataloger('Books', REQUEST)"> > <dtml-call reindex_object> > </dtml-with> > > which is nonsense, but works for one Book-Folder with a defined name. > > I like deriving from ZCatalog, so the users do not see > the Catalog (otherwise one could delete it) and the > ContainerClass (Books) is the catalog of its members (Book). > > Any hints? This is essentially what I am doing -- I just tried adding a DTMLMethod named "Catalog" to the ZCatalog-derived class, which just returns this() -- IT WORKS! -- ========================================================= Tres Seaver tseaver(a)palladion.com 713-523-6582 Palladion Software http://www.palladion.com

3 9

How to Delegate manage users permission to another role?
by Ping Lau 03 Nov '99

03 Nov '99

Hi, I have installed UserDB product & successfully created/changed/deleted users in DTML method. My goal is to create a role called Admin & let users with Admin role to create/change/delete other users. So I created Admin role & user Test assigned to this role. In the Security Tab of the folder containing the acl_user folder, I assigned Manage Users Permission to Admin. Next I login as Test & tried to add a new user. But Zope authorization window appeared. I tried to login as Test a couple times & Zope gave me the authorization error! What did I do wrong? Regards, Ping __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com

1 0

Zope.org down?
by Phil Harris 03 Nov '99

03 Nov '99

Seems that zope.org (yyy.zope.org) is down.

1 0

ZODB documentation
by Geoff Nordli 03 Nov '99

03 Nov '99

Can someone please direct me to some ZODB documentation. I have seen the How-to by Michel. thanks, Geoff Nordli

2 2

"collaborative Unix sysadmin" -- is Zope the right tool?
by Will Partain 03 Nov '99

03 Nov '99

Folks, I'm musing on an idea for "collaborative Unix system administration", and can't quite decide if Zope is the right tool for (part of) the job, or not... I throw myself on your collective wisdom! "Collaborative Unix sysadmin": better explain what I'm on about. Think about Unix sites with, say, 100 hosts, of more than one flavor (e.g. Linux+Solaris). A good sysadmin "adds value" to the site in all sorts of ways: configuring printers, installing packages other than the vendor-supplied ones, designing/implementing a backups strategy, writing Web pages to explain "where things are", etc. Problem #1 is that a huge fraction of this "added value" may reside only in the sysadmin's head, and, if the proverbial bus runs over him/her, then ... So, solution(s) #1 is to have *systematic* ways to record/implement the value added. Problem #2 is that the "added value" of a good sysadmin at Site A probably has many *similarities* to that at Site B. Without help, you have wheel reinvention on a grand scale. (NB: it won't be the *same* because, at the heart of sysadmin, you have Immovable Local Realities -- e.g. a different printer, different "security guidelines", different critical apps, etc.) So wouldn't it be great if the sysadmin at Site B could say, "I want to do my backups the same way as at Site A, except for <detail-1> and <detail-2>?" Essentially, I'm thinking of some kind of "inheritance" of Site A's "added value" by Site B's... Onwards... Building blocks I already envisage: (a) Encode basic *data* about a site -- hosts, users, support contracts, packages, how to power-down the mail server, checklist for setting up a new account, etc. -- as XML documents; and (b) encode basic site *behavior* for all these things as Python classes. I already know this kind of thing can be Very Useful. Where would that leave us? We now have tools for systematic recording (Problem 1) and, if thought through and written correctly, we could have some kind of "inheritance" (Problem 2). But we will soon have Problem #3: a site's pile of sysadmin "added value" will quickly become big/complex enough that it will be impenetrable to all but the original author -- and you're back to the run-over-by-a-bus problem. And we might want to think about Problem #4: how can collaborating sysadmins make available some of their "added value" so that others can "inherit" from it? So this is where Zope might come in. It's object-, Python-, and XML-friendly. By always presenting "added value" via a (search-friendly, index-friendly, ...) Zope-generated page, it becomes more accessible than just a big pile of *.xml and *.py files! From there, it is but a short step to *doing* sysadmin over the Web, perhaps remotely (scary, but...). And the "added value" you want to "inherit" from your friendly neighbor is now just a URL away... sounds good, no? But I have Zope Doubts (sorry :-). These include: * I definitely don't want through-Zope-only admin; I still want a command-line interface (CLI), and to be able to concoct ad-hoc scripts out of my .xml/.py pile. (Perhaps xml-rpc rides to the rescue? -- with it, we can suck on any Zopery from a CLI; but isn't that pretty heavy-handed for a simple task like "list-site-hosts"?) So, though I like the look of Zope transaction- and security-ish stuff, I'm not sure how I could make use of it in CLI land... * I would like what comes *out* of my .xml/.py pile to be XML also (as well as making the .py *do* stuff). To a big extent, my Zope stuff would be mere presentation of that XML. Reasonable? * There is so much Zope stuff I don't think I need; e.g. the "connect to SQL (or any other) database" stuff. * I would rather do my own configuration management (version control, etc.), with CVS/ClearCase/whatever. Partly, it's the politics in any CM-aware organization -- "sorry, I'm not using the normal CM tools around here; I've got this versions gizmo inside of Zope instead..." -- won't fly. But mostly, what if I want to say "roll back the Solaris boxes to the STABLE_1_3 release"? -- I feel confident that kind of stuff can be built on CVS/CC/whatever; I'm jumpy about Zope. * I'm not sure how/if Zope helps me w/ the "do across all hosts" parts of the sysadmin problem; e.g. "change /etc/exports on every NFS-serving host and run exportfs -a, or equivalent"... Do I put a Zopey server on every host and have them talk to each other? Or what? Recap: I need a tool to help (at least) with *presentation* of Unix sysadmin "added value", across collaborating mid-size installations. I like objects/Python/XML. How should Zope fit in the picture, if at all? Thanks, Will PS: Thanks to Jim Rowan and Jonathan Hogg for helping me organize these thoughts; sillinesses/brain-fades/etc mine.

3 2