- Zope-Dev - Zope lists

Re: Zope 2.4: Unicode, Berkeley Storage?
by Sin Hang Kin 22 Jun '01

22 Jun '01

I think bsddb3 only accept string not unicode string. rgs, Kent Sin

1 0

RE: [Zope-dev] Fishbowl not problem centered enough
by Jay, Dylan 22 Jun '01

22 Jun '01

> -----Original Message----- > From: Ken Manheimer [mailto:klm@digicool.com] > Sent: Thursday, 21 June 2001 2:53 AM > To: zope-dev(a)zope.org > Cc: Casey Duncan; Jay, Dylan; Paul Everitt; Jim Fulton > Subject: Re: [Zope-dev] Fishbowl not problem centered enough > > > On Wed, 20 Jun 2001 09:24:40 -0600, Casey Duncan <cduncan(a)kaivo.com> > wrote: > > > "Jay, Dylan" wrote: > > > > > > Fishbowl is a great idea but it seems to be that its > solution focused rather > > > than problem focus. Perhaps if you had a page that listed > all the problems > > > with zope or problems that need to be solved that isn't > as easy as it could > > > be with zope. > > I think it would be helpful to have a "big picture", with goals and > objectives, into which to fit the pieces - would that address > the kinds of > things you're talking about? "big picture" is good but its not what I mean. What I mean is a list like this ---------- ZODB is not fault tolerent - ZODBReplication No way to use Zope with source control - DirectoryStorage - ZODB - CVSStorage - ZODBFileSystemSynchronization Need clearer seperation between presentation and code - HiperDOM etc etc --------- What I'm suggesting is turning the focus on its head. If every day your looking at problems rather than proposed solutions it promotes the following - Ideas about alternative solutions - Focused debate about tradeoffs between alternatives - a clear way to determine priority of proposed solutions by determining priority of the problems they solve. People can vote on the problems to gauge the need in the community. This is something that you guys need. eg No one at work will take zope seriously if they can't use source control to intergrate into our existing processes. If I'm alone then thats cool, but if lots of people are in the same boat but arn't about mailing the dev list to tell everyone then you'll never know and lose all those potential zopisters. Voting could be done by giving each "problem" a page with a special tag. Every user gets 5 votes to place on any page with the tag. When ever the problem changes status then everyone who voted gets notified. When the problem is solved all those votes get refunded. If someones priorities change then they just move their votes around. (The java bug parage was an inspired idea IMHO) > > The fishbowl is also "pull" technology, and so it is > time-consuming to > > keep up with the developments. I personally find it to be > cumbersome, > > limiting and not really conducive to actually getting stuff done. > > I've really wanted to enable people to subscribe to notification about > changes to wiki pages, and to notifications about additions > to the wiki. > Unfortunately, i didn't have time to get to that in the WikiForNow > project. As soon as i'm clear form a current project i *may* > be able to > concentrate on at least formulating a reasonable > quick-and-dirty way to do > notifications, and getting it done for the short term. Whether or not > it's me doing it, i think we're going to be bringing more attention to > these issues. I wrote a quick and dirty one for this. I'll include the code at the bottom of the email. However someone recently suggested something better. The idea that you can send email to a wiki page. To take this futher imagine if every wikipage is a mailing list. Everyone who adds to it becomes a subscriber or you can subscribe manually to become a lurker. Then every update gets mailed to everyone. Then every reply becomes a comment at the end of the page. Perhaps every wikipage created from the original page inherits its subscribers. Of course you can unsubscribe at any time (have to be real easy to do like one click at bottom of email). Email addresses would be something like ZODBReplication(a)wiki.zope.org or something. So what problem does this solve? - Lack of awareness of wiki changes - Email discussion is easier than wiki discussion but essentially the same thing however they get recorded in different places with no connection between each other - No more "good idea, but record it on the wiki" comments Anyway the code I wrote (just for stright subscription) went like this. It relies on an XML document to keep the subscribers but that can be replaced by some kind of map. It also relies of ZCron to do the checks every 5min or so. If you guys added a flexible change notification hook (Listener talker pattern) it would make like much easier. eg The idea of subcribing to events on any object like "change" and "add" events. add_subscriber(self, user, page_name) ------------------------ doc = self.subscribers body = doc.getElementsByTagName('subscriptions')[0] n = doc.createElement('Notify') body.appendChild(n) p = doc.createElement('Page') p.appendChild(doc.createTextNode(page_name)) n.appendChild(p) u = doc.createElement('User') u.appendChild(doc.createTextNode(user)) n.appendChild(u) remove_sbscriber(self, user, page_name) ------------------------ doc = self.subscribers.getElementsByTagName('subscriptions')[0] sub = [] for e in doc.getChildNodes(): if e.getNodeType() == 1: page = e.getElementsByTagName('Page')[0].getFirstChild().getData() the_user = e.getElementsByTagName('User')[0].getFirstChild().getData() if page == page_name and user == the_user: doc.removeChild(e) return sub get_subscibers(self, page_name) -------------------- doc = self.subscribers.getElementsByTagName('subscriptions')[0] sub = [] for e in doc.getChildNodes(): if e.getNodeType() == 1: page = e.getElementsByTagName('Page')[0].getFirstChild().getData() if page == page_name: user = e.getElementsByTagName('User')[0].getFirstChild().getData() sub.append(user) return sub and then a ZCron run method doPageNotifications(self, lastUpdate) -------------------- res = [] for page in self.get_updated_pages(lastUpdate): for user in self.get_subscribers(page.id()): res.append((page,user)) self.mailNotification(self, None, user=user, page=page.id(), url=page.absolute_url()) return res

2 1

Zope 2.4: Unicode, Berkeley Storage?
by Randall F. Kern 22 Jun '01

22 Jun '01

I was just reading the Zope 2.4.0 plan on dev.zope.org, and I have two questions: 1. Will Unicode be supported (UTF-8 encoding) for results, posted data, marshaled arguments, etc? 2. Will the BDB storage be standard with 2.4? Transactional Undo sounds _very_ nice. Thanks, -Randy

3 2

RE: [Zope-dev] ZClass not in a Product
by Jay, Dylan 22 Jun '01

22 Jun '01

> -----Original Message----- > From: Chris McDonough [mailto:chrism@digicool.com] > Sent: Friday, 22 June 2001 2:42 PM > To: Jay, Dylan; 'Joachim Werner'; zope-dev(a)zope.org > Subject: Re: [Zope-dev] ZClass not in a Product > > > > > Now is there a technical reason why I can't have a ZClass inside any > folder? > > No. There is not code to allow this to happen in Zope, > however. I think at I know there is no code to do this. I'm asking how much code would be needed. Is it a major re-architecture? Is it something I could do? > some point, Lalo came up with a local factory product that > did something > like this. Not quite the same thing. I want local factory for local class.

2 1

RE: [Zope-dev] ZClass not in a Product
by Jay, Dylan 22 Jun '01

22 Jun '01

> -----Original Message----- > From: Joachim Werner [mailto:joe@iuveno-net.de] > Sent: Friday, 22 June 2001 11:01 AM > To: Jay, Dylan; zope-dev(a)zope.org > Subject: Re: [Zope-dev] ZClass not in a Product > > > > Is there any good reason why a Product inside the > ControlPanel is the only > > place a ZClass can exist? Why can't I have one in any folder? > > I think it is perfectly logical that ZClasses are located in > the Products > area. A folder is for instances of classes, and a ZClass is a > class, not an > instance. That doesn't answer my question. That answers the question of "Why are they kept in the control panel". Yet another question is "Why am I interested in putting ZClasses elsewhere?" which my help you if I answer. I would like to delegate responsibility for classes to different people. I would like to have class that only can be used in the certain subsection of a site I would like to be able to make a quick local specialization of a class. Similar to anonymous inner classes in Java I would like to be able to have my code in classes and my code in methods etc in the same place. I would like to be able to replace a folder with methods in that I was using as a pseudo class via aquisition into a full blown class with the absolute minumum of effort I would like to be able to create a quick class for use as a plugable brain and not have to create products for it or have it in a whole different part of my site. One part of OO says that things that are related should be close to each other. I could probably go on. Now is there a technical reason why I can't have a ZClass inside any folder?

2 1

and thanks
by Simon Michael 22 Jun '01

22 Jun '01

dtml-tree made me look good today :). Thanks DC!

2 1

Properties and ZClass instances
by Holger Lehmann 21 Jun '01

21 Jun '01

Ok Guys, I am lost :-( We have created a set of Functions to edit the Properties of our objects. The idea is based on the Howto called Editing Only Properties found at: http://www.zope.org/Members/rlgines/propertiesOnly We wrote a __init__.py file in a seperate Products folder that actually "patches" the PropertyManager object dynamically (e.g. without cahnging the original source). This works all pretty well for DTML Documents as well as other objects. Now I created a ZClass (my very own :-) ) and tried to use this very manage_editPropertiesOnly thing as well. Without the result I wanted. When I linked to http://somwhere/path/to/zclass/instance/propertysheets/props/manage_editPro… with props being the name of the property sheet defined under the Property Sheet tab of the Zope management screen. manage_editPropertiesOnlyForm is a 1:1 copy of the manage_editPropertiesOnly DTML Method with some user interface changes. Furthermore does it call a copy of the manage_editProperties python function called manage_editPropertiesForm. This Function again is a 1:1 copy of the original with the difference to redirect to a different URL instead to the Zope management screen. When called it shows all properties and the according values. When I hit save it tells me it saved the properties but nothing acually happened. I poked around the sourcecode but could not find any hints. I re-copied the functions to ensure I had the correct code but without any results. It tries to post the form data the URL http://somwhere/path/to/zclass/instance/propertysheets/props .... I am using Zope 2.3.0 and Zope 2.3.2. Our manage_editPropertiesOnly function works (so far) under 2.1.6 2.2.0 2.2.5 2.3.0 and 2.3.2 (verified) Any hints ? Thanks in advance, Holger -- ----------------------------------- catWorkX GmbH Dipl.-Ing. Holger Lehmann Stresemannstr. 364 22761 Hamburg Tel: +49 (0700) catWorkX Tel: +49 (40) 890 646-0 Fax: +49 (40) 890 646-66 mailto:lehmann@catworkx.de http://www.catworkx.de http://www.catbridge.de

2 1

Re: [Zope-dev] ZPL and GPL licensing issues
by Oliver Bleutgen 21 Jun '01

21 Jun '01

>> as i said before, writing gpl code subclassing zope is a non-sense. even >> the author cannot, imho, redistribute its work with a plain gpl attached >> to it. the gpl says that if you link with gpl code *all* the code should >> be gpl or gpl-compatible (major os components like clibs, compilers, etc >> are an exception). so even the author cannot do that without licensing >> under gpl plus some exception ("as a special exception you're allowed to >> link this code with zope or any other zope product distributed under the >> zpl".) see the (in)famous gpl vs. qt thread in the debian mailing lists >> for an in-depth analisys of this problem. > To me this is the key point. If you GPL license a product (or other > software) for Zope, you cannot subclass ZPL coded classes in your > product without violating the GPL. This makes a strict GPL license > nearly useless for Zope development and incompatible (license-wise) with > Zope itself. What bugs me is when people point to the ZPL being the > "problem", it is the GPL that is the limiting factor IMEHO. > -- > | Casey Duncan > | Kaivo, Inc. > | cduncan(a)kaivo.com > `------------------> Either this is wrong, or I don't get it. The GPL talks just about _distribution_ of a product, or more precisely, about the rights of _others_ for distribution. I can distribute my products with any license I want, who should have a problem with that and what license may be violated? To cite the GPL: "You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License." and "Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program. " and (from the GPL-FAQ): "Is the developer of a GPL-covered program bound by the GPL? Could the developer's actions ever be a violation of the GPL? Strictly speaking, the GPL is a license from the developer for others to use, distribute and change the program. The developer itself is not bound by it, so no matter what the developer does, this is not a "violation" of the GPL. However, if the developer does something that would violate the GPL if done by someone else, the developer will surely lose moral standing in the community. " I.e. I also can publish internet explorer specific javascript under the gpl (or vb-macros for that matter). and (also from the GPL-FAQ) "I'm writing a Windows application with Microsoft Visual C++ and I will be releasing it under the GPL. Is dynamically linking my program with the Visual C++ run-time library permitted under the GPL? Yes, because that run-time library normally accompanies the compiler you are using." The only problem I see is when someone (DC) wants to incorporate someone else's GPLed product together with zope, or when someone wants to modify someone elses GPLed zope product and distribute it. But I think even the second part isn't a problem, because the GPL says (under section 2, the "viral" part): "These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. " For me that means that as long as I distribute someone elses GPL'ed zope product without zope, it's ok. I guess that we all are in agreement that zope "can be reasonably considered independent and separate work in themselves". cheers, oliver

1 0

Re: restructuredtext
by Michel Pelletier 21 Jun '01

21 Jun '01

I've cc:ed zope-dev in case anyone else is interested. On Thu, 21 Jun 2001, David Goodger wrote: > The last time I downloaded and studied the CVS branch was in November 2000. > At the time, the code wasn't very inviting. I just downloaded the CVS branch > again, using the instructions in > http://dev.zope.org/Members/jim/StructuredTextWiki/NGReleases, and visited > http://dev.zope.org//Members/jim/StructuredTextWiki. The RecentChanges page > and the StructuredTextNT/CurrentStatus page both list several additions > which don't seem to be reflected in STNG.txt or the StructuredText.py module > docstring. Is this code up to date? If not, I would appreciate a pointer to > the latest code, or a source .tgz by email. The version in Zope CVS (the HEAD, not any branches) is the most current code. The branch was dinscontinued when we folded it into the head, so try checking out a full head branch and look there, you will probably notice many changes. > If you do have information on creating a language front-end parser for > STXNG, please send it. And please add links to my projects to the > appropriate Wiki pages if you have time. (Karl: everytime I say DOM, I mean "DOM-like"). Basicly, Zope's current "classic" front-end is defined in StructuredText/ST.py. In there, you will see a function called StructuredText that turns indented, newline separated text into StructuredTextParagraph DOM objects, that get inserted DOM tree-style into a StructuredTextDocument DOM object. I would suggest you start looking there, ie, turn your code into a simple, homogeonous StructuredText paragraphs. For example:: >>> foo = """Title ... ... One ... ... Two *three* ... ... o four ... ... o **five** ... ... """ >>> Basic(foo) StructuredTextDocument([ StructuredTextParagraph(Title, [ StructuredTextParagraph( One, [ ]) StructuredTextParagraph( Two *three*, [ StructuredTextParagraph( o four, [ ]) StructuredTextParagraph( o **five**, [ ]) ]) ]), ]) >>> The resultant object is a StructuredTextDocument DOM object with StructuredTextParagraph DOM children. After the very first step, you can work with the content using the DOM interface:: >>> Basic(foo).getNodeName() 'StructuredTextDocument' >>> Notice how the first pass *didn't* go through looking for markup, *just* for structure. We did this for simplicity and because our structure could be factored out of our markup, I'm not sure if you can do that, but I suspect you can define more complex rules to define what a 'paragraph' element is. The next step is to "colorize" the simple, homogeonous DOM into a more complex "Document" DOM object:: >>> Document(Basic(foo)) StructuredTextDocument([ StructuredTextSection(StructuredTextSectionTitle(Title, [ ]), [ StructuredTextParagraph( One, [ ]) StructuredTextSection(StructuredTextSectionTitle([' Two ', StructuredTextEmphasis('three')], [ ]), [ StructuredTextBullet(four, [ ]) StructuredTextBullet(StructuredTextStrong('five'), [ ]) ]) ]), ]) >>> Now you have a DOM object that fully expresses your textual language. Obviously, you could turn this right back into STX. The Document() factory accepts a "simple" STX DOM tree created by the Basic() factory. This factory goes through, using the DOM API, looking for our special markup, and then colorizing that markup by adding new, more specialized DOM objects (like StructuredTextBullet and StructuredTextEmphasis). The final step is to feed the colorized DOM into an output generator. This is a factory that accepts a DOM object and returns a string of that object in a certain format. As an example, STXNG comes with HTML, MML (framemaker) and DocBook generators:: >>> HTML(Document(Basic(foo))) '<html>\n<head>\n<title>Title</title>\n</head>\n<body>\n<h0>Title</h0>\n<p> One</p>\n<h1> Two <em>three</em></h1>\n\n<ul>\n<li>four</li>\n<li><strong>five</strong></li>\n\n</ul>\n</body>\n</html>\n' >>> So what you would do is to create your own "frontend" that can turn your reStructuredText into a simple DOM consisting solely of 'paragraphs', whatever that means to you. In the case of STX, indentation and newlines define paragraph structure. In reSTX, you may have different ways of marking up document structure. I suspect your parsing rules will be more complex, and that you've probably already written that piece. DocumentClass.py contain a class for each type of markup STX defines. All of these classes subclass the StructuredTextParagraph DOM object. These DOM objects will get created when the DocumentClass.DocumentClass class encounters your markup as it parses your Basic DOM. The DocumentClass.DocumentClass class has doc_* methods that get called on every paragraph node in your Basic DOM. Each method has an associated regular expression that is used to match occorances of your markup. Some of them, like doc_table, are very complex, but others like doc_emphasize are pretty simple. You would write one subclass of StructuredTextParagraph and one of these methods for each kind of your markup. So you can subclass DocumentClass to specialize and extend it to recognize the markup in your simple DOM (and reuse any coincidental features with StructuredText). The Document class is very simple, but you will need some understanding of regular expressions to customize it. I suspect that using STXNG, just for its DOM, will save you many, many hours of time that you would need to re-create something as flexible (the DOM is, after all, a very rich API). Since STXNG comes in three distinct peices, you can thrown away the first piece and replace it with your own, specialize the second piece, and totally re-use the third. Hope that helps, -Michel

1 0

RE: [Zope-dev] ZPL and GPL licensing issues
by Toby Dickenson 21 Jun '01

21 Jun '01

> > >and the 'obnoxious advertising clause' > > >seemingly puts a stop to it.. > > > > I understand that 'obnoxious advertising clause' is the > phrase used by > > the FSF to describe this type of license clause, however I wonder > > whether you (personally, or as an organisation) really find it to be > > 'obnoxious'? > > > > Personally, I am *happy* to respect clause 4. > > Please, don't try to critize the FSF just for the fun of it. I did not intend any fun, nor criticism. > Have you read the FSF's comment about the original 'obnoxious > advertising > clause' ? The problem is a practical one, and a real one: The old BSD > license said that, if you incorporated their code in your > product, every > advertisement for your product had to carry this line: > > This product includes software developed by the University of > California, Berkeley and its contributors. Yes, but thats *not* what the ZPL clause 4 says. ZPL says you only need to include the acknowledgement in an advertisement "mentioning features derived from or use of this software". As I read this you need not include the acknowlegement if your advertisement: a. does not mention features derived from Zope b. does not mention that it uses Zope

2 1