- Zope-Dev - Zope lists

FTP support for SQL methods
by Brian Hooper 22 Sep '99

22 Sep '99

Hi there - Should / does FTP work with SQL Methods? At least, in my environment, it doesn't, but after digging around in the code, it looks like since Shared.DC.ZRDB.DA.DA inherits from OFS.SimpleItem.Item (which defines manage_FTPstat and manage_FTPlist), it should be sufficient to just define a manage_FTPget method for DA, and that's it, right? Does anyone out there have any wisdom / insight on this? --Brian Hooper

1 0

Re: [Zope-dev] PROPOSAL: Site objects
by Adam Feuer 21 Sep '99

21 Sep '99

> Quoting Michel Pelletier <michel(a)digicool.com>: > > > o Small patch to ZServer.HTTPRequest > > > -- so it places the actual socket IP and Port numbers into the > > > request's environment (HTTP_SOCKET_IP and HTTP_SOCKET_PORT) > > > > > > -- i didn't use HTTP_HOST for mapping since it is symbolic; > > > i wanted to have a 1:1 mapping from IP address to path > > > > Hmmm.. this sounds like it wouldn't work with HTTP 1.1 'Host' header > > based virtual hosting. Where the IP addr is the same for all virtual > > hosts. > > michel, > well, yes. but the IP-based scheme seemed the hardest problem to > tackle. :-) > > it would be easy enough to change the Remapper logic to look for the > HTTP_HOST key, and if it exists, use it; othewise check the socket IP > address, and use that. i forgot to say, i'll update my code to do that! :-) cheers adam -- Adam Feuer adamf(a)pobox.com

1 0

RE: [Zope-dev] PROPOSAL: Site objects
by Michel Pelletier 21 Sep '99

21 Sep '99

> -----Original Message----- > From: Adam Feuer [mailto:adamf@pobox.com] > Sent: Tuesday, September 21, 1999 3:52 PM > To: Evan Simpson; Jim Fulton > Cc: zope-dev(a)zope.org > Subject: Re: [Zope-dev] PROPOSAL: Site objects > > o Small patch to ZServer.HTTPRequest > -- so it places the actual socket IP and Port numbers into the > request's environment (HTTP_SOCKET_IP and HTTP_SOCKET_PORT) > > -- i didn't use HTTP_HOST for mapping since it is symbolic; > i wanted to have a 1:1 mapping from IP address to path Hmmm.. this sounds like it wouldn't work with HTTP 1.1 'Host' header based virtual hosting. Where the IP addr is the same for all virtual hosts. -Michel

1 0

RE: [Zope-dev] using persistent storage inside Zope
by Michel Pelletier 21 Sep '99

21 Sep '99

> -----Original Message----- > From: Adam Feuer [mailto:adamf@pobox.com] > Sent: Monday, September 20, 1999 12:54 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] using persistent storage inside Zope > > > zope folks, > if this has already been covered somewhere, let me know-- i just > couldn't find information about it on the Zope site! > > i'm building a Zope product that needs to store some persistent > information in the Zope object database. the information needs to be > accessible to all instances of that product. I would suggest not making this data a class attribute, and instead make it an instance of an object that provides a service to your instances via a protocol you define yourself. For example, a user folder provides an authentication server to other zope objects. > my approach was: write a class that derives from > Persistence.Persistent that will store the data and mediate access to > it. then, in the product's __init__.py file, instantiate this class > and put the instance into the Zope object database, then call > get_transaction().commit() to commit it. > theoretically, once my instance is in the Zope object database, > other objects can access it-- adding or subtracting data. and the > instance will handle committing its own changes, so it won't forget > anything between restarts of Zope. Your sorta halfway there, but I would make your 'storage' a full fledged Zope object, not some sort of product class attribute, if this is what you mean. Maybe I'm the one confused. > my question: how do actually do this?? :-) i found a kludgy way to > store a class instance in the Zope object database from the product's > __init__.py file, but i can't figure out how to connect to this object > from a random instance of my product. > > amy i going about this all wrong? is there a better way of storing > and accessing persistent objects from inside of Zope? or if my > approach is correct, how do actually implement it? > > here's what i am doing in the product's __init__.py file: > > # get the ZODB root-- kludge! > root=context._ProductContext__app._p_jar.root() > # now make the object instance if we need to > if root.has_key('FooObject'): > print "FooObject already in DB" > else: > print "made new FooObject." > root['FooObject'] = Foo.Foo() > get_transaction().commit() > > > the problem seems to be, i don't know how to get access to the Zope > object database's root object from inside an instance of my product. > what i want to do inside the product base class, during an add or > delete of an instance of the product, is something like: > > # somehow get the root of the Zope ZODB :-) > root=Somehow.get.ZODB.root() self._p_jar.root() > root['FooObject'].remove_item(someitem) > get_transaction().commit() All persistence objects have an _p_jar attribute which represents the current database 'connection'. _p_jar.root() will give you the root object. But what it looks like your doing is stuffing something in the object database that Zope is not aware about? Why not just make it a Zope object? This smells like a hack. -Michel

3 2

Length of Search Results/ZServer Crawling
by Jason Spisak 21 Sep '99

21 Sep '99

Zopsters, Does anyone know why this code:    Outside the Catalog, renders the number of all the objects in the Catalog and not the Amount of MyClasse instances in the Catalog? I'd like to get the number of objects of a give type with some property values that are cataloged, but I'm unable to. Also, ZServer has been slowing to a crawl and taking 2-3 minutes to give back responses at times. Very vague, I know, but I don't see activity on all of the threads, so I don't see how more threads would solve the problem. Right now I am running what looks like the default 6 threads. All with 13% of CPU percentage. I've got about 20 people hammering this thing non-stop all day long. The spead is good when I restart Zope, but then it deteriorates the longer the process is leftr running. -- Jason Spisak webmaster(a)hiretechs.com

3 2

Re: [Zope-dev] what you see and what dont is all dom
by cwitty＠newtonlabs.com 21 Sep '99

21 Sep '99

Richard Wackerbarth <rkw(a)dataplex.net> writes: > On Mon, 20 Sep 1999, Martijn Pieters wrote: > > In Zope, the inputs to a rendered document depend on the acquisition path > > taken, and there is an unlimited number of combinations. I don't think that > > a dataflow scheme is therefore applicable to Zope. > > I tend to agree. Cacheing of targets, which is implicit in dataflow, only works > when there are a limited number of targets and those targets are likely to be > used in the future. Well, there are certainly sites where very few HTTP requests would be repeated, and caching would be a waste of time; but I'll bet there are sites that would be willing to trade off some of the power of Zope (by avoiding some of the more interesting uses of acquisition) for significantly better performance. Carl Witty

1 0

Fw: [Zope-dev] wygiwys
by morton＠dennisinter.com 20 Sep '99

20 Sep '99

----- Original Message ----- From: damien morton <morton(a)dennisinter.com> To: Jeffrey Shell <Jeffrey(a)digicool.com> Sent: Thursday, September 16, 1999 6:55 PM Subject: Re: [Zope-dev] wygiwys ----- Original Message ----- From: Jeffrey Shell <Jeffrey(a)digicool.com> > > If the community were to come up with something REALLY good, we'd be > interested. But there's a lot of difficulty matching the advanced > philosphies of Zope (Acquisition, Security, and now ZClass based > objects) and DTML (namespaces, syntax, general concepts) with just about > any visual editor out there. A _LOT_ of difficulty. It would be a > project of some serious effort, and we haven't seen anybody with enough > initiative to come up with a plan of tackling this. > > On the other hand, the new syntax is easier to work into smart > (non-visual) editors like Alpha (and Emacs-ish editor on the Mac) with > syntax completion and all that. Some tags like the contributed dtml-let > tag may have some difficulties in these environments that prefer to help > keep code very neat by quoting all attributes (a good thing really), > since the dtml-let tag behaves differently (ie, > > <dtml-let bob=uncle lu="aunt()" billy="'cousin'"> > > ) The basic problem is that most good html designers (as opposed to html hackers) are working with object oriented design tools. They whack this object there, set its properties, attach some behaviours, and away they go. They are working at the DOM level. Many of the objections to integration object oriented html desitgn tools with programmer oriented tools such as zope arise from the fact that programmers like to work with the raw text of the html. But the raw text is just the transport layer. Whats really being handed around in a http transaction is DOM trees that happen to be represented as html. If our work as programmers focussed less on whacking out html text and instead focussed on producing and consuming DOM nodes, then the integration between object oriented html design tools and out programming tools would become a lot easier. In fact, the a website as a whole could be viewed as a DOM structure, and there are many advantages to this. For example, if we assumed that our programs elemenst were functional DOM consumers and producers, you could eliminate much of the dynamic nature of a website. In my experince, there is a whole lot of stuff about a website that only changes slowly - it doesnt need to be re-created for every page view, only when the source data changes. If you could decompose a website into a kind of feedforward dataflow machine and add some intelligent caching, you would have a very efficient dynamic website. What would be needed for that would be for the programmed part of the website to conform to functional or dataflow programming - each module or function would take objects as input and would create or modify existsing objects. Might mesh well with the ZODB mechanism. > And there's always problems with this perrenial favorite (dtml tags > inside of HTML tags) -- > > <tr <dtml-if sequence-index-even>bgcolor="#c0c0c0"</dtml-if>> > > And, well, a trying-to-be-SGML-complient editor that is doing all these > wonderful things to help you (syntax hiliting, completion, dialog boxes > with tag attributes) panics and jumps over these. > > But situations like that aside, the new syntax is significantly easier > to work with. And with FTP and WebDAV integration, authoring outside of > the management interface is made a little bit easier (but work still > needs to be done in this area to help it along). > > So, the dream lives on... :) > > _______________________________________________ > 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 ) >

4 6

Re: XML Document & ZCat
by Clint Shelby McCulloch 20 Sep '99

20 Sep '99

It appears that zcat limits the acquisition of properties to direct children (not XML Document) when indexing. Example: 1) Create afolder with a property named, say, 'city' 2) Create a subfolder (subfolder1) 3) Create a subfolder of that folder (subfolder2) 4) Use ZCat to index the colection: in the expr field enter 'color' Result: The root folder and subfolder1 will be found and indexed, but not subfolder 2. Is this intended?

1 0

using persistent storage inside Zope
by Adam Feuer 20 Sep '99

20 Sep '99

zope folks, if this has already been covered somewhere, let me know-- i just couldn't find information about it on the Zope site! i'm building a Zope product that needs to store some persistent information in the Zope object database. the information needs to be accessible to all instances of that product. my approach was: write a class that derives from Persistence.Persistent that will store the data and mediate access to it. then, in the product's __init__.py file, instantiate this class and put the instance into the Zope object database, then call get_transaction().commit() to commit it. theoretically, once my instance is in the Zope object database, other objects can access it-- adding or subtracting data. and the instance will handle committing its own changes, so it won't forget anything between restarts of Zope. my question: how do actually do this?? :-) i found a kludgy way to store a class instance in the Zope object database from the product's __init__.py file, but i can't figure out how to connect to this object from a random instance of my product. amy i going about this all wrong? is there a better way of storing and accessing persistent objects from inside of Zope? or if my approach is correct, how do actually implement it? here's what i am doing in the product's __init__.py file: # get the ZODB root-- kludge! root=context._ProductContext__app._p_jar.root() # now make the object instance if we need to if root.has_key('FooObject'): print "FooObject already in DB" else: print "made new FooObject." root['FooObject'] = Foo.Foo() get_transaction().commit() the problem seems to be, i don't know how to get access to the Zope object database's root object from inside an instance of my product. what i want to do inside the product base class, during an add or delete of an instance of the product, is something like: # somehow get the root of the Zope ZODB :-) root=Somehow.get.ZODB.root() root['FooObject'].remove_item(someitem) get_transaction().commit() any help is greatly appreciated! cheers adam -- Adam Feuer adamf(a)pobox.com

1 0

XML Document & ZCat
by Clint Shelby McCulloch 20 Sep '99

20 Sep '99

I've made some progress trying to catalog xml documents.. There are a few wrinkles which make things interesting. One thing I've noticed, however, is that acquisition works somewhat strangely either when xml documents and zcat are combined or simply with xml documents. Element attributes appears to travel down the hierarchy only one level: if an element has an attribute then it will be availble only to its first children. This seems to be true with any properties of the xml document itself as well. This has been my experience cataloging xml documents, but I may try to see if the same is true with dtml. All in all, though, I'm very impressed with both of these products. Although I've yet to try it, kudos for adding relevance ranking!

1 0