- Zope-Dev - Zope lists

[Re: [Zope-dev] ZPatterns Documentation]
by Chris Withers 29 Jul '00

29 Jul '00

"Phillip J. Eby" wrote: > Despite the implications of the bait-and-switch subject line, I have not > yet written any substantial amounts of documentation. I have, however, > written this: > > http://www.zope.org/Members/pje/Wikis/ZPatterns/DataSkinsOverview Which was actually exceptionally useful, at least for me :-) Thanks, Chris PS: > Could anyone who gets a chance please give me some feedback? I'd like to > know if this is the kind of stuff that people would like to see more of, Yes please! :-) > whether it's too much detail, Perhaps still a little too much jargon still, if there's anything to complain about. I can't help thinking that a _really_ simple example that _only just_ uses the available features would help to make it real for people like me...

2 1

Re: [Zope-dev] New Client.py bug(?) in 2.2.0 affects ZScheduler
by Adam Karpierz 29 Jul '00

29 Jul '00

>In Zope version 2.2.0b3 Client.py calls connect in httplib (in two different >places) like this: > > sock.connect(self.host,self.port) > >In Zope version 2.2.0 (final) it's like this: > > sock.connect((self.host,self.port)) > >In the latter case, Python complains: > > TypeError: 'argument 1: ..., tuple found' > >Does anyone know what was the motivation for the change in the syntax for >the call to connect? > >Should I drop this in the Collector? It is of course a bug. I just was sent a patch to the Collector (http://classic.zope.org:8080/Collector/1480/view) because this bug is related to my previous patch #1427. -- Adam Karpierz karpierz(a)alpha.pl

1 0

New Client.py bug(?) in 2.2.0 affects ZScheduler
by Loren Stafford 28 Jul '00

28 Jul '00

In Zope version 2.2.0b3 Client.py calls connect in httplib (in two different places) like this: sock.connect(self.host,self.port) In Zope version 2.2.0 (final) it's like this: sock.connect((self.host,self.port)) In the latter case, Python complains: TypeError: 'argument 1: ..., tuple found' Does anyone know what was the motivation for the change in the syntax for the call to connect? Should I drop this in the Collector? -- Loren

2 1

PROPOSAL: Splitting ZPatterns into two products
by Phillip J. Eby 28 Jul '00

28 Jul '00

Many people have suggested splitting out the PlugIns part of ZPatterns as a seperate product for general Zope use. In addition to this, it is becoming clearer to me as I work on docs, etc., that there really is only one thing left in ZPatterns after you take out PlugIns, and that is DataSkins. (Pretty much everything else in ZPatterns only has meaning in relation to DataSkins.) So, I am thinking perhaps I should split ZPatterns into two products: PlugIns and DataSkins. The DataSkins product would require the PlugIns product. LoginManager would require both. For backward compatibility, there would need to be a "final release" of ZPatterns which contained stubs to load in classes from their new locations, so that existing objects stored in ZODB's would not be "broken". Newly created objects, of course, would refer to the new products automatically. The term "ZPatterns" would then go away, which is just as well because it doesn't really mean anything, anyway. :) Please let me know if you have any comments or questions on this. _____ _/__) ___/

4 7

Re: [Zope-dev] Re: [Zope-PTK] PROPOSAL: Splitting ZPatternsinto two products
by Chris Withers 28 Jul '00

28 Jul '00

"Phillip J. Eby" wrote: > DataSkins themselves, Okay, I'm being dumb again, but could someone explain to me how the name DataSkin came about and how it relates to what these objects do? :S > That might be, but the PlugIns part isn't really where it should be before > it could even be proposed to go into the Zope core. The biggest hurdle > remaining is full ZClass support. How does this interact with DC's plans to redo ZClasses? (although I'm not sure there are plans here yet, I just got the feeling there were..) > >Has anyone done anything with the 'glossary wiki' idea I punted out a > >while back? > > I don't believe so. But I think that splitting the package will make > documentation easier. Partly because it will allow starting from a fresh > viewpoint that is DataSkins-centric and more use-oriented. I figure on > leaving the ZPatterns Wiki alone for the most part until the DataSkins docs > start to mature, and then yanking out documentation-type stuff from the > ZPatterns Wiki and re-purposing it to focus on application design, object > modelling, and the like, in the context of the DataSkins and PlugIns packages. Sounds great :-) cheers, Chris

2 2

RE: [Zope-dev] Stuff hanging off user not in cookies
by Brian Lloyd 28 Jul '00

28 Jul '00

> Is there are reason why configuration info for the user > doesn't hang off > the user object and is instead stored in cookies? > > I'm thinking of the dimensions/etc of the edit boxes and the > like. I do > a lot of work through virtual domains and it's a real pain having to > resize that edit box every time I log in through a different domain or > on a different computer... Have you looked at the "Better User Management" proposal? One aspect of it is a better level of lowest-common-denominator support for extended attributes. I think that a prerequisite for what you are asking for is a well-defined interface for hanging extended attrs on users that can work reliably (or fail in a well-defined way) for whatever flavor of user source you are using. http://dev.zope.org/Wikis/DevSite/Proposals/BetterUserManagement Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

2 1

patches to make ZServer's http_request subclassable
by Brian Takashi Hooper 28 Jul '00

28 Jul '00

Hi all - I made a couple of patches to ZServer (medusa, actually) to make medusa'a http_request objects subclassable... the motivation is to make customizing medusa / ZServer's logging easier to do just overriding http_request's log() method in a subclass. Patches are attached to this message, suggestions welcome! --Brian Hooper Tokyo, Japan

1 0

"REQUEST" considered a string
by Rob Miller 28 Jul '00

28 Jul '00

The following DTML method works in Zope 2.1.6, but not in 2.2.0: ("testfs" is a LocalFS product installed in the method's folder) -------------------- <dtml-var standard_html_header> <dtml-call "REQUEST.set('spec', '*')"> <dtml-call "REQUEST.set('num_dir_columns', 3)"> <table> <dtml-call "REQUEST.set('ctr', 0)"> <dtml-in "testfs.fileValues(REQUEST.get('spec', _.None))"> <dtml-if "type == 'directory'"> <dtml-if "ctr % num_dir_columns == 0"> <tr> </dtml-if> <td><a href="<dtml-var URL1>/<dtml-var url>"><dtml-var "id"></a><br> <dtml-if "ctr % num_dir_columns == num_dir_columns - 1"> </tr> </dtml-if> <dtml-call "REQUEST.set('ctr', _.int(ctr) + 1)"> </dtml-if> </dtml-in> <dtml-comment> In case we end in the middle of a row... </dtml-comment> <dtml-if "ctr % num_dir_columns != 0"> </tr> </dtml-if> </table> <dtml-var standard_html_footer> ---------------------- The error that this causes in 2.2.0 is: ---------------------- Error Type: AttributeError Error Value: 'string' object has no attribute 'set ---------------------- The traceback reveals that the line where the error occurs is "<dtml-call "REQUEST.set('ctr', _.int(ctr) + 1)">". Zope is acting as though the REQUEST object is a string! I'm posting this to Zope-dev to see if any of you folks who are familiar with the innards can tell me if this is happening because there's a bug in 2.2.0, or if there's something that has changed within Zope that I need to account for in my code. If this is a bug, where is the proper place to report it? I've heard mention of something called a collector, but all of my searches on zope.org are resulting in error messages right now, so I don't know what it is or how to find it. thanks for any help or feedback, rob

1 0

Announce: ZScheduler alpha Version 0.0.7
by Loren Stafford 28 Jul '00

28 Jul '00

ZScheduler Version 0.0.7 Date: 2000/07/02 1. Fixed a bug that caused ZEvents to execute in the wrong context. 2. If the action method of a ZEvent raises an error, a traceback is written in the log. 3. Added a Trigger tab to the management screen for ZEvents which fires the event in the same context that the Dispatcher does, but without regard to the schedule. This helps immensely in debugging the DTML in the ZEvent. I've tested on: Win98 Zope 2.2.0b3 Solaris 2.6 Zope 2.1.4 Linux ?.? Zope 2.1.3 On the Linux configuration (my account at CodeIt Computing), most features work; however, the new Trigger tab does not behave correctly. Though the ZEvent method eventually executes correctly, it doesn't return anything to the client and Zope seems to lock up temporarily -- that is, it doesn't respond to other client requests. I don't have a Linux development system with which to track this down. Any help would be appreciated. Here's the code for the Trigger tab. Can you see anything wrong? ...or anything Linux and Zope 2.1.3 would find wrong? def manage_triggerZEvent(self, client=None, REQUEST=None, RESPONSE=None, **kw): """For use by the Trigger tab on ZEvent management page. Use for testing the ZEvent in a context that mimics that of Dispatcher. """ RESPONSE.setHeader('Content-type','text/plain') aurl=REQUEST['URL1'] furl=string.join((aurl, 'trigger'), '/') (headers,response)=Client.call(furl) # Fire event RESPONSE.setBody(headers) RESPONSE.appendBody('\n') RESPONSE.appendBody(response) Otherwise, ZScheduler is looking good. Let me know how it works for you. http://www.zope.org/Members/lstaffor/ZScheduler -- Thanks -- Loren

1 1

ZPatterns Documentation
by Phillip J. Eby 27 Jul '00

27 Jul '00

Despite the implications of the bait-and-switch subject line, I have not yet written any substantial amounts of documentation. I have, however, written this: http://www.zope.org/Members/pje/Wikis/ZPatterns/DataSkinsOverview DataSkins (formerly known as RackMountables) are central to the operation of ZPatterns, and I decided to take a whack at explaining them at an introductory (I hope) level, complete with a diagram. Could anyone who gets a chance please give me some feedback? I'd like to know if this is the kind of stuff that people would like to see more of, or whether it's too much detail, not enough, right questions, wrong questions... Just comment, please, preferably in e-mail via Zope-dev. Thanks. _____ _/__) ___/

2 2