January 2000 - Zope-Dev

Product standardization
by Martijn Faassen 13 Jan '00

13 Jan '00

Hi there, Many of us are developing products for Zope; either in pure python, pure ZClasses, or a combination. I'd like to make the products I'm making as 'Zope compliant' as possible; that is, they should use: * the standard Zope web interface * they should follow the standard Zope security conventions * when possible, they should implement a number other standard Zope interfaces, such as the properties interface and the object manager interface. The problem is that there is, as far as I know, no: * standard Zope web interface definition * standard Zope security conventions description * description of other standard Zope interfaces This is in part a documentation problem, but in part it's simply that the standards are probably undefined. The classes to inherit from are there in many cases, but I personally am in the dark concerning many issues. I just practice 'voodoo programming' where I just do stuff because I know I have to, but haven't a clue why. This is bad. So, could we start somekind of process in order to define what it means to be 'Zope compliant'. I have in mind: * standards documents * guidelines documents * motivations and explanations of the standards and guidelines. * tutorials and examples, such as products like the 'Boring' product that give working and compliant examples. * a peer review process; developers review each other's product code for standard compliance. Product users can do part of the reviewing as well. * Perhaps somekind of 'official approval stamp', that at least gives a clue that the product you're using is mature and complaint. Though we should watch out that this process wouldn't slow down development. Doing this could help us in many ways; we learn more about how to write a product, we learn more about how to write a *good* (secure, usable) product, and finally the development of Zope itself is helped by pointing out what people use/should use, and suggestions for future directions. Any comments, ideas? Regards, Martijn

2 1

RE: [Zope] Need help with evaluation issues of Zope
by Michel Pelletier 13 Jan '00

13 Jan '00

> -----Original Message----- > From: Peter.Rupp(a)ual.com [mailto:Peter.Rupp@ual.com] > Sent: Thursday, January 13, 2000 10:27 AM > To: Peter.Rupp(a)ual.com; michel(a)digicool.com > Cc: m.faassen(a)vet.uu.nl; zope-dev(a)zope.org > Subject: RE: [Zope] Need help with evaluation issues of Zope > > > ...happens on Solaris 2.7 (x86) within the same server. > BTW, have you identified the cause of the problem? Nope. > If the > problem is > not well understood...there's a chance that somebody could > conceivably > shutdown a site by restarting Zope in another (yet unknown) situation. This is probably a pretty easy bug to fix, it manifested itself in 2.1.1 and 2.1.2, so there won't be very many changes to look at to find the offending code. -Michel

1 0

RE: [Zope] Need help with evaluation issues of Zope
by Peter.Rupp＠ual.com 13 Jan '00

13 Jan '00

...happens on Solaris 2.7 (x86) within the same server. BTW, have you identified the cause of the problem? If the problem is not well understood...there's a chance that somebody could conceivably shutdown a site by restarting Zope in another (yet unknown) situation. -----Original Message----- From: michel(a)digicool.com Sent: Friday, January 07, 2000 2:26 PM To: michel(a)digicool.com; Rupp, Peter /whqkt Cc: m.faassen(a)vet.uu.nl; zope-dev(a)zope.org Subject: RE: [Zope] Need help with evaluation issues of Zope > -----Original Message----- > From: Peter.Rupp(a)ual.com [mailto:Peter.Rupp@ual.com] > Sent: Wednesday, January 05, 2000 2:47 PM > To: Peter.Rupp(a)ual.com; michel(a)digicool.com > Cc: m.faassen(a)vet.uu.nl > Subject: RE: [Zope] Need help with evaluation issues of Zope > This problem only apears to happen in one specific scenario. If you are using a browser that is running on the same machine as Zope and you are using RedHat 5.1 or 5.2. This problem doesn't occour for us when running both the browser and the server on RedHat 6+. We consider this then to be a pretty minor bug. Can either of you reproduce it in any other situation? -Michel > > > Ok, I can reproduce it now, we're looking into it. > > -Michel > >

1 0

ZFormulator review...
by Chris McDonough 13 Jan '00

13 Jan '00

I have taken a little bit of time to look at Martijn Faassen's ZFormulator product, and here are some findings: ZFormulator is a product that allows you to create self-validating HTML forms without hand-coding HTML form element constructs in DTML methods/documents. It allows you to use the Zope UI to set validation constraints on form input, to resize form elements, etc. Your role after creating the ZFormulator object in constructing a basic form is limited to calling the ZFormulatorForm object within DTML to get all the form elements, and setting a target action method for the form. - Martijn includes a .zexp file for demo purposes in the product which gets placed into the import directory upon untarring the product file. I think this is OK, but I wonder if anybody else has thoughts on the implications of placing stuff into directories other than the intended product directory within a product tarball? For instance, I would consider it bad form for a Product to expand something into the lib/python/OFS directory. Others might disagree. What about products just going right ahead and creating instances of their classes within the ZODB upon installation? Or products automatically importing demo .zexp (or equivalent) files into the App object? Bad form or no? - The owner and group of all Martij's product files are martijn/martijn. We had some talk lately about how untarring Products into the directory tree might lead to the unintended resetting of permissions. When I untarred the product, all the files were reset to owner/group mcdonc/mcdonc (my user login). I do not know under what circumstances tar creates files which have their permissions set to their build filesystem's permissions, or whether this is a behavior endemic to non GNUtar tar variants or what. I seemed to have no problem with gunzip ZFormulator.tgz, tar xvf ZFormulator.tar within the Zope homedir. Does anybody have any tips as to when tar decides to write files out with their original owner/group bits set instead of owner/group set to the untarring user? (yes, I am way too lazy to try to decode the WORST man page in history, the GNUtar manpage). - ZFormulator is a good example of how to create a folderish object within a Python product that constrains addable meta-types to certain other object types. In Martijn's product, he creates a base class named Form that inherits from ObjectManager, RoleManager, and SimpleItem. Since the Form base class inherits from ObjectManager, it is folderish. He overrides ObjectManager's all_meta_types method, and though I can't quite follow the logic as to how he populates the meta_types list within the class, it works, constraining the addable meta_types to those he chooses in a registration function (in this case, the individual field types, such as checkbox, textarea, etc.) I learned some tricks from this. One of the unintuitive things about constraining addable objects this way is that a ZFormulatorForm instance's Security tab still shows permission descriptions for aquired object types (such as Folders, etc). Not a really big deal, but sure to confuse some people. - The UI of ZFormulator is pretty standard, first you create a ZFormulatorForm object (this is an object that is represented by the Form class) by choosing it from the addable object dropdown. Then you click on that object to start messing with it. While you're messing around with it, you can add BasicFields, TextboxFields, CheckboxFields, and a bunch of other form widgets inside the Form. Each object type has its own icon (nice!) and each object type corresponds to a different object class (e.g. the TextareaField class, the CheckboxField class, etc.) You create the form widget object through the standard Zope management interface through the add dropdown. After you've done that, you navigate to the form object by clicking on it and redefining its properties. One thing that I'm sort of on the fence about is calling MessageDialog when properties for objects are changed. Martijn does this for most all changes within the UI. I sometimes find that this gets old after a while ("Yes, I know, thanks, I changed the object properties.") There isn't really much of a standard within Zope about calling MessageDialog (for example, SQL method Edit properties, when changed, don't call MessageDialog, they instead put a "last changed" blurb at the top of the management screen). Any comments? Additionally, what if a person were to create a Wizard-style interface for the addition of forms and form elements. Martijn has taken the approach of creating forms and form elements one-at-a-time via the Zope UI, but I could easily see a multipart form Wizard that would lead a user through the creation of a form and its elements without him or her knowing that he/she is instantiating things within the ZODB. Thoughts? - Martijn defines something like 27 classes that live within his product. Each of these classes, for the most part, is defined in a separate Python module within the product directory. I don't mind this at all. Anybody have anything to say about that? - I don't really want to get too deep into reviewing code here, so I'm just going to report errors and things that I think are a tiny bit askew (:-))... within a ZFormulator form, when adding a *second* instance of the same type of object (for example, a second TextareaField), I intermittently got an AttributeError, "None" object has no attributes coming from Field.py line 138 in _setSheet. Martijn, I would also give a little blurb as to what "Order" means within the Form elements add and edit UI as its not immediately obvious (I figured it out by reading the code). The View button between form elements produces inconsistent results (for example, a checkbox returns quoted HTML of the form element, while a textarea View shows the default value for the form element without any HTML). Also, the ListField input box for the list elements should probably be split into separate key/value fields instead of using the pipe as a separator between key and value within a textarea. I know SQL integration is a "work in progress", and doesn't actually do much yet. I'd almost be apt to leave it out of the product entirely as it's sort of hurts my brain to think about where my form values are coming from and going to in the context of using the product as a SQL conduit. Also, when navigating with the back-forward buttons within a browser between forms created using ZFormulator (even within the ZFormulator UI which "eats its own dogfood"), browser errors indicating that form responses have expired are common. I imagine this is a pretty tough one to avoid, and I haven't looked at the code closely enough to see why it happens with ZFormulator forms more often than with Zope HTMLFile-derived forms. Nice product Martijn! Well done! -- Chris McDonough Digital Creations, Inc. Zope - http://www.zope.org

4 6

RE: [Zope-dev] NotMail
by Johan Carlsson 13 Jan '00

13 Jan '00

Have you tried http://classic.zope.org:8080/? If not, I think I can dig it up from my "stash". //Johan > -----Original Message----- > From: zope-dev-admin(a)zope.org [mailto:zope-dev-admin@zope.org]On Behalf > Of Brian Takashi Hooper > Sent: den 13 januari 2000 10:46 > To: zope-dev(a)zope.org > Subject: [Zope-dev] NotMail > > > Hi there - > > Does anyone have a copy of NotMail lying around anywhere that they could > send me? I couldn't find it anymore on the Zope site... > > --Brian Hooper > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://lists.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** > (Related lists - > http://lists.zope.org/mailman/listinfo/zope-announce > http://lists.zope.org/mailman/listinfo/zope ) > _______________________________________________ Zope maillist - Zope(a)zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

1 0

Re: [Zope-dev] Authentication Patch
by Anthony Baxter 13 Jan '00

13 Jan '00

>>> "Stuart 'Zen' Bishop" wrote > On 12 Jan 2000, Esben Haabendal Soerensen wrote: > > > Evan> I got tired of dealing with the weird mechanics cookie-based > > Evan> logins have to deal with, where standard_html_error and > > Evan> tracebacks intrude on login intercepts. I came up with the > > Evan> following minor change, which works great for me, and might make > > Evan> GenericUserFolder's job easier, too. > > > Evan> What do you folks think? > > Evan - If it works like you say, it will mean I get to strip quite a bit > of ugly code out of GUF (or at least skip it if the Zope version number > is high enough) :-) I have no time atm though to check for sure... If it works as I think it should (from looking at the code) I too will be a verry happy bunny. The cookie login stuff is a leetle bit painful right now. We've had to jump over all sorts of hurdles with our hacked up copy of UserDb (well, it was UserDb, once. It's own mother wouldn't recognise it now :) I might give it a whirl on our non-public test site... Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

NotMail
by Brian Takashi Hooper 13 Jan '00

13 Jan '00

Hi there - Does anyone have a copy of NotMail lying around anywhere that they could send me? I couldn't find it anymore on the Zope site... --Brian Hooper

1 0

Re: [Zope-dev] Authentication Patch
by Esben Haabendal Soerensen 13 Jan '00

13 Jan '00

>>>>> "Evan" == Evan Simpson <evan(a)4-am.com> writes: Evan> I got tired of dealing with the weird mechanics cookie-based Evan> logins have to deal with, where standard_html_error and Evan> tracebacks intrude on login intercepts. I came up with the Evan> following minor change, which works great for me, and might make Evan> GenericUserFolder's job easier, too. Evan> In ZPublisher/HTTPRequest.py (or SiteAccess/ChangeBehaviors.py, Evan> if you use SiteAccess), change the lines: Evan> if user is None and roles != UNSPECIFIED_ROLES: Evan> response.unauthorized() to: if user is None and roles != Evan> UNSPECIFIED_ROLES: object = response.unauthorized Evan> Under normal circumstances, this has no effect, since Evan> 'response.unauthorized' will be called as soon as it is returned Evan> and will raise its exception as usual. Now however, we add a Evan> twist; When the cookie-based authenticator fails, it replaces Evan> 'response.unauthorized' with its 'login' document. If no Evan> higher-level authentication succeeds, the 'login' document is Evan> rendered normally. Since 'response' is re-created with each Evan> request, this modification has no effect beyond the current Evan> request. Evan> What do you folks think? Nice. I wouldn't mind seeing this go into next release of GUF. /bart -- caffeine low .... brain halted

2 1

Re: [Zope-dev] Factory pollution, scopes, zope hosting
by Tres Seaver 13 Jan '00

13 Jan '00

Lalo Martins <lalo(a)webcom.com> wrote: > > > > You have identified a real problem: it is a pain even for me in a site where I > > stage projects for different clients. One solution I had considered was to hack > > the factories to add a "global_visibility" flag to them, and to add a "factory > > proxy" object which would be dropped into the main Zope tree which would > > "surface" its factory to folders which acquired it. > > I thought of this one too, but it would be a major security > problem, because any of your customers with Manager role would > be able to add a ``factory proxy'' (or ``product proxy'') and > gain access to any product you have. Hmm, if the parent of a given user's root folder didn't expose the product, then the user wouldn't be able to either, perhaps? This would mean defaulting to all products available, and then turning them off as folder properties within each branch of the tree where they did not apply. > > I think a scope in the Factory (or perhaps the Product, you > have a good point) is the best sollution. The problem here is that the Product developer won't know how a site manager will want to use the product, in many cases -- or are you suggesting that the site manager might add items to the product folder? -- ========================================================= Tres Seaver tseaver(a)palladion.com 713-523-6582 Palladion Software http://www.palladion.com

2 1

not getting any backtrace on product import
by Stefan Kuzminski 13 Jan '00

13 Jan '00

I'm developing a new product and if there is any error ( syntax or whatever ) when I restart zope, it fails to print anything to let me know what went wrong. The product just isn't in the list of 'Available objects' in the management screen. Is there anyway to get this basic information..? thanks, Stefan Kuzminski

3 2