May 1999 - Zope-Dev - Zope lists

ZLDAPMethods propsal, input requested
by Chris Petrilli 14 May '99

14 May '99

Gang, In order to get some new projects kicked off, we are going to be commissioning a ZLDAPMethods product that will provide OO access to the LDAP database world. In order to get this as "right" as possible on the first round, attached you will find, a PDF overview of the architecture (VERY early, forgive me :-) here: http://www.zope.org/Projects/ZLDAPMethods/ZLDAPMethods.pdf Please let me know (either directly, or via the list) of any input you might have. Thanks, Chris -- | Christopher Petrilli Digital Creations | petrilli(a)digicool.com http://www.digicool.com

2 1

RE: [Zope-dev] ZLDAPMethods propsal, input requested
by Rob Page 14 May '99

14 May '99

> > That's because they don't exist :-) As is noted, at some > point we will > create new tags to deal with LDAP, but we're trying not to polute the > name space too badly, and looking at genericising the existing tags. > Until then, #var is all you get :-) > For a little more commentary... :^) This is a place where we can *really* make some innovations. Chris showed me the rather lisp-ish syntax known as LDAP Search Filters -- basically you type 23 open parentheses, some search terms and then 23 closing parens. :^) . For those of you familiar with the totally cool  and  tags there seems to be an interesting correlation between dynamic SQL commands and dynamic LDAP Search Filters (i.e., dynamic LDAP queries). IMHO, time will produce more and more directory- enabled/based applications and a good well-thought implementation of ZLDAP Objects will help a lot. Thanks for everyone for your comments and suggestions -- keep 'em coming!!!! --Rob

1 0

ANNOUNCE: COMObject 1.0.1
by Amos Latteier 13 May '99

13 May '99

Hello: I'm happy to announce a new unsupported Zope Product, COMObject. I quickly hacked together this Product to demonstrate how COM can be used with Zope. http://www.zope.org/Download/Prereleases/COMObject Here's an example from the README.txt which gives the flavor of what you can do with this Product: Suppose you have a COM Object named 'word' whose COM Object Dispatch Name is 'Word.Application' You can use this COM Object like so:  <br>  COMObject requires: * Zope 1.11.0pr1 or later (running on win32) * Python Windows extensions * Some understanding of using COM from Python See the README.txt for more information. If you haven't used COM from Python before, then this Product is not for you. This Product is *not supported*. It is simply a proof of concept showing one way to use COM and Zope together. I'm happy to accept patches, and answer questions as time permits, but maintaining this Product is definitely a very low priority. If someone who knows COM well would like to take over this Product (or even just take it as an example, and rewrite the darned thing) I'd be quite happy to cede ownership of it, hint hint ;-) Right now the Product is fairly limited, it's just basically sugar for win32com.client.Dispatch(). I have ideas about how to evolve it, for example, COM Method objects could be added to make access to an object's methods easier and perhaps to wrap results like SQL Methods do. This could also provide finer grained security... Let me know if you find it useful. And don't forget to have fun! -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com

1 0

RE: [Zope-dev] ZLDAPMethods propsal, input requested
by Chris Petrilli 13 May '99

13 May '99

> [Discussion of over-riding the binding info] I don't think this is consistent with the model used for ZSQLMethods, and would just increase the confusion. We can re-examine the need for this when there's an exact product that needs some other behaviour. You could of course then bind at a lower layer and not use THIS abstraction. > [Access to lower-level controls] These can definately be added as necessary, but I fear that too many knobs will make for bizarre performance problems. Having worked with LDAP for the past couple years in pretty heavy usage environments, I find that programmers often create MORE problems by twiddling the knobs, and it's better for the application to choose more sane defaults. > * It seems to me the document spends a lot of time talking about LDAP > search filters, but not how to fill in parameters, which > would be like ZSQL > docs talking about SQL syntax, but not explaining how to put > in #sqlvar tags. That's because they don't exist :-) As is noted, at some point we will create new tags to deal with LDAP, but we're trying not to polute the name space too badly, and looking at genericising the existing tags. Until then, #var is all you get :-) > [LDAP over SSL] I forget not everyone uses this since my pervious employer wrote the spec for it. This is mandetory for future use with PKI which is one of the reasons this is being written. At that point, bindDN information is replaced by X.509 certs. This will be non-functional in the initial release. > * The subject of multi-valued attributes appears to have been > completely > overlooked, as well as delete and modify-rdn operations. I > realize these > may all be outside the scope of your current project, but it > might be good > to explicitly list what things are out-of-scope. I will add these as "out of scope" right now. Thanks for the input. Chris -- | Christopher Petrilli Digital Creations | petrilli(a)digicool.com http://www.digicool.com

1 0

Re: [Zope-dev] ZLDAPMethods propsal, input requested
by Phillip J. Eby 13 May '99

13 May '99

At 02:46 PM 5/13/99 -0400, Chris Petrilli wrote: >Gang, > >In order to get some new projects kicked off, we are going to be >commissioning a ZLDAPMethods product that will provide OO access to the >LDAP database world. In order to get this as "right" as possible on the >first round, attached you will find, a PDF overview of the architecture >(VERY early, forgive me :-) here: > > http://www.zope.org/Projects/ZLDAPMethods/ZLDAPMethods.pdf > >Please let me know (either directly, or via the list) of any input you >might have. > It would be nice for a ZLDAPMethod to be able to override the default binding name and password, using parameters to the LDAPMethod. This would be useful for applications which must modify data in the LDAP server, but wish to use the LDAP server's security rules to determine whether the current user can perform the modification(s). It would also be useful for performing authentication when the Zope server is not allowed a login ID of its own on the LDAP server, but must use BIND operations to validate users. Granted, this is more relevant to an LDAPUserFolder type object. Another "nice to have" would be caching control, and access to the various other connection-oriented parameters which ldapmodule and most LDAP SDK's usually provide. In particular, the ability to specify when and whether LDAP aliases will be dereferenced. Some other notes, in no particular order... * It seems to me the document spends a lot of time talking about LDAP search filters, but not how to fill in parameters, which would be like ZSQL docs talking about SQL syntax, but not explaining how to put in #sqlvar tags. * LDAP is described as a connectionless protocol. It isn't. CLDAP is a variant protocol which provides only limited functionality compared to the full protocol. * I notice there is a reference to LDAP over SSL - does this mean you will be developing your own extension module for this instead of using the (OpenLDAP-based) ldapmodule? AFAIK, OpenLDAP and ldapmodule do not support SSL at the present time. * The subject of multi-valued attributes appears to have been completely overlooked, as well as delete and modify-rdn operations. I realize these may all be outside the scope of your current project, but it might be good to explicitly list what things are out-of-scope. * There are some miscellaneous DTML errors; for example:  Should be  And so on. By the way, I've been actively hacking the contributed ZLDAP product to do things like automatically re-connect the connection object upon errors, make the returned results Acquisition.Implicit so they can have methods wrapped around them, etc., and I was looking at adding some more features to do some of the above. If you guys are making a standard product for this sometime soon, I'd be happy to help with testing or even coding additional features. Let me know.

1 0

RE: Object references
by Jason Spisak 12 May '99

12 May '99

Robert, <opinion> I was tossing that same problem around before I said yes to the Catalog and ZClasses. I went with the them because the structure I have is mostly Hirearchicle in nature. I do however have two objects that store a referring object's id as a property. I have submission objects that contain a reference to a person object that was sent. I do a DTML _.getattr(_.getitem()) call to get the piece of the person object I want to grab in reference to that submission, or a (off the top of my head untested )      and that renders the actual document stored in the person property.(I have gloablly unique id's for ZClass instances) That's all fine and good, it can be done, but when you delete the object stored in that property, Zope will not be able to find it, true, and ugly. I thought of two ways to check that effect a) write DTML to display only if the id is valid b) write a method that takes place when you delete a ZClass instance that does a quick Catalog search and update that replaces it with whatever value you want. Even ORACLE 8 has to clean up after itself in this way if you use its new REF sql construct. But they wrote it so you have to pay for it and don't even know what it does. Funny thing is that if you are keeping around old copies of something that refers to objects that no longer exsist, the instance itself no longer has to be dynamic, it is history. So preserving thier dynamic nature does nothing for you. The Order Class is only applicable when it's dynamic, and a subclass or whatever, more accurately depicts the order after the purchase has cleared and can't change anymore. After paid, then the order ceases to be an Dynamic Order and becomes a Static Order. Static orders could just be a DTML method with some proerties. It's history. You're only keeping it around so that you can say who bought what when, etc... This is all just the way that I did things here, and it probably only applies to me, but I thought I'd give my thoughts such as they are. To be honest, I'd contort my ususal way of doing things just to have the speed, ease of use, flexibility, and extendability the Zope offers. I weighed all the possibilities on the scale of Web Applications and Zope came out the winner. Everyone has thier own scales. </long, way too long, opinion>;-) All my best, -- Jason Spisak webmaster(a)mtear.com

1 0

Re: [Zope] DTML methods vs. documents for index_html
by Jimmie Houchin 12 May '99

12 May '99

Hello, I wrote this message last week. I probably should have posted it to this, the zope-dev list instead of the zope list. In the Zope 1.11pr1 Windows95, binary install that I use/play with at work I made the change I list at the end of my message and it worked great to change the default behaviour of adding a default interface to a folder from creating a DTMLDocument to creating a DTMLMethod. Is my understanding in line with the rest of the community? Jimmie Houchin At 01:37 PM 5/5/99 -0500, Jimmie Houchin wrote: >Hello, > >I am working on my understanding on DTML methods and documents. >I've read previous posts and the ZDP FAQ and this is my understanding. >Feel free to enlighten my understanding. :) > >>From Michel in the thread, DTML Method vs Document >At 05:24 PM 3/3/99 -0500, Michel Pelletier <michel(a)digicool.com> wrote: >> >>This is my take on the situation. As far as I can tell this is pretty >>deep voodoo. >> >><Snip>... >> >>Both DTML Documents and DTML Methods can hold DTML and content. The >>difference is subtle. DTML Methods would be used when the answer to the >>question 'Am I showing some other objects content through me?' is Yes. >>DTML Documents should be used when the answer to the question 'Am I the >>content I want to display?' is Yes. DTML Methods have the advantage >>that they don't have any properties, and their perspective of aquisition >>is from their containing folders point of view. DTML Documents have >>properties which may interfere with aquisition you'd want to do, and >>aquisition is from their own point of view, which may not be what you >>want. > >By the way I find this to be a most excellent explanation. > >For the default public interface of a folder, it seems to me that it should >be a DTMLMethod. In browsing a default install of Zope 1.11.0pr1 the top >level folder's default interface is a DTMLMethod, likewise the QuickStart. > >When you add a Folder and check Create Public Interface and then click add >it adds a DTMLDocument not DTMLMethod. Is this the currently desired >effect? Or is this legacy functionality due to pre 1.10.x and DTMLMethods? > >If so would the following be a reasonable way to handle the current >philosophy? >(According to my understanding.) > >In /python/OFS/Folder.py I see line 119 which says: > > if createPublic: i.manage_addDTMLDocument(id='index_html',title='') > >To change the default is all I need to do is change it to? > > if createPublic: i.manage_addDTMLMethod(id='index_html',title='') > >Thanks, > >Jimmie Houchin

1 0

bug in handling of :tokens:int
by Service Informatique CHSR 12 May '99

12 May '99

Hello, Zope 1.1.0.2 using :tokens:int (to have "1 2 3" --> [1, 2, 3]) doesn't work Included is a patch against lib/python/ZPublisher/Converters.py Basically, field2whatever recursively calls field2whatever if its argument is a list or a sequence, where 'whatever' is int, float, or long Also, field2date appears twice in this file. The patch also corrects this. I don't know if someone already discovered the problem (don't have access to CVS), but in case it can help someone... Also, my timezone tzname is 'RET' (I live in Reunion Island). It is GMT+4 I don't know the official name for my timezone, but i someone could add this to lib/python/DateTime/DateTime.py Regards, Jephte CLAIN Service Informatique CHSR

1 0

Re: [Zope-dev] ACTION: COMExternalMethod and Python for Windows Book
by Rik Hoekstra 12 May '99

12 May '99

-----Original Message----- > From: zope-dev-admin(a)zope.org [mailto:zope-dev-admin@zope.org]On Behalf > Of Phil Harris > Sent: woensdag 12 mei 1999 9:39 > To: zope-dev(a)zope.org; Amos Latteier > Subject: Re: [Zope-dev] ACTION: COMExternalMethod and Python for Windows > book > > > Hi Amos, > > I wonder if you could send that file again as the original was corrupt (at > least for me). > Ah, I thought it was me. It was corrupt here as well. Please make it available once again, so we can have a look at it. (and then decide whether we are able to make contributions) Rik Hoekstra

1 0

Re: [Zope-dev] ACTION: COMExternalMethod and Python for Windows book
by Amos Latteier 12 May '99

12 May '99

At 09:20 AM 5/7/99 -0400, Paul Everitt wrote: > >OK, I've gotten a few replies by now. I'm attaching a file that >contains the outdated COMExternalMethod code. > >Some action items: > >1) Clean it up to make sure it actuall works with the latest Zope and >the latest Python COM stuff. > >2) For extra credit, improve the code and make it do more/better. > >3) For extra credit, actually document it (put some text on the add >form, create a useful README, etc.) > >4) Help out with the words to go with the book. Below is what Amos >started with. ... Hi Guys, I just wanted to check to see if anyone is serious about working on this project. Paul is really busy, and so he's passed the baton on to me on this one. To reiterate, what we're looking for is someone to help resuscitate COMExternalMethod, and someone to help write the Zope bit for the forthcoming Python and Windows O'Reilly book. Your payment would mostly consist of fame and goodwill ;-) Please, let me know if you'd like to be a part of this project. And if you've already made an arrangement with Paul, I apologize for making you repeat yourself, but please let me know too. Thanks a lot. -Amos

2 1