- Zope - Zope lists

Re: [Zope] Render SQL method as lines
by Rich Young 20 Mar '01

20 Mar '01

Kenneth- How about <dtml-in getNames> <dtml-var name><dtml-var expr="_.chr(13)"><dtml-var expr="_.chr(10)"> </dtml-in> The expr="_.chr(#)" gives you the ASCII value corresponding to that number -- here, it's carriage return/line feed, which should return query results separated by lines --Rich > How do I render a SQL method as lines ? > > I'd like to make a DB lookup for a Multi-Selection property. > > This is my DTML method (getNames is a SQL method): > <dtml-in getNames> > <dtml-var name> > </dtml-in> > But this renders as a string which is not compatible... > Regards

2 1

Re: [Zope] Zope security management
by Dieter Maurer 20 Mar '01

20 Mar '01

Simon Michael writes: > I agree with John that this is a weakness in the current system. I > have often found myself wishing for something like tri-state > checkboxes (grant/deny/don't care). > > Would it be correct to say this is not a limitation of the zope > security model, but a user interface issue ? Yes, as you can already get what you want: When you uncheck the acquire checkbox, you can explicitly control (locally) which roles have the respective permission independant of any setting higher up in the hiararchy. Thus, your third state is not locally at each cell but sticks to a complete permission role. Dieter

8 9

RE: SV: [Zope] Render SQL method as lines
by Capesius, Alan 20 Mar '01

20 Mar '01

A list of brains? lol, could be handy for medical apps I suppose..... :) >>>-----Original Message----- >>>From: Casey Duncan [mailto:cduncan@kaivo.com] >>>Sent: Tuesday, March 20, 2001 12:21 PM >>>To: ke(a)younameit.dk >>>The SQL method returns a list of brains. The DTML Method returns a

1 0

RE: [Zope] Problems with *BIG* SQL queries
by Capesius, Alan 20 Mar '01

20 Mar '01

I've seen the same problem, but was able to workaround by having the SQL server do the totalling. If you are doing any calcs in the DTML, try moving them to the SQL as calculated fields. This will reduce the load on Zope. Zope seems to have a big problem preparing large calculated results through DTML calculations. External methods might help. The Zope server side page build process is probably taking a long time, you can determine this by adding a <dtml-var "ZopeTime()"> to the start and end of your page and comparing the times. The sequence looks like this: 31000 records, three fields w/Zope server running dual 266mhz and SQL Server running dual 1GHz. Client request to Zope .1 sec Zope request to SQL Server .1 sec SQL response to Zope 22 sec Zope internal 115 sec Zope response to client 3 sec(600mhz client) - 30 sec (dual 266mhz client) If as others have suggested, this is a browser rendering problem, you could easily determine this by removing all HTML table coding from your page and dumping straight text to the browser. That way there are no client side rendering delays. In my experience, you will need to significantly increase client processor speed to correct this. OR... break your output into separate tables. This improves browser rendering time. For instance, 31000 records displaying 3 fields without tables renders in 2 seconds, but requires just under 2 minutes for Zope to prepare the page for the client. With tables, the client pretty much never responds. (10 minutes+) However, the Zope response time is similar with or without tables. Here's an example of how I break the tables down for better rendering. This increases the Zope calc time (from 2 minutes to 3 minutes in my sample test) but the browser rendering only takes about 10 seconds: <dtml-var standard_html_header> <dtml-var "ZopeTime()"> <dtml-call "REQUEST.set('count', 0)"> <TABLE> <dtml-in allorders> <dtml-call "REQUEST.set('count', count+1)"> <dtml-if "count>100"> </TABLE><TABLE> <dtml-call "REQUEST.set('count', 0)"> </dtml-if> <TR><TD><dtml-var itemno></TD><TD><dtml-var desc></TD><TD><dtml-var datelastmn></TD></TR> </dtml-in> </TABLE> <dtml-var "ZopeTime()"> <dtml-var standard_html_footer> If you are using ZODBCDA for this and are seeing site delays as result of long running queries, try ZmxODBC instead. It will allow multithreading. Alan Capesius, MCSE/NTCIP+20 Technical Support Engineer Sysmex Corporation of America capesiusa(a)sysmex.com Zope+NT: http://twsite.bizland.com/zopetips.htm >>>-----Original Message----- >>>From: Mayers, Philip J [mailto:p.mayers@ic.ac.uk] >>>Sent: Sunday, March 18, 2001 9:17 AM >>>To: 'zope(a)zope.org' >>>Subject: [Zope] Problems with *BIG* SQL queries >>> >>>And no, I don't want to batch the results up. Any ideas? Is >>>it just the dtml >>>processing that's slowing it down? If so, how can I speed it up >>>(PythonScript to generate the HTML?)

1 0

Re: Fwd: [Zope] (no subject)
by Federico Di Gregorio 20 Mar '01

20 Mar '01

> fog(a)mixadlive.com said: > > if you want to use the per-cursor commit extension of psycopg, you > > need to call the .commit() method on the *cursor*. calling it on the > > connection will commit on all the cursors derived from the connection. > > I know (I wrote ODBC drivers for a living, among others a PostgreSQL one > :-)). I sorta expected the Z SQL Connection to do the "right thing", but it > forwards the TM messages to the connection, not to individual cursors. zope has to cope with drivers that are *not* thread safe at level 2 (see the Python DBAPI) and the cursor commit is an extension, not implemented by other drivers. so Zope does the right thing and uses 1 connection per thread. > > mmm... i think that zope instantiate a connection for every thread. in > > the psycopg case, every zope thread gets one connection and one > > cursor. > > Let's hope so, although I haven't been able to discern the code that does > that bit of magic. Is there a document somewhere that describes what Zope > does, thread-wise, when handling requests? Zope documentation is, mmm... i little bit difficult to find. usually i just read the sources and cross my fingers... > Anyway, I plunged into my code and FYI, this is how I'm now dealing with it: > > - select statements grab and release a cursor; > - update statements grab a cursor, wrap them in a TM subclass and register > the result with the transaction manager. The cursor is also registered in a > thread map, so that subsequent update statements in the same > thread/transaction reuse the cursor. When the Zope TM calls > finish()/abort(), the cursor is committed and released (and removed from the > thread map). > - session access (updating the "last accessed" timestamp on mostly every > request) is done through a special global cursor, which does a commit every > 10 or so updates keeping disk write load for this non-critical piece of > information low. > > The end result is acceptably low connection usage and correct transaction > scoping. pretty nice! will this stuff be released in a Zope Product? ciao, federico -- Federico Di Gregorio MIXAD LIVE Chief of Research & Technology fog(a)mixadlive.com Debian GNU/Linux Developer & Italian Press Contact fog(a)debian.org Qu'est ce que la folie? Juste un sentiment de liberté si fort qu'on en oublie ce qui nous rattache au monde... -- J. de Loctra

2 1

Re: [Zope] Zope security management
by The Famous Brett Watson 20 Mar '01

20 Mar '01

[Say 'hi' to the Zope newbie, everyone.] I'd like to put in my 2c worth regarding the security management discussion with particular reference to the encryption side of things, then I have a small question. Whilst it would be possible to do encrypted authentication with forms and Javascript that does a one-way hash (like MD5) using a challenge-response type of protocol, I agree with the previous poster who said that this would not be worth it when SSL is an option. SSL can be obtained (I believe) without the overhead of Apache by using an SSL wrapper. There is a program available (it's in Debian, for example) called "sslwrap" which negotiates SSL connections and then forwards the unencrypted content somewhere else. If you forward to the local host, then the unencrypted data does not travel over the network. The main disadvantage here is that Zope thinks all such connections originate at the local host, and your server logs become somewhat less interesting for that fact. What I prefer to do personally, when remotely managing my site, is to use SSH tunnels. I ssh to my Zope-box, then forward port 8080 to 127.0.0.1:zope-port at the other end. This also has the effect that all connections appear to come from the local host, but I use this fact to advantage. First, it allows me to filter out my own administrative accesses from the server log with ease, leaving actual "customer page views" behind. Second, as an added security measure I specify "localhost" as the domain for my administrative account. This prevents anyone from accessing the account without first gaining access via ssh. My question: am I right in believing that "localhost" in the /domains/ field of the user form has this effect? It seems to, but all the examples show right-hand-parts of domains rather than hostnames. Note that giving ignorant end-users ssh access does not mean you also have to give them shell access. It's possible to launch them into a menu-driven system, and the ssh tunnels will still work. Tera Term is a good free Win32 telnet client that has an ssh extension available for it. Regards, TFBW

7 9

Manipulate permissions
by David Kyte 20 Mar '01

20 Mar '01

Anyone know how to manipulate permissions in dtml. I would like to remove the view inherit permission. Any takers? Thanks Dave

1 0

SV: SV: [Zope] Render SQL method as lines
by Kenneth Ellested 20 Mar '01

20 Mar '01

This was excactly what I needed ! list = [] for row in context.sqlMethod(context.REQUEST): list.append(row.field) return list Thanks !

1 0

SV: [Zope] Render SQL method as lines
by Kenneth Ellested 20 Mar '01

20 Mar '01

Hmmm... not yet ! I was trying to convert a SQL method into lines, which as far as I can understand is newline terminated (LF?). I think that my attempt below returns CR/LF. When I try to insert a new property (multiple selection) in another object, and add my DTML method as the value parameter, zope says "Strings are not allowed as input to the in tag". If I specify the SQL method directly, I get the row objects (I think), and not the actual column. So I'd like to transform the SQL column into lines... Hope you understand what I mean ! Thanks -----Oprindelig meddelelse----- Fra: zope-admin(a)zope.org [mailto:zope-admin@zope.org]Pa vegne af tom smith Sendt: 20. marts 2001 18:14 Til: Kenneth Ellested; zope(a)zope.org Emne: Re: [Zope] Render SQL method as lines on 20/3/01 4:21 PM, Kenneth Ellested at ke(a)younameit.dk wrote: > How do I render a SQL method as lines ? > > I'd like to make a DB lookup for a Multi-Selection property. > > This is my DTML method (getNames is a SQL method): > <dtml-in getNames> > <dtml-var name> > </dtml-in> add... <dtml-call "RESPONSE.setHeader('Content-Type', 'text/plain')"> ...and it should work tom _______________________________________________ Zope maillist - Zope(a)zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

2 1

PROBLEM(100) ZServer warning
by Ricardo Bermell 20 Mar '01

20 Mar '01

What does it mean "PROBLEM(100) ZServer warning"? My Zope crashes continuously giving this message: "PROBLEM(100) ZServer warning: server accept() threw an exception" (but doesn't say what exception, nor any useful info) I have installed Zope-2.3.1b1, on OpenBSD 2.7, with Apache 1.3.19. I've tested these three combinations for installing Zope with Apache: * PCGI * FastCGI thru socket * FastCGI thru port None of them runs without at least ocasional crashes in my server. The worst (for my installation) is PCGI, wich today has been annoying me with a "PROBLEM(100)" crash almost every five minutes (while administrating my site). What does it mean "PROBLEM(100)"? In what manual or documentation can i interpret the code 100? How can i get more info in the logs about the error? (The Z2.log does not give more info than the mentioned message) Now i have "FastCGI thru port", running 1 hour without problems after only one "PROBLEM(100)" crash at the beginning of that hour. The next thing i'm going to try is Zope-2.3.0 instead of Zope-2.3.1b1, and if it also fails, then Zope without Apache. (I barely remember that i tested Zope.2.3.0 with PCGI and yet appeared the magic number 100, but i will re-test it anyway) -- Ricardo

1 0