March 2001 - Zope - Zope lists

Re: AW: [Zope] manage_clone - Pleeeease help !!!
by Dieter Maurer 20 Mar '01

20 Mar '01

Marc Fischer writes: > But I think I don't understand the syntax of Dtml/ Python! I never now what > syntax to use like ... _.[xxx] or _['xxx'] or ... or what ever. > > Perhabs someone could tell me where to start learning. It's really difficult > to understand !!!! I suggest, you look at the "Name lookup" section of URL:http://www.dieter.handshake.de/pyprojects/zope/book/chap3.html Dieter

1 0

Re: [Zope] dtml login
by Dieter Maurer 20 Mar '01

20 Mar '01

David Kyte writes: > I want to create a DTML method/form that provides > a login for other areas of the site ie form > contains username/password text boxes and > then forwards to userfolder protected areas. > > I presume that some manipulation of REQUEST is required. You may have a look at Shane "CookieCrumber" product (--> zope.org) Dieter

1 0

Re: [Zope] PDF Files
by Dieter Maurer 20 Mar '01

20 Mar '01

Kenneth Ellested writes: > Can Zope (ZCatalog) index PDF files ? If you provide a method that extracts the text for the PDF.... Dieter

1 0

Re: [Zope] Strange ZCatalog behaviour
by Dieter Maurer 20 Mar '01

20 Mar '01

Ingo Wilmer writes: > I experience Problems using ZCatalog, > See following example: > <dtml-in "Catalog(meta_type=3D'ZClass_seite_press',region=3Dzregion)"> > where zregion is one string and region is a list indexd as text If "region" is a text index, the corresponding (indexed) value should be a string. I do not know (doubt it) that ZCatalog can index lists in a text index. > when i change this to =20 > <dtml-in "Catalog(meta_type=3D'ZClass_seite_press',region in zregion)"> > where zregion itself is a list, containing 3 or more strings that=20 > should match on some instances of ZClass_seite_presse i can't > even get this into zope, because i recive this error > > non-keyword arg after keyword arg That is clear: "in" is a Python operator. "region in zregion" evaluates to either 0 or 1. Thus, you call: "Catalog(meta_type='ZClass_seite_press',1)" Not what you want... And Python does it neither... Dieter

1 0

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