- Zope-Dev - Zope lists

Re: [Zope-dev] Stumped about handling this particularexception...
by skip＠mojam.com 30 Apr '99

30 Apr '99

>>>>> "Paulo" == Paulo Eduardo Neves <neves(a)inf.puc-rio.br> writes: Paulo> Another approach is to use javascript to validate it before Paulo> submitting it. A js library for this was posted sometime ago in Paulo> the zope list. It just guarantee that an invalid field won't be Paulo> submitted if ALL your users have javascript turned on. That's the rub. Since you can't guarantee that all your users have JavaScript enabled, you have to perform all the checks in the server anyway. Skip

1 0

Re: [Zope-dev] Stumped about handling this particular exception...
by Tres Seaver 29 Apr '99

29 Apr '99

Jim Fulton wrote: > Amos Latteier wrote: > > > > (snip) > > > It may be that ZPublisher doesn't have much business validating form input. > > I agree. ;) > > > When I complain to Jim Fulton that the converters are pretty lame he > > usually tells me that they are not for form validation, but for argument > > marshalling. > > Exactly. Input validation, error reporting, and other UI activities > should be done at a much higher level. ZPublisher is a very low-level > tool meant for basic communication. Actually, the ideal would be to have as much of the shallow, "pure UI" type validation happen on the client side: required fields, valid integers / dates / phone numbers, etc. Only "deep" validations (those which depend on actual business logic) should be done in Zope. I recall a chunk of DTML from this list which I used at one point (but can't find now :) to generate simple JavaScript validations, based on the converter types. Worked nicely, if in a fairly limited scope. > > Obviously, we made the mistake early on of introducting "required", > which really is an input validation feature. This was before we realized > that we couldn't hope to do a good job of validation at such a low level. > > > > Improving the ZPublisher converters is a worthwhile problem, IMO. > > I agree, It would be nice to do more sophisticated marshalling. ;) > > > In > > addition, making ZPublisher's error reporting more flexible is also a > > worthwhile project. > > Well, It would be worthwhile to make ZPublisher provide better hooks > to let application handle errors detected by ZPublisher. This is > definately on the to do list. > > I also think that a default value mechanism of some kind would > make sense. This would help in other situations too. I personally would like to see the default behavior for exception handling be to render the exception object as visible HTML. While a Python backtrace might be disconcerting to some users, the "sorry, this site is experiencing technical difficulties" is hardly less so. -- ========================================================= Tres Seaver tseaver(a)palladion.com 713-523-6582 Palladion Software http://www.palladion.com

1 0

Stumped about handling this particular exception...
by skip＠mojam.com 29 Apr '99

29 Apr '99

I asked this question in a different form before but got only silence from the list. I'll give it another try... I'm using ZServer and a snapshot of the Zope CVS directory. When a user of the web site fails to input a required form element, ZServer spits out Server Error: exceptions.ValueError, No input for required field<p>: file: /home/dolphin/skip/src/Zope/lib/python/ZPublisher/Converters.py line: 114 on the controlling terminal and the user sees Error response Error code 500. Message: Internal Server Error. instead of a useful message that will help the user figure out what they did wrong. This makes them think my web site is broken, when it's actually their input that's broken... I've tried tracing the control flow back from Converters.py. I manually figured out the following call chain: HTTPRequest.py, line 246 Publish.py, line 252 The three levels of try statement nesting in Publish.py made it unlikely that I would figure out precisely what happens from the failed Request(). I tried adding a little traceback printing to the field2required function: def field2required(v): if hasattr(v,'read'): v=v.read() else: v=str(v) if strip(v): return v try: raise ValueError, 'No input for required field<p>' except: import sys, traceback ty, va, tb = sys.exc_info() f = open("/tmp/traceback", "a") f.write("\n\n---- %s, %s ----\n" % (ty, va)) traceback.print_tb(tb, None, f) f.write("\n") f.close() raise but all it dumps in /tmp/traceback is information for a single line: ---- exceptions.ValueError, No input for required field performers<p> ---- File "/home/killer-whale/skip/src/Zope/lib/python/ZPublisher/Converters.py", line 115, in field2required raise ValueError, 'No input for required field %s<p>' % k Any reason why it won't show me more of the execution stack? I'm really flummoxed. Any feedback on this problem would be much appreciated. Skip Montanaro | Mojam: "Uniting the World of Music" http://www.mojam.com/ skip(a)mojam.com | Musi-Cal: http://www.musi-cal.com/ 518-372-5583

5 4

How to access the internals of Zope ?
by Hannu Krosing 28 Apr '99

28 Apr '99

How can I access (modify) the DTML for /manage frameset and possibly other management frames ? I want to make the management screens available through HTTPS only (to protect the innocent from revealing their passwords to sniffers), and I quess it would be trivial by adding something like  in a few places, but I have'nt been able to find the right places yet. Is it possible using the management interface, or do I have to access the BoboBase directly? Or would it be better to hack the UserDB and add a special flag to users who may authenticate through HTTPS only ? ---------------- Hannu

1 0

RE: [Zope-dev] Problem with DTML Batch Processing
by Michel Pelletier 28 Apr '99

28 Apr '99

> -----Original Message----- > From: David White [mailto:davew@ed.ray.com] > Sent: Wednesday, April 28, 1999 3:02 PM > To: zope-dev(a)zope.org > Subject: [Zope-dev] Problem with DTML Batch Processing > > > Hi, > > > I can go back to Python 1.5.1 with no problems, but I was > just wondering > > if anyone else had seen anything like this. All this is with Zope > 1.10.2 > on a Solaris 2.5.1 machine. If any Zopistas out there can shed some > light > on this, that would be great. > Dave, Thanks for the report. Please submit it to the Collector (http://www.zope.org/Collector) and we will make sure it gets fixed when we go to fix all the transition-to-1.5.2 bugs. For now, I suggest sticking to 1.5.1 for Zope which is the version 1.10.2 and the upcoming 1.11 have been extensively tested against. -Michel > Dave > > -- > ---------------------------------------------------- > David R. White Raytheon Electronic Systems > Process Support (508) 440-2087 > 528 Boston Post Rd. > Sudbury, MA 01776 > davew(a)ed.ray.com > ---------------------------------------------------- > > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (For non-developer, user-level issues, use the companion list, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) >

1 0

Problem with DTML Batch Processing
by David White 28 Apr '99

28 Apr '99

Hi, I've been playing around with Zope for quite some time now and have been very excited about some of the possibilities it presents. I've been particularly pleased with the simplicity and elegant power of the Batch Process capabilities withing DTML. Recently however I've run into a problem which appears to be a bug related to upgrading to Python 1.5.2. I have a bit of DTML like this (variable names changed to protect the innocent!):  ### Display column headers, records, etc  </table>  Next Sequences:  <a href="qs="> ( - )</a>     <p><b>Query Returned No Records</b></p>  Where 'some_sql_query' is an sql query against our Oracle database. This all works fine. I can retrieve the data and format it to my hearts content (very slick!). The problem is with the piece at the botton which uses the sequence-* and batch-* stuff. These pieces worked fine when I was using Python 1.5.1, but when I upgraded to Python 1.5.2 these display out something like this: Next Sequences: (32 - 32) (33 - 33) (34 - 34) (35 - 35) (36 - 36) (37 - 37) (38 - 38) (39 - 39) (40 - 40) (41 - 41) (43 - 43) (44 - 44) (45 - 45) (46 - 46) (47 - 47) (48 - 48) (49 - 49) (50 - 50) (51 - 51) (52 - 52) (53 - 53) (54 - 54) (55 - 55) (56 - 56) (57 - 57) (58 - 58) (59 - 59) (60 - 60) (61 - 61) (62 - 62) (63 - 63) (64 - 64) (65 - 65) (66 - 66) (67 - 67) (68 - 68) etc... What it should display (and used to...) something more like this: Next Sequences: (32 - 57) (58 - 68) I can go back to Python 1.5.1 with no problems, but I was just wondering if anyone else had seen anything like this. All this is with Zope 1.10.2 on a Solaris 2.5.1 machine. If any Zopistas out there can shed some light on this, that would be great. Dave -- ---------------------------------------------------- David R. White Raytheon Electronic Systems Process Support (508) 440-2087 528 Boston Post Rd. Sudbury, MA 01776 davew(a)ed.ray.com ----------------------------------------------------

1 0

Problems with ZServer
by Pavlos Christoforou 27 Apr '99

27 Apr '99

I am running the latest version of ZServer and occasionally ZServer crashes with the following traceback: Unhandled exception in thread: Traceback (innermost last): File "/home/pavlos/Zope-1.10.2-src/ZServer/PubCore/ZServerPublisher.py", line 97, in __init__ response._finish() File "/home/pavlos/Zope-1.10.2-src/ZServer/HTTPResponse.py", line 209, in _finish self.stdout.close() File "/home/pavlos/Zope-1.10.2-src/ZServer/HTTPResponse.py", line 235, in close self._channel.push(CallbackProducer(self._channel.done)) File "/home/pavlos/Zope-1.10.2-src/ZServer/HTTPServer.py", line 307, in push if send: self.initiate_send() File "/home/pavlos/Zope-1.10.2-src/ZServer/medusa/asynchat.py", line 199, in initiate_send self.refill_buffer() File "/home/pavlos/Zope-1.10.2-src/ZServer/medusa/asynchat.py", line 174, in refill_buffer p = self.producer_fifo.first() File "/home/pavlos/Zope-1.10.2-src/ZServer/medusa/asynchat.py", line 246, in first return self.list[0] IndexError: list index out of range Any ideas? Pavlos

1 0

REPOST: Timezones
by Robert Leftwich 26 Apr '99

26 Apr '99

I am re-sending this mail as I have not received any replies, surely somebody knows the answer. As I work in Australia I would like to add support for our timezones to the DateTime/DateTimeZone files. Adding the data to DateTime.py is fine but can anyone describe the format of the data in DateTimeZone.py as it somewhat cryptic to say the least ? TIA Robert Leftwich

2 2

RE: [Zope-dev] accentued character input
by Brian Lloyd 26 Apr '99

26 Apr '99

> Hello, > > Using accentued characters in properties (I'm french) can pose > problems. All editing forms in Zope and many products > I have seen are written as: > > ... > <input type=text name=field value=""> > ... > > But should be written as: > > ... > <input type=text name=field value=""> > ... Thanks for the report -- I've added it to the Collector. Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

accentued character input
by Service Informatique CHSR 26 Apr '99

26 Apr '99

Hello, Using accentued characters in properties (I'm french) can pose problems. All editing forms in Zope and many products I have seen are written as: ... <input type=text name=field value=""> ... But should be written as: ... <input type=text name=field value=""> ... Let the title be "Formulaire d'édition". I write: "Formulaire d'édition" on a Windows platform, which is correctly input into the base. But it is displayed as "Formulaire d'édition" (yo, viva HTML!). So, if I hit "Save changes" twice, "Formulaire d'édition" is put in the database. Now if I try to browse the document from Unix, I can see a little box instead of "é". Zope is not the only product affected by this. I had the same problem with TinyTable, and some others. My current Zope installation is heavily modified :-(, so I won't submit the patch, but you know what to do. PS: I should have used the Collector to report this, but I don't have access to internet today. What about a mail gateway to the Collector? Regards, Jephte CLAIN Service Informatique

1 0