Re: [Zope-dev] limit to number of operations in a transaction?
"Christopher N.Deckard" <[EMAIL PROTECTED]> writes: > I have roughly 1,500 people in the database. I wrote a script to > migrate the people. Basically it does getProperty for each property > on each person folder, then creates the new person object which uses > XML. Zope apparently cannot handle this number of operations in one > transaction. Zope gets slower and slower and eventually becomes on > responsive. It looks like the script has completed, but nothing is > ever committed to the ZODB, and since Zope is unresponsive it must > be restarted. This, as expected, kills that entire transaction > which was never committed. > > Is it known that large numbers of operations, such as above, in a > single transaction can cause problems? A transaction, of course, > being a request, and an operation being something like > manage_addProduct. In practice I've only seen problems when I'm dealing with lots of data and need to be thinking about this anyway :) > I've solved the "problem" by using xmlrpc and for person in people > calling my migrate_person script for only one person at a time. > This is SO MUCH FASTER. I previously ran the script that migrates > all of the people, and after 8 hours it still had not completed. As Jens replied, this is because the transactions are getting committed for each person, and you can do this without xmlrpc by committing in your script. The possible drawback of committing after each person is that you're committing a new version of the object being modified. Depending on how you're storing the stuff this can grow your ZODB - if every person is a node in a single ParsedXML document, you'd be storing 1500 versions, each one person bigger than the last. You can use transactions and subtransactions to juggle database size, memory usage, and temp file usage. -- Karl Anderson [EMAIL PROTECTED] http://www.monkey.org/~kra/ ___ Zope-Dev maillist - [EMAIL PROTECTED] 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-dev] DAV collections, index_html, and HEAD
Objects that inherit from Folder (and therefore from Collection) and also have an index_html that's a Python method (or othewise nonvanilla, presumably) return a 405 (Method Not Allowed) for HTTP HEAD requests. Zope 2.5.1 raises on line 57 of Collection.py. The object raises if its index_html member doesn't have a HEAD attribute. Surely it's a bug to only give HEAD for objects that return an index_html via hasattr/getattr. What about getitem, __bobo_traverse__, and __call__? Shouldn't we find the object to HEAD via ZPublisher? And aren't we bypassing the access control checks, anyway? Would it be a good idea to try and make up a HEAD response for arbitrary attributes that don't support it (such as Python methods)? Perhaps by publishing them internally, and picking whatever we can from RESPONSE, computing Content-Length from the returned stream if necessary? It's inefficient, but at least it's cache-friendly... and better for tools (er, linbot) that assume that if it can't be found via HEAD, it isn't there. Excerpt from Collection.HEAD(): # Note that we are willing to acquire the default document # here because what we really care about is whether doing # a GET on this collection / would yield a 200 response. if hasattr(self, 'index_html'): if hasattr(self.index_html, 'HEAD'): return self.index_html.HEAD(REQUEST, RESPONSE) raise 'Method Not Allowed', ( 'Method not supported for this resource.' ) raise 'Not Found', 'The requested resource does not exist.' persephone ~/tmp= telnet viii.dclxvi.org 80 Trying 206.163.69.253... Connected to viii.dclxvi.org. Escape character is '^]'. HEAD /blog HTTP/1.0 HEAD /blog HTTP/1.0 HTTP/1.1 405 Method Not Allowed Date: Thu, 06 Jun 2002 02:22:40 GMT Server: Apache/1.3.12 (Unix) mod_ssl/2.6.6 OpenSSL/0.9.5a Bobo-Exception-File: /usr/local/zope/2-5-1/lib/python/webdav/Collection.py Bobo-Exception-Line: 57 Bobo-Exception-Type: Method Not Allowed Bobo-Exception-Value: bobo exception Connection: close Content-Location: http://viii.dclxvi.org/blog/ Ms-Author-Via: DAV X-Powered-By: Zope (www.zope.org), Python (www.python.org) Content-Length: 2106 Content-Type: text/html -- Karl Anderson [EMAIL PROTECTED] http://www.monkey.org/~kra/ ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Parsed-XML-Dev] Re: [Zope-dev] ParsedXML in Zclass methods loses permissions on Zope restart
Martijn Faassen <[EMAIL PROTECTED]> writes: > Brad Clements wrote: > > I'm still casting around for a suggestion on where I can go to fix this. > > > > I have a ParsedXML object in the methods list of a ZClass Product. > > > > The "Access Contents Information" Permission Mapping always get's reset to "blank" >in > > the ParsedXML object when Zope restarts. > > > > Is this a problem with ZClasses, or with ParsedXML? > > Taking a look at ParsedXML, it looks like it just does a very simple > permission definition, so it doesn't *look* like there's something > wrong there. > > What it sounds like is that something that should be persistent isn't > for some reason. Either an object attribute is changed without > the permission mechanism being informed of the change, or it's > for some reason an attribute on a nonpersistent is changed. This at least > would explain why the permission mapping magically goes away.. I don't understand the situation very well, but Martijn's explanation sounds familiar. Remember, there's only one persistent Zope object in a ParsedXML instance, and that's the document proxy object. All of the proxy subobjects are transient, and that includes proxy documents that are navigated to from proxy subobjects. I.E. if "app.foo.PXML" is the ParsedXML instance, then setting Zope attributes on "app.foo.PXML.firstChild()" and "app.foo.PXML.firstChild.parentNode()" won't persist. Same goes if you traverse to these nodes via the web-exposed URLs of these methods. Perhaps you're trying to persist changes to Zope attributes on those nodes? -- Karl Anderson [EMAIL PROTECTED] http://www.monkey.org/~kra/ ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: oodb philosophics ;) was: Re: [Zope-dev] Experiments withORMapping
Casey Duncan <[EMAIL PROTECTED]> writes: > I am not arguing necessarily for SQL as a query language for the ZODB. > Although it is an accepted standard, but not a perfect one by any means > especially for OODBs. Its appeal lies mainly in the high level of > community familiarity and the plethora of SQL software to borrow from. Does anyone have an opinion on the possible usefulness of XPath, XQuery, and other XML standards for this? Someone suggested (on the zope-xml wiki) that it would be nice to be able to drop in a cataloger that supported a presumably standard and presumably well-known XML query syntax, and which would work throughout the database because Zope objects would support DOM. This is all speculation, and I personally don't know much right now about XML database interfaces and how finished or well-regarded they are. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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-dev] ZCatalog catalogable types and nonproducts
I have a Python Product with several subobjects which are not products
in their own right. I'm trying to make these subobjects selectable in
the Find Objects tab of a ZCatalog, so I can restrict the cataloged
objects to these types.
Whats the right way to do this?
Since they're not addable products, they don't go in the "Find objects
by type" selection by default. Rooting through the source, I see that
this selection is populated by all_meta_types, and ObjectManager
creates that list by appending a _product_meta_types attr onto an
acquired value.
I can't create a _product_meta_types property on the ZCatalog. I can
add a _products_meta_type dict to the ZCatalog via Python:
app.catalogtest.catalog._product_meta_types = ({'permission': 'Dummy', 'name':
'Manageable Element', 'action':'Dummy'},)
I added the dummy permission and action becuase the contents view
doesn't display without them.
This seems to work, and these meta types aren't displayed in the add
list for the container view (becuase I don't have the 'Dummy' perm),
which is what I want. But should I be telling the users of my product
to do this?
--
Karl Anderson [EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] memory leak
This turns out to be a memory leak in ParsedXML. DOM references created during a parse aren't released. We hope to have a new release very soon that fixes this. Restarting Zope is a temporary workaround - DOM refs retrieved from the DB aren't being leaked. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] memory leak
Marco Nova <[EMAIL PROTECTED]> writes: > I've replaced ParsedXML's ExpatBuilder with the pyXML package and I used the > sax parser without modifing the code (except for the import), this is the > refcounts results. > > Class April 12, 2001 11:55 am April 12, 2001 12:00 > > xml.dom.NodeList.NodeList 2103 3678 +1575 > xml.dom.Text.Text 1263 2208 +945 > xml.dom.NamedNodeMap.NamedNodeMap507 885 +378 > xml.dom.Element.Element 499 871 +372 > xml.dom.Attr.Attr339 591 +252 > xml.dom.DocumentType.DocumentType 710 +3 > xml.dom.Document.Document 710 +3 > > xml.dom.Document.Document increments by 1 each time an xml is procesed (I > tried to add a del doc at the end but it's ineffective). > > So the problem is not ParsedXML but Zope itself or my bad methods. Not necessarily - it's been mentioned that PyXML requires releasing nodes after they're done, so I'd expect this if you replaced ParsedXML's DOM with PyXML's without adding the release. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] memory leak
Dyon Balding <[EMAIL PROTECTED]> writes:
> On Tue, Apr 10, 2001 at 05:27:28PM +0200, Marco Nova wrote:
> > Hello guys,
> >
> > It seems that I've some memory leak problems and I want to understand where
> > I've to look for.
> >
> > Scenario:
> >
> > I've an IIS web server that generates an XML page (taking data from
> > SqlServer);
> > The Zope web server must retrieve the XML page, manage the data and render
> > them in HTML (I cant only apply a XSL stylesheet to XML).
> >
> > The Facts:
> >
> > I've written a external method that - using httplib - reads the XML page and
> > return a string that is the raw XML sources, than I've written another
> > external method that use ExpatBuilder of Products.ParsedXML.DOM to parse the
> > XML an generate a list of [(id - {mapping})] which will be accessed with a
> > dtml-in tag, so in the sequence-key I've access to the ID and with
> > sequence-item I can access to the mapping object.
Are you parsing the XML and creating this list from the DOM objects,
and then throwing them away? Or are you parsing the XML and creating
this list from your pyexpat interface code, and never accessing the
DOM objects?
In either case, it seems like you shouldn't be using ParsedXML's
ExpatBuilder, which is an interface to PyExpat which is made to create
ParsedXML's DOM objects. You should be using your own PyExpat
interface to parse this information from your XML input, without the
overhead of generating a DOM tree that you're just going to throw
away. The interface is documented in the XML-SIG topic area on
python.org, and our ExpatBuilder should be a good example on how to
interface with our PyExpat installation - just don't build the DOM if
you don't use it.
Regardless of what you *should* be doing :), or if I'm misreading you,
if you aren't keeping references to the DOM objects being created,
then they should be reclaimed by the GC, and you do seem to have DOM
objects lying around. I'd like to see your code, is it short enough
to post? Or you can chuck it into the collector or ParsedXML tracker.
For debugging purporses, I'd suggest simplifying by supplying an XML
string directly, rather than from an external server.
--
Karl Anderson [EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] memory leak
ender <[EMAIL PROTECTED]> writes: > generally dom objects need to be released to destroy them, doing a del doc, > won't do it because of circular ref nature of dom. i'm guessing that you > would need to call something akin to releaseNode from pyxml (xml.dom.ext) on > the document to release it fully else you're likely to see the behavior > you're seeing, namely dom objects staying in memory. We aren't using circular refs in our DOM, so we don't have any way to release a DOM object - losing or deleting the reference should do it. If this isn't happening when the reference is going away, then this is either a Zope bug or a ParsedXML bug. I'd like to make sure that the ref really is going away, though :) > a quick browse through the source of ParsedXML doesn't offer any clues on how > to release the object (or if its nescessary). its hard to say since > acquisition is being used to help with the dom tree. Acquisition is what we're currently using to avoid circular references. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Memory problems with ParsedXML ?
Godefroid Chapelle <[EMAIL PROTECTED]> writes: > Karl Anderson a écrit : > > Another thing to keep in mind is that the ParsedXML *product* is a DOM > > tree and a management interface around it. The management interface > > only gives you a convenient UI and a place to store a few bits that > > the DOM doesn't know about (content type, namespace usage, etc.). > > It's always more efficient to just use the DOM tree and related > > utilities (parsing, printing), although it is less convenient - you > > have to know a little bit more about what you're doing. Do you need > > each of those 2500 product instances? See the createDOMDocument > > method to create a DOM document without the management interface. > > > > I am trying to use createDOMDocument, calling it from an external method: > > from Products.ParsedXML import ParsedXML > > def accessXml(document): > return ParsedXML.createDOMDocument(document) > > When using the document returned in a python script, it seems that Zope > security prevents me from accessing any DOM attributes. > > Am I doing something wrong or am I forced to do everything through external > methods ? The DOM objects without the ParsedXML management proxies don't have any Zope security information associated with them, so you have to provide it yourself. This is one of the things that the management proxies provide. I didn't mean to sell the proxies short; I should have mentioned that you have to know about providing the features youself that they provide, including security, so this is an area for Zope experts. I've added this to the README. Furthermore, if you're just calling methods on the Document node, without traversing to its subnodes, you're really not paying much of a price; you're basically just putting more function calls between you and the DOM object until you access a DOM subobject. I don't use the python scripts much, but they have very restricted security, being web-edited and all. So yes, one way to give access is to use external methods. Another way is to use a python product and the security machinery available to you there. The unproxied DOM objects are similar to any non-Zope aware python class instances with regards to security; if you're unfamiliar with it, I'd play around with some non-Zope aware dummy class instances, with nested subinstances and attributes, until you know how to make those objects and attributes publishable. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Memory problems with ParsedXML ?
Godefroid Chapelle <[EMAIL PROTECTED]> writes: > Hi, > > I have imported about 2500 xml files in ParsedXML objects through the > use of : > > manage_addProduct['ParsedXML'].manage_addParsedXML(id, '', xmlString) > > This works perfectly. > > But when trying to browse the folder containing the ParsedXML instances, > a whole lot of memory is used by Zope and it took my machine down. > > Have I done something wrong or does this info help you debug the product > ? Hm, it's been pointed out to me that the inefficiency of the get_size method of ParsedXML is compounded with many instances because the standard management interface uses it. It's possible that some stuff isn't getting garbage collected until the transaction is done, and calling get_size on many ParsedXML instances in one transaction is the problem. I'll look into it. I didn't think that anyone would want to see a management screen with 2500 ParsedXML instances - or 2500 instances of anything - at one time. Have you tried using a BTree folder? Another thing to keep in mind is that the ParsedXML *product* is a DOM tree and a management interface around it. The management interface only gives you a convenient UI and a place to store a few bits that the DOM doesn't know about (content type, namespace usage, etc.). It's always more efficient to just use the DOM tree and related utilities (parsing, printing), although it is less convenient - you have to know a little bit more about what you're doing. Do you need each of those 2500 product instances? See the createDOMDocument method to create a DOM document without the management interface. It's easy to wrap a ParsedXML product around an existing DOM tree - see the initFromDOMDocument method. Currently, you have to create the persistent ParsedXML product which wraps the DOM Document node, and install that product in a Zope ObjectManager (or subclass like Folder) somewhere, to avoid a few warts. Someday I'd like to be able to just instantiate a management wrapper when I want a management interface, and then just throw it away, without bothering to add it to a folder. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] FTP interface being worked on?
"Chris McDonough" <[EMAIL PROTECTED]> writes: > > > Are you thinking that we would build client-side tools to recognize an > XML > > > representation of a subpart of a site? > > > > Client-side tools, no. I'm thinking that exporting to XML would allow > > existing tools to recognize and manipulate a subpart of a site. > > Which ones? Parsers, transformers, etc.. I don't know of any end-user tools (are there any?), I'm talking about building blocks. > > Is there a particular set of tools or editing paradigms that we have > > in mind when we say that a non-XML representation is suited for client > > side tools? > > Yes.. anything that works well with diff and CVS and is recognizable by a > human. PythonScripts should be serialized to something that looks like a > regular Python script. Images should look like images, etc. The directory > tree generated should look as much as possible like a normal filesystem. Sure, I would use that, too, probably more than an XML representation, I'm referring to the ability to represent in other formats because of their usefulness and scalability. For example, if I were doing lots of random edits on a subtree of DTML files and Python scripts, I'd want them to look like a filesystem tree full of text files and I'd use emacs, grep, find, etc. on them. If I wanted to be able to use an automated tool to, say, update the spam and eggs fields of everyting in a subtree every friday, an XML parser and/or DOM tree and/or transform working on a single XML representation of the subtree checked out to the local filesystem seems like the easiest entry point. I'm probably straying from the proposal here. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] FTP interface being worked on?
Chris McDonough <[EMAIL PROTECTED]> writes: > I think the only good reasons we have right now for having > filesystem-compatible serialization are to make Zope content editable via > common tools in a way that makes sense to people not used to (or comfortable > with) the object database, and to give people a plausible way to put a Zope > site under source control. > > Are you thinking that we would build client-side tools to recognize an XML > representation of a subpart of a site? Client-side tools, no. I'm thinking that exporting to XML would allow existing tools to recognize and manipulate a subpart of a site. I'm basically agreeing with you - "common tools" for manipulating text sounds like parsers to me. I'm not sure why XML is considered less readable than an unknown format for Zope object serialization; I guess I haven't seen what's being considered. But it seems to me that for humans, XML might lose by a little, but for any type of mediated or batch processing, XML wins by a lot. Parsers are standard enough that their APIs are easy to learn if you've played with them before. Random human-editable text formats sounds like StructuredText; when I think of StructuredText I think "simple DOM serialization". Is there a particular set of tools or editing paradigms that we have in mind when we say that a non-XML representation is suited for client side tools? This is the way that Manila seems to be doing it: http://www.thetwowayweb.com/theXmlFiles -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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-dev] ParsedXML 1.0 released
We've just released ParsedXML 1.0, the first stable release. It can be downloaded from zope.org at <http://www.zope.org/Members/karl/ParsedXML/ParsedXML>. Parsed XML allows you to use XML objects in the Zope environment. You can create XML documents in Zope and leverage Zope to format, query, and manipulate XML. Parsed XML consists of a DOM storage, a builder that uses PyExpat to parse XML into the DOM, and a management proxy product that provides Zope management features for a DOM tree. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] FTP interface being worked on?
"Chris McDonough" <[EMAIL PROTECTED]> writes: > I don't think it's reasonable or wise to impose any "master > structure" for filesystem serialization of bodies of > objects. Each instance (or perhaps each class) should > define how best to serialize itself to disk. > Representations between classes are likely to be radically > different. A place for standardization is in the > "properties" file(s) which accompany each object rep... this > is likely to be XML or another structured variant. Is there a motivation for using serialization to provide an editable "god's eye view" of all or part of a Zope site? That is, provide a two-way XML serialization at any stage of the managed hierarchy of a site? That way, XML tools could be used as stream editors at any level, to the extent that the serialization is understandable. So, for example, we'd have ways to not just alter a template or content that gets templatized, but the containers that organize them, and related metadata or content that isn't as near. This links well with the standardization that you mention - objects can have arbitrary serialization formats, but if certain attributes that we're interested in are recognizable, those attributes could be edited on a containerwide level. So, if we had arbitrary objects that we wanted to have an effect on content or display, the same XML tools could be used to manage them all, limited only by the ability of those tools to slog through a level of the hierarchy. This is kind of stream-of-consciousness talk, and might be more silly than realistic; certainly, if the objects didn't guard how they could be updated, a misconfigured tool could waste them without warning. There's a similar project called psilib that was discussed in xml.com: <http://www.xml.com/pub/a/2000/03/22/psi/index.html> -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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-dev] acquisition interfering with []?
Hopefully this is enough context for this question.
When I subclass Acquisition.Implicit or .Explicit, I find myself
losing the foo["item"] and foo[slice:slice] syntax. __getslice__ and
__getitem__ aren't affected.
When I don't subclass Acquisition, the [] syntax works fine.
I can get them back by explcitly redefining them __getslice__ and
__getitem__ (even though those methods never had any problems), but is
there a better way around this?
I'm doing a lot of other craaazzy stuff with these classes, I may be
causing this problem myself elsewhere. I'm not defining
foo.__getslice__, rather I'm defining __getattr__ in a superclass, and
returning the result of a call on a proxied object for attr names that
match a list.
But this does look like the [] syntax is running into the fact that
you need to call inheritedAttribute rather than the superclass method
directly, or something.
Here's what I'm doing to make this work:
class ManageableNodeList(ManageableWrapper, DOMProxy.NodeListProxy,
Acquisition.Implicit):
def __getslice__(self, i, j):
return self.__getattr__("__getslice__")(i,j)
def __getitem__(self, i):
return self.__getattr__("__getitem__")(i)
--
Karl Anderson [EMAIL PROTECTED]
___
Zope-Dev maillist - [EMAIL PROTECTED]
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-dev] the Parsed XML project
The Parsed XML project is now public and ready for input. Parsed XML is the successor to XMLDocument. We have a wiki at <http://www.zope.org/Wikis/DevSite/Projects/ParsedXML>. [EMAIL PROTECTED] is also a good place for discussion at this time. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] mailing list 'noise'
Ken Manheimer <[EMAIL PROTECTED]> writes: > In fact, i'm *really* interested in "turning answers into stories". That > is, not just getting answers to questions, but preserving them in a way > that makes them easy to find when they're next needed - organizing them so > they collectively serve to describe the topic they're about, to make the > topic, as a whole, discoverable. While i think there are many modes of > discussion that can serve this purpose, depending on the application and > collaborative context, i think mailling list discussion threads need more. > They're a step towards that building-together, but fail to organize beyond > that - so the answers they provide are fragmentary glimpses into the topic > at hand. > > One key way wiki documents help bind the fragments is by providing more > "fixed points" around which discussions can range. The fixed points > are not immutable - they can evolve - but they're easy to point at, and > provide a definite manifestation of the topic at some stage of its life. That's a good point. Mailing list threads are great if you're around when they come up. After that, searching is doable, but not easy enough - witness that the same threads tend to come up for any list. One good quality of lists is that if you can tell your reader to organize threads, then the discussion is broken up and shoved in your face for you piece by piece. In a wiki, on the other hand, you have to return to the same page, find where you were last, and actively look for changes. > The dev.zope.org proposals site is one example where definite subjects are > at hand. As someone behind the WikiNG proposal, who *wants* to be able to > reap the suggestions and details from a discussion, but knows i won't have > the time for a while to actually concentrate attention on it, i dread > having to collect all the messages, for later review for harvesting. > Furthermore, messages on the mailling list tend to diverge more and > farther from the topic, than they do when placed within the wiki. > > What i'd like the best, for now, is to have discussion happen on the > mailling list *when someone wants to feel something out*, *and then > they're responsible for summarizing in the wiki discussion page, if they > have anything to harvest*. Note that we keep on acknowledging that the different fora are better in different ways, and that what we keep on wanting is the right way to communicate and propagate between the fora. Here, you want it to be easy to pop a thread into a wiki. Something like a thread-to-wiki feature would be nice - tell the wiki "flatten this thread & make a page for it", then edit it by hand. But it's still a one-way link, really, the best you can do is post a final message to the thread - 'see the wiki for further discussion'. Which isn't that bad, really. What I really want is for the different fora to just be interfaces on the information. I'm not sure how, it isn't that realistic, I can't think of an implementation without it getting overfeatured. Something like wiki edits being reflected in the mailing list archive. Nah. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] I feel your Wiki Pain ;-)
Martijn Faassen <[EMAIL PROTECTED]> writes: > I think you could integrate both mailinglists and wikis. On the one > hand, often we'd like to preserve a good posting in a mailing list as > a wiki page. So we make a separate [EMAIL PROTECTED] address that's subscribed > to the mailing list, that keeps listening to the list and sees things > like this in postings: > > Wiki:StructuredTextWiki:FooBarPage > > This is a bunch of text that should be added to FooBarPage. > > Wiki:end Check out the MonkeyFist blog at <http://monkeyfist.com/DailyChurn/> - it's generated by scanning their IRC channel. -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] mailing list 'noise'
Ken Manheimer <[EMAIL PROTECTED]> writes: > On Thu, 28 Sep 2000, Chris Withers wrote: > > > Toby Dickenson wrote: > > > I dont see this as a problem: You only create a new list when the > > > traffic for that proposal gets too great for zope-dev. Threading is > > > good enough before that point. > > > > Yes, but zope-dev has a relatively high traffic load... Why should you > > have to put up with all that 'noise' if you're only interested in posts > > for your comparatively small discussion? > > Yeah - maillists flow by, and not everyone can follow all the traffic all > the time!! The cool thing about "content-based" mailling lists, where > people can subscribe to notifications about changes in subthreads, is that > you just subscribe to the part of the discussion that has your interests!! I haven't understood this gripe ever since I started reading mail with Gnus. Before anyone groans, I'm not sure that Gnus is ready for general use by anyone who doesn't want to learn elisp - but surely there's anther reader with these features? The point that I'm trying to make is that a mailing list has all the strucure needed to keep abreast of an important thread. I don't think it's perfect when you can't afford to miss a single important article, but it works great for general lists. Gnus treats mail & news as the same, and allows you to score posters, threads, messages, etc. both manually and adaptively. Threads can be presented by order of their score. Adaptive scoring is what really makes it work. The normal reading commands - read article, kill thread, save article, catchup (mark unread articles as read) can affect the scores. So, reading articles in a thread tends to make it float to the top, and posters who contribute to well-read threads elevate future threads that they contribute to. The inverse for killed threads, less so for caught up threads. I can read comp.lang.python when it has 3000 unread articles, by skimming 100-500 articles, reading some, catching up or killing the rest, and saving other 2500 for later. I draw in what I'm interested in from the mass of unread articles first, each time, and the stuff that I rarely get around to is the stuff that I don't miss. Same with rec.bicycles.soc - when the article count gets to 200-300, I read the 2-10 articles that I'm probably interested in, and miss the 95% which is almost always noise. That's why I resist moving to other fora. I've never seen one that lets me use better tools. Okay, my download finished while I wrote this, back to work :) -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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-dev] permissions/authorization on non ZClass/product objects
I'm having trouble with permissions and Python class instances that aren't part of the Zope permission mechanism. I'm creating plain Python class instances in the Python baseclass of a ZClass, and storing them in a list on the baseclass. The baseclass instantiates these instances and appends them to its list. The class is defined in the baseclass .py file. A method on the baseclass returns this list of instances, and I'm iterating over them in DTML and looking at their attributes - or trying to. I get an authorization prompt, which always gives me an auth error, even though the user can look at the ZClass that's returning the instances. I'm able to get around this by registering the plain Python class as a base class, subclassing them with a ZClass, and instantiating ZClass instances instead of baseclass instances. It seems like overkill, though (and I always thought that instantiating ZClasses in python was confusing). I don't need to expose methods or restrict access, just open the attributes to be used as DTML variables. Are there ways to do this without making full-fledged ZClasses out of my classes? Are there guidelines in general for using non-Zopish subobjects that get used by the publishing process? -- Karl Anderson [EMAIL PROTECTED] http://www.pobox.com/~kra/ ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Please HELP: Nested ZClass, Nested instance
"Park, Karl" <[EMAIL PROTECTED]> writes: > I created a ZClass in the Product folder. And anther ZClass under the > ZClass(thus nested class) > To do it, I created a DTML Method which accepts user's input and then, if > needed, it have to create an object. > First part is to create the parent object, which works just fine. > But the sencond part to create the child object doesn't seem to work. > If I take the easy way, that is, creating othere ZClass on the top of the > products folder of Control Panel, I can do it. > But I don't think it is a good desing from the perspective of OOP I had some hassles with this recently. There's a HOWTO at: http://www.zope.org/Members/gtk/containers Can you create the child zclass from the manage screen inside the parent zclass? Does the parent zclass inherit from ObjectManager before any other superclasses? -- Karl Anderson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
