- Zope - Zope lists

RE: [Zope] defining a method from a ZClass
by Michel Pelletier 22 Jun '99

22 Jun '99

> -----Original Message----- > From: Petru Paler [mailto:ppetru@bv.ro] > Sent: Monday, June 21, 1999 1:16 PM > To: zope(a)zope.org > Subject: [Zope] defining a method from a ZClass > > > How can I hook a method from a ZClass to its parent folder ? > Could you be more specific in what this means? -Michel > -Petru > > _______________________________________________ > Zope maillist - Zope(a)zope.org > http://www.zope.org/mailman/listinfo/zope > > (For developer-specific issues, use the companion list, > zope-dev(a)zope.org - http://www.zope.org/mailman/listinfo/zope-dev ) >

2 1

RE: [Zope] ANNOUNCE: Z Classes Tutorial Update
by Amos Latteier 22 Jun '99

22 Jun '99

> Thanks Amos that really looks great. Thanks! > I have a general question about ZClasses: Why can they only > be used via > creating a Product? Um, I believe that the rational is that the Control Panel provides a centralized location for creating new Zope objects. A Product Folder is just a way of compartmentalizing Zope extensions. The Control Panel is just a way of containing those extensions. > Seems like that kind of defeats part of > the purpose > of having ZClasses -- freeing people from writing Python methods in a > lot of cases (which requires superuser priveledges). By only > being able > to add ZClasses through the Product interface, one has to > have superuser > priveledges to create ZClasses, right. I'm not sure where you got that idea. To my knowledge you can create Products in the Control Panel without being the "super manager". Though you do need to have the "Manager" role. Did you try creating a Product in the Control Panel and run into access problems? > What would be much nicer is for ZClasses to be creatable at > any level in > the Zope heirarchy. We've talked about being able to have multiple Control Panels at different levels in the Zope hierarchy, so that Control Panel setting are not global. This change is a ways off yet, and is not necessary in order to use Z Classes. -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com

2 1

ANNOUNCE: Zope 2.0 alpha 3 is available
by Jim Fulton 22 Jun '99

22 Jun '99

See: http://www.zope.org/Download/Releases/Zope-2.0.0a3 Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

1 0

The wrong content type
by Alexander Staubo 21 Jun '99

21 Jun '99

I just discovered that DTML Documents and Methods containing "special" characters are deemed by ZServer to be binary (that is, "Content-Type: application/octet-stream"), and not HTML. The special characters I refer to are part of the Windows ANSI (ISO-8859-1, I believe) character set, and the inclusion of characters such as em-dash (#150) instead of character reference entities (eg., ), while not entirely correct HTML, should not automatically demote the document to binary, should it? When, at all, would it be appropriate to assume that a DTML Document contains binary data? Aren't DTML Documents by definition text? -- Alexander Staubo http://www.mop.no/~alex/ "It has taken the planet Earth 4.5 billion years to discover it is 4.5 billion years old." --George Wald

1 0

RE: [Zope] Fixing refresh problems
by Alexander Staubo 21 Jun '99

21 Jun '99

What's extra super weird is that it returns a correct Date field. Look at this HTTP output: HTTP/None 200 OK Server: Zope/Zope 1.11.0pr1 (binary release, python 1.5.1, win32-x86) ZServer/1.1b1 Date: Tue, 22 Jun 1999 00:08:26 GMT Content-Type: text/html Content-Length: 5974 Last-Modified: Mon, 21 Jun 1999 23:08:17 GMT It may not look funny until you consider that this document was modified 9 seconds before the GET request occurred. In other words: The Date field is correct; Last-Modified is off by an hour. -- Alexander Staubo http://www.mop.no/~alex/ "It has taken the planet Earth 4.5 billion years to discover it is 4.5 billion years old." --George Wald >-----Original Message----- >From: zope-admin(a)zope.org [mailto:zope-admin@zope.org]On >Behalf Of Brian >Lloyd >Sent: 21. juni 1999 19:44 >To: 'Alexander Staubo'; Zope Mailing List (E-mail) >Subject: RE: [Zope] Fixing refresh problems > > >> What seems evident is that newer browsers such as IE 5.0 do not heed >> Pragma and Expires headers correctly. The solution is to provide the >> Cache-Control header, which supersedes the "Pragma: no-cache" >> header in >> HTTP 1.1, thus: >... >> What bugs me is that ZServer doesn't handle If-Modified-Since >> correctly, >> or doesn't seem to. Telnetting to ZServer and typing a future >> date value >> doesn't elicit the expected 304 error ("Not modified"). > >I tried putting handling in for this recently, with pretty >bad results... a number of browsers seemed to have problems >with 304's implemented, so I took them back out. I could, >of course, have been doing something stupid that caused the >odd (hanging) behavior in some clients, so if anyone wants >to implement If-Modified-Since handling, I'd be happy to roll >it in if it is thoroughly tested and found not to cause any >problems with any known clients... > >> Also, for me, >> ZServer returns a Last-Modified timestamp that is an hour off. The >> DateTime module seems to be slightly brain damaged in its handling of >> time zones; if a document was modified at 18:00 GMT+1 (which >> is my time >> zone), ZServer will emit: >> >> Last-Modified: Mon, 21 Jun 1999 16:00:00 GMT >> >> I've never been a wizard with date arithmetic, but this >looks weird to >> me: When my local time is 18:00, this is 17:00 GMT time. Is >> this perhaps >> related to the timezone bug that Dylan Jay posted a fix for a while >> back? > >No, this probably reflects daylight savings time not being >handled correctly... which is unforunately a *hard* problem >(with a capital H :). The DT module tries to deal with this >as best it can, but zones for which there is no information >in it's pre-fab database are probably mishandled during DST. > >Do you happen to know if mxDateTime or any of the other date/ >time handling packages out there handle DST in arbitrary >timezones? Perhaps there is something we could learn from one >of those... > > >Brian Lloyd brian(a)digicool.com >Software Engineer 540.371.6909 >Digital Creations http://www.digicool.com > > > > >_______________________________________________ >Zope maillist - Zope(a)zope.org >http://www.zope.org/mailman/listinfo/zope > >(For developer-specific issues, use the companion list, >zope-dev(a)zope.org - http://www.zope.org/mailman/listinfo/zope-dev ) >

1 0

ZClasses Tutorial
by Fitzgerald Steele, Jr. 21 Jun '99

21 Jun '99

I'm sorry...I know Amos just wrote a ZClasses tutorial, but I can't find it on the Zope site...where is that again? Thanks, Jerry

2 1

JOBOP Director of Software Development
by 915602＠candseek.com 21 Jun '99

21 Jun '99

Since your email address was listed on a related web site page or database, I thought you might help. I am seeking an individual within the following conditions: I represent a leader in providing interactive Information Technology services, particularly new media self-service applications, in the United States. Currently they are looking for a Director of Software Development for their Southern Connecticut office. In this role, an individual will provide technical leadership to Project Managers and programmers working on a variety of internal and external development projects. In addition, the Director or Software Development will be responsible for Quality Assurance, Human Resources Management, and Technical Sales Support. The ideal candidate will have at least 5 years of experience managing a software development department or team in a structured company environment with world class processes and quality assurance, preferably ISO 9000. Knowledge of Internet technology and programming languages in the Unix and Microsoft environments, including HTML, Java, Javascript, CGI, Perl, C/C++, ASP, or Visual Basic, is preferred. In order to effectively manage the software development group, the manager must have a solid understanding of both large and small scale relational database technology and design. For the right person, the salary can go as high as $100,000 with generous bonuses and a great benefits package. Geographic Location of Position: Branford, CT If you know anyone that might be interested, please forward this to them or contact: Megan McCullough Diedre Moire Corporation Voice: 609-584-9000 ext 275 Fax: 609-584-9575 Email: 915602(a)candseek.com To permanently discontinue receiving employment opportunity notices from any and all help wanted advertisers using the Candidate Seeker system, click your "Reply" button and type the word "re- move" without spaces between the letters into the SUBJECT field then click the "Send" button. Your email address will be permanently filtered from ALL future job opportunity notifications sent via the Candidate Seeker system. To temporarily filter employment opportunity notices sent via the Candidate Seeker system, type the acronym "JOBOP" into your subject filter. All employment opportunity notices sent via the Candidate Seeker system contain the acronym "JOBOP" in the subject so they may be easily filtered or blocked if so desired. Other email addresses may be permanently deleted from future contact by emailing a single blank message from the desired address to nomail(a)candseek.com. Enter additional addresses into the body of the message and they will also be added to the "nomail" list Please feel free to contact the candidateseeker.com feedback line at 609-584-5499. Do not use this number for job related questions. All job related questions should be directed to the employer by replying to contact addresses or phone numbers indicated at the end of the job description message.

1 0

Fixing refresh problems
by Alexander Staubo 21 Jun '99

21 Jun '99

What seems evident is that newer browsers such as IE 5.0 do not heed Pragma and Expires headers correctly. The solution is to provide the Cache-Control header, which supersedes the "Pragma: no-cache" header in HTTP 1.1, thus: Cache-Control: no-cache The header permits other settings such as max-age (a variation of expiry). See the HTTP 1.1 spec for more information. The header can be emitted through a DTML Method in two ways: 1) Doing this:  2) Putting this inside the HTML <head> block: <meta http-equiv="Cache-Control" contents="no-cache"> This works with ZServer 1.11.0pr1 on NT. What bugs me is that ZServer doesn't handle If-Modified-Since correctly, or doesn't seem to. Telnetting to ZServer and typing a future date value doesn't elicit the expected 304 error ("Not modified"). Also, for me, ZServer returns a Last-Modified timestamp that is an hour off. The DateTime module seems to be slightly brain damaged in its handling of time zones; if a document was modified at 18:00 GMT+1 (which is my time zone), ZServer will emit: Last-Modified: Mon, 21 Jun 1999 16:00:00 GMT I've never been a wizard with date arithmetic, but this looks weird to me: When my local time is 18:00, this is 17:00 GMT time. Is this perhaps related to the timezone bug that Dylan Jay posted a fix for a while back? -- Alexander Staubo http://www.mop.no/~alex/ "It has taken the planet Earth 4.5 billion years to discover it is 4.5 billion years old." --George Wald

2 1

RE: [Zope] Fixing refresh problems
by Alexander Staubo 21 Jun '99

21 Jun '99

>-----Original Message----- >From: Brian Lloyd [mailto:Brian@digicool.com] >Sent: 21. juni 1999 19:41 >To: 'Alexander Staubo'; Zope Mailing List (E-mail) >Subject: RE: [Zope] Fixing refresh problems > > >> What seems evident is that newer browsers such as IE 5.0 do not heed >> Pragma and Expires headers correctly. The solution is to provide the >> Cache-Control header, which supersedes the "Pragma: no-cache" >> header in >> HTTP 1.1, thus: >... >> What bugs me is that ZServer doesn't handle If-Modified-Since >> correctly, >> or doesn't seem to. Telnetting to ZServer and typing a future >> date value >> doesn't elicit the expected 304 error ("Not modified"). > >I tried putting handling in for this recently, with pretty >bad results... a number of browsers seemed to have problems >with 304's implemented, so I took them back out. I could, >of course, have been doing something stupid that caused the >odd (hanging) behavior in some clients, so if anyone wants >to implement If-Modified-Since handling, I'd be happy to roll >it in if it is thoroughly tested and found not to cause any >problems with any known clients... That's odd. Apache and IIS both support and use the If-Modified-Since header, and I have experienced no client-side problems with this (Netscape 3.0 and later, IE 4.0 and later). What I notice is that Apache emits the ETag header, which is something Zope (ZServer) should do, as well. It's probably not related to your problem, but it would assist browsers in caching contents. >> Also, for me, >> ZServer returns a Last-Modified timestamp that is an hour off. The >> DateTime module seems to be slightly brain damaged in its handling of >> time zones; if a document was modified at 18:00 GMT+1 (which >> is my time >> zone), ZServer will emit: >> >> Last-Modified: Mon, 21 Jun 1999 16:00:00 GMT >> >> I've never been a wizard with date arithmetic, but this >looks weird to >> me: When my local time is 18:00, this is 17:00 GMT time. Is >> this perhaps >> related to the timezone bug that Dylan Jay posted a fix for a while >> back? > >No, this probably reflects daylight savings time not being >handled correctly... which is unforunately a *hard* problem >(with a capital H :). The DT module tries to deal with this >as best it can, but zones for which there is no information >in it's pre-fab database are probably mishandled during DST. > >Do you happen to know if mxDateTime or any of the other date/ >time handling packages out there handle DST in arbitrary >timezones? Perhaps there is something we could learn from one >of those... Never having used mxDateTime, I can't tell. However, why do we need to bother with DST at all? On Windows, at least, DST handling is generously wrapped into the time APIs (although there are functions to obtain it separately); if all you need is to obtain the current time, what's keeping you? Am I missing something? (I admit I have not studied DateTime.py a lot.) -- Alexander Staubo http://www.mop.no/~alex/ "It has taken the planet Earth 4.5 billion years to discover it is 4.5 billion years old." --George Wald

1 0

RE: [Zope] Fixing refresh problems
by Brian Lloyd 21 Jun '99

21 Jun '99

> What seems evident is that newer browsers such as IE 5.0 do not heed > Pragma and Expires headers correctly. The solution is to provide the > Cache-Control header, which supersedes the "Pragma: no-cache" > header in > HTTP 1.1, thus: ... > What bugs me is that ZServer doesn't handle If-Modified-Since > correctly, > or doesn't seem to. Telnetting to ZServer and typing a future > date value > doesn't elicit the expected 304 error ("Not modified"). I tried putting handling in for this recently, with pretty bad results... a number of browsers seemed to have problems with 304's implemented, so I took them back out. I could, of course, have been doing something stupid that caused the odd (hanging) behavior in some clients, so if anyone wants to implement If-Modified-Since handling, I'd be happy to roll it in if it is thoroughly tested and found not to cause any problems with any known clients... > Also, for me, > ZServer returns a Last-Modified timestamp that is an hour off. The > DateTime module seems to be slightly brain damaged in its handling of > time zones; if a document was modified at 18:00 GMT+1 (which > is my time > zone), ZServer will emit: > > Last-Modified: Mon, 21 Jun 1999 16:00:00 GMT > > I've never been a wizard with date arithmetic, but this looks weird to > me: When my local time is 18:00, this is 17:00 GMT time. Is > this perhaps > related to the timezone bug that Dylan Jay posted a fix for a while > back? No, this probably reflects daylight savings time not being handled correctly... which is unforunately a *hard* problem (with a capital H :). The DT module tries to deal with this as best it can, but zones for which there is no information in it's pre-fab database are probably mishandled during DST. Do you happen to know if mxDateTime or any of the other date/ time handling packages out there handle DST in arbitrary timezones? Perhaps there is something we could learn from one of those... Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0