- Zope-Dev - Zope lists

Re: [Zope] Import from Zope-1 to Zope-2
by Michel Pelletier 09 Sep '99

09 Sep '99

"Jay, Dylan" wrote: > > > -----Original Message----- > > From: anders.brun(a)abc.se [mailto:anders.brun@abc.se] > > Sent: Tuesday, September 07, 1999 05:24 > > To: zope(a)zope.org > > Subject: [Zope] Import from Zope-1 to Zope-2 > > > > > > Hi, > > > > I have a site built in Zope version 1.10.2 (binary release, > > python 1.5.1, linux2-x86). Now I´d like to export everything > > into Zope-2. It doesn´t work using export/import ... Have > > anyone experiensed anything similar? > > The answer is to use the upgrade utility in the utilities dir but on a > related note heres another idea I had. How about a product that can mount > one zope ODB into another. Using XML-RPC or something to connect the two > sites togeather over the internet. It may not be fast enough for using that > way but at least it would be really easy for transfering data between zope > odb's. We are entertaining the possibility of putting ZPublisher.Client into the _ DTML Namespace. I am primarily championing the idea. 'Client' offers many cool uses. 'Client.Function' will call a remote 'Zope Method' which marshals simple types around (int, list, tuple etc.) and act as Zope oriented RPC. 'Client.call' is a convienent wrapper around 'Client.Function'. These both have the upshot of working with any URL, turning non 'object content' into file Message objects and return them in a list. Even cooler, 'Client.Object' will create surrogate objects of remote Zope objects. If you have a DTML Document on machine A, then Machine B could say: <dtml-with "_.Client.Object('http://A/YourDocument')"> <dtml-var id> </dtml-with> and print 'YourDocument'. You can pass autentication information in to all of the calls to access restricted object. The downside is that this is the first method to be introduced into DTML namespace that may block forever (not so say that in the past other methods didn't block because of bugs ;). The reason why there are no blocking methods is because Zope used to be single threaded. If the above Client calls took a minute to return, then your entire system hung for a minute. Granted, the OS should eventually time out the socket. Now that Zope is multi threaded, this isn't much of an issue, but it should be understood that these calls block and will take time and maybe hang individual threads for a while. Another no-no would be for an object to call Client on itself. I suspect this would cause some sort of StackOverflow exception. I'm not sure how well Zope would take that kind of behavior. The proposal mearly needs to pass the scrutiny of our security dictator. It is a trivial change to the code. I think it's pretty safe since no holes are introduced in the server, just client functionality, and any security bugs this could reveal could be just as easily exploited in python with Client or urllib (immagine, hacking machines in DTML!! It *is* a real language ;). -Michel

2 1

RE: [Zope] Re: Two newbie questions + Zope patch
by Michel Pelletier 09 Sep '99

09 Sep '99

> -----Original Message----- > From: Evan Simpson [mailto:evan@tokenexchange.com] > Sent: Thursday, September 09, 1999 9:39 AM > To: Michel Pelletier; Martijn Pieters > Cc: zope-dev(a)zope.org; zope(a)zope.org > > <dtml-var number/3/the_larch> Ok. > <dtml-with thingy><dtml-var "_[varwithstringpath]"></dtml-with> That's cool. > <dtml-var "_.getattr(eric(), 'half/a/bee')"> Ouch! I can see changing var to work with relative paths, but not getattr. You can try and convince me otherwise but I think _.getattr should work as much like the python getattr as possible (after all, it *is* the python getattr!). -Michel

2 1

Use Factories
by Jason Spisak 09 Sep '99

09 Sep '99

Zopists, I discovered a mapping that probably was meant to be turned on by default like the Add Permission, when you create a ZClass. Inside the Factory that is created by default when you adda ZClass, go under the define permissions tab. You have to map the "Use Factories" permission to the permission you want to apply to using that factory. It isn't enough just to map the "Permission" on the edit tab of the Factory to the "Add MyZClass" permission, you have to duplicate that under the "Define Permissions" tab. Unless you want only people with the Manager role to add those, then the default works. Just a heads up. Jason Spisak webmaster(a)mtear.com

2 2

Re: [Zope] Re: Two newbie questions + Zope patch
by Michel Pelletier 09 Sep '99

09 Sep '99

Michel Pelletier wrote: > I'm not sure what your getting at here, but if you want to resolve a > path to a URL try: > > <dtml-with "REQUEST.resolve_url((SCRIPT_NAME + '/path/to/object'))"> > blah > </dtml-with> > Before I shot my mouth off, I should have metioned that this ability comes with a catch. This sort of functionality was necesary for ZCatalog and WebDAV to resolve URLs into Zope objects, but the usage and semantics of path=object-traversal were never standardized. In addition, the solution to serve the needs of the application did not, unfortuatly, jive with ZopeFind and ZCatalog. Brian and I had a hard time expaining the nature of the problem at the team meeting today, so I hope this explains it to everybody. ZopeFind is a method that will start at a container and search for objects that meet certain criteria with the option to recursivly traverse subfolders. Anyone who has used the Find view in the managment interface will be familiar with this, the interface is just an input form to the ZopeFind method that does all the actual work. Zope find returns a list of (relative_path, unwrapped_object) pairs. The relative_path, is *relative to the container from which ZopeFind was executed in the context of*. 'unwrapped_object' is the acutal object, not including any acquisition wrappers, therefore 'object.absolute_url()' just returns the id of the object, because there is are no layers of acquisition wrappers to build the path from. This is not a problem in itself, the absolute url of the object can be built by '(URL1 + relative_path). A further complication however is added because of the way ZCatalog remembers objects. The ZCatalog.Catalog.Catalog class works on the basis of object and their unique identifiers. The unique identifier can be anything at all, it is just used a document id in the class inverted file index that ZCatalog.Catalog.Catalog uses. The ZCatalog.ZCatalog.ZCatalog class, which is the actual Zope objects, used a (jeez) ZCatalog.Catalog.Catalog object as its engine, what it uses as a 'unique identifier' is the absolute *path* of the object, which is identical to the absolute url without SCRIPT_NAME (ie http://machine:port) in front of it; like '/absolute/path/to/object'. It would make no sense to catalog the whole URL, because if you changed the name of the computer or moved the port, your catalogs would break. 'REQUEST.resolve_url(URL)' wants an absolute url beginning with http: (like absolute_url() is supposed to return). ZopeFind returns relative paths with no context, and ZCatalog wants absolute paths. The work arounds between these three systems are simple, but the problem is that there are three seperate APIs in Zope that work with URLs in different ways. Brian and I tackled this problem in ZCatalog immediatly before the final release. The problem was discovered when a bug was reported that ZCatalog did not return proper URLs of objects when the Catalog was not in the root folder. The solution was simple, use absolute URLs everywhere and strip SCRIPT_NAME off of URLs before cataloging them, and with friendly community support, we found this discrepancy. So until we work it out by coming up with a common standard and implimenting it in the 2.1 release, use REQUEST.resolve_url(), ZopeFind and the Catalog with caution. When you absolutly must do it, use it like ZCatalog does and make sure you pass it the resolve_url() the absolute_url() of a properly wrapped object, or that you prepend URL1 to a relative path, and strip SCRIPT_NAME from URLs before calling Catalog methods. -Michel > -Michel

2 1

Can't get ZClass baseclass to behave as DTML Method
by Martijn Faassen 09 Sep '99

09 Sep '99

Hi there again, Python and DTML Methods, one way or another they seem to be the theme for me today.. A couple of weeks ago I asked the same question (I encountered it in different circumstances). I'm trying to create a ZClass (deriving from a Python base class) that behaves like a DTML _method_. To this purpose, I tried to define this __call__: def __call__(self, client, REQUEST=None): "Call this ZClass as a DTML method." return self.render(client, REQUEST) in the base class that is inherited by a ZClass. If I grok the answers I got today by Martijn Pieters and Evan Simpson right, the arguments mean the following: self - the instance of this ZClass client - the object we're calling this method on (in my case an XML node) REQUEST - the regular request object the 'render' function figures out how to display the node (client) and returns the resulting string. This is however not working -- if I call an instance 'foo' like this on an XML node, like this: xmldoc/e7/e14/foo instead it'll display index_html (that is acquired and not defined on the ZClass). It apparently isn't calling __call__ at all. How do I fix that? Do I have to go full fledged product to do this? I'd like to use ZClasses because it's easier, but perhaps they simply don't allow it? Once I get this working I'll go back to the calling DTML Methods from Python problem again. :) Regards, Martijn

2 3

Multiple inheritance woes
by Martijn Pieters 09 Sep '99

09 Sep '99

Hmm.. I know this is a python question, but DejaNews nor the Python website give me the answers I am looking for: I define a baseclass derived from CatalogAware and DTMLMethod: class Base(CatalogAware, DTMLMethod): def index_object(self): # check a few things I want to know about # before indexing, maybe even not allowing # the indexing CatalogAware.index_object(self) Then I define a bunch of classes based on this base class: class A(Base): pass class B(Base): pass etc. Now, if I do the following: a=A() a.index_object() I get a TypeError: unbound method must be called with class instance 1st argument Now, I have seen all sorts of messages relating this error, but none of them seem to relate to my problem... self in Vase.index_object _is_ a class instance, a step-by-step debug proves this. The python interpreter just won't accept it =(. -- Martijn Pieters, Web Developer | Antraciet http://www.antraciet.nl | Tel: +31-35-7502100 Fax: +31-35-7502111 | mailto:mj@antraciet.nl http://www.antraciet.nl/~mj | PGP: http://wwwkeys.nl.pgp.net:11371/pks/lookup?op=get&search=0xA8A32149 ------------------------------------------

2 2

Announce: PythonMethod 0.0.1
by Evan Simpson 09 Sep '99

09 Sep '99

It works. I'm really tired. For more, see http://zope.org:18200/Members/4am/PythonMethod

4 11

WebDAV with IExplorer
by Rik Hoekstra 09 Sep '99

09 Sep '99

Some time ago I wrote a post about the problems IExplorer causes with WebDAV in Zope. For instance when copying a number of files to a "WebFolder", sometimes files are not copied, or not copied properly. Perhaps not much of a problem, but anyway too much of a problem if you want to use it for end users. Not using Win/IE is no solution as most users are using Windows _and_ IE is currently the only WebDAV client available. (Nobody seems to care, however, as no-one replied. Oh well, cluttering the list further on my own then.) Today, I discovered that at least part of the problem was related to a known (to pythonwin users anyway) very annoying 'feature' of Win95/98/NT: case (in)sensitivity. For example, if you create a folder 'foo' within a Zope WebFolder, it is created allright. However, Win95 converts the first character of its filenames to uppercase, even if it shows them in lowercase !?!?!. So you end up with a foldername in your webfolder which shows as if it were lower case (and the http request apparently asks the server for a lower case folder name), but in Zope it is with a capital first character. Manually changing the name of the Zope folder to all lower case will solve the problem. However, if you copy a tree of items (with folders/directories in them) the same problem occurs again - hampering the effective use of WebDAV. A few remarks: - I don't think changing the case of the folder in the webfolder will change anything - perhaps some of the Windows ftps clients could be suffering from the same problem??? Rik Hoekstra

2 1

RE: [Zope] mount zope server (was: Import from Zope-1 to Zope-2)
by Jay, Dylan 09 Sep '99

09 Sep '99

> -----Original Message----- > From: Michel Pelletier [mailto:michel@digicool.com] > Sent: Thursday, September 09, 1999 15:20 > To: Jay, Dylan > Cc: zope-dev(a)zope.org; zope(a)zope.org > Subject: Re: [Zope] Import from Zope-1 to Zope-2 > > > "Jay, Dylan" wrote: > > > > related note heres another idea I had. How about a product > that can mount > > one zope ODB into another. Using XML-RPC or something to > connect the two > > sites togeather over the internet. It may not be fast > enough for using that > > way but at least it would be really easy for transfering > data between zope > > odb's. > > We are entertaining the possibility of putting ZPublisher.Client into > the _ DTML Namespace. I am primarily championing the idea. > > 'Client' offers many cool uses. 'Client.Function' will call a remote > 'Zope Method' which marshals simple types around (int, list, > tuple etc.) > and act as Zope oriented RPC. 'Client.call' is a convienent wrapper > around 'Client.Function'. These both have the upshot of working with > any > URL, turning non 'object content' into file Message objects and return > them in a list. > > Even cooler, 'Client.Object' will create surrogate objects of remote > Zope objects. If you have a DTML Document on machine A, then > Machine B > could say: > > <dtml-with "_.Client.Object('http://A/YourDocument')"> > <dtml-var id> > </dtml-with> > > and print 'YourDocument'. You can pass autentication > information in to > all of the calls to access restricted object. So what would happen if this wrapper object was passed back using a <dtml-return> call or even a __bobo_traverse_ method? Would further resolution in the object happen using the link or would it break and start trying to find objects in the local context?

2 2

Re: [Zope-dev] File input retuns what type?
by Jason Spisak 09 Sep '99

09 Sep '99

Kevin, I changed the name of the form element, and the code refering to it to a wacky word, and I get the same traceback. It just wants to make that form element a string. I tried different browsers/platforms too. All my best, jason Kevin Dangoor wrote: > > This is a shot in the dark, but did you try a field name other than "file"? > That sounds so generic, I'm wondering if Zope has something else defined > that is interfering. Another way to know for sure would be to reference > REQUEST.form['file'] > > Kevin > > -----Original Message----- > From: Jason Spisak <webmaster(a)MTEAR.COM> > To: zope-dev(a)zope.org <zope-dev(a)zope.org> > Date: Wednesday, September 08, 1999 9:58 PM > Subject: [Zope-dev] File input retuns what type? > > >I am trying to upload a file into a property. > >I am using code that works to update the property: > > > >My form reads <input type="file" name="file" size="25" value=""> pretty > >standard fair. > > > > > > > > > > > >But only when creating a ZClass instance I get this traceback: > > > >Error Type: AttributeError > >Error Value: 'string' object has no attribute 'read' > > > >Traceback (innermost last): > > File /Zope/lib/python/ZPublisher/Publish.py, line 214, in publish_module > > File /Zope/lib/python/ZPublisher/Publish.py, line 179, in publish > > File /Zope/lib/python/Zope/__init__.py, line 201, in > zpublisher_exception_hook > > (Object: RoleManager) > > File /Zope/lib/python/ZPublisher/Publish.py, line 165, in publish > > File /Zope/lib/python/ZPublisher/mapply.py, line 160, in mapply > > (Object: ResumeClass_add) > > File /Zope/lib/python/ZPublisher/Publish.py, line 102, in call_object > > (Object: ResumeClass_add) > > File /Zope/lib/python/OFS/DTMLMethod.py, line 145, in __call__ > > (Object: ResumeClass_add) > > File /Zope/lib/python/DocumentTemplate/DT_String.py, line 502, in > __call__ > > (Object: ResumeClass_add) > > File /Zope/lib/python/DocumentTemplate/DT_With.py, line 148, in render > > (Object: > >ResumeClass.createInObjectManager(_.str(PARENTS[-1].counter), REQUEST)) > > File /Zope/lib/python/DocumentTemplate/DT_Util.py, line 321, in eval > > (Object: REQUEST['file'].read()) > > File <string>, line 0, in ? > > File /Zope/lib/python/DocumentTemplate/DT_Util.py, line 125, in > careful_getattr > >AttributeError: (see above) > > > >Doesn't the <input type="file"> return a file object in zope? > >The above code works to update the property, why not to create it? > >Any ideas? > > > >Jason Spisak > >webmaster(a)mtear.com > > > >_______________________________________________ > >Zope-Dev maillist - Zope-Dev(a)zope.org > >http://www.zope.org/mailman/listinfo/zope-dev > > > >(To receive general Zope announcements, see: > >http://www.zope.org/mailman/listinfo/zope-announce > > > >For non-developer, user-level issues, > >zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) > >

1 0