March 2000 - Zope - Zope lists

RE: [Zope] Zope needs this (and Dynamo has it)
by Alexander Staubo 12 Mar '00

12 Mar '00

(This is getting quite off-topic. Let's keep this brief.) > From: Hung Jung Lu [mailto:hungjunglu@hotmail.com] > Sent: Sunday, March 12, 2000 3:19 AM > To: faassen(a)vet.uu.nl; alex(a)mop.no; zope(a)zope.org > Subject: Re: [Zope] Zope needs this (and Dynamo has it) > > > >alexander staubo <ale-(a)mop.no> wrote: > I think Zope's > source code is one > >huge, glowing argument in favour of > > > having protected members. > > Having worked with C++ for a long time, and later with Java, > I can tell you just how much I hated the whole thing about > data "encapsulation." > > The whole mumbo-jumbo stuff about data hiding has one and one > single purpose [snip] Having worked with C++, Python, and Object Pascal for a long time, I tend to agree, with a few modifications: - encapsulation helps keeping the code self-documenting -- nobody can accidentally access hidden members; - it aids documentation tools in that visibility rules can be seen as metadata -- "source navigator"-type object browsers can categorize members (methods and data) into their various protectedness; and - most significantly, hiding data and replacing direct access with clearly defined accessor methods lets you control access (such as synchronizing access from multiple threads) and also provide behaviour -- often data is calculated on demand rather than stored, and often related objects must be notified when data is changed. Python doesn't have accessor methods, but uses __setattr__ and __getattr__() instead, which is less intuitive -- a code browser cannot easily infer the access interface from the class definition alone -- and certainly slower -- but also more flexible. I'm a big believer in pure-code interfaces, keeping data hidden and restricting all reads and writes to accessor methods; languages such as Dylan and Object Pascal fortunately have accessor-method support built into the language, so referencing an attribute foo.name would actually be resolved by the compiler into a call to foo.GetName(). Python doesn't really need this, since its attributes are all dictionary-stored. Btw, as for private data members that are very specific to an implementation of a class, Ada95 solves this quite elegantly through packages, which are similar to C++ namespaces. I don't remember if Ada has language-assisted accessor method support. > > > Python has no "out" parameter, only "in" parameters that > > > are mutable depending on the type of the object passed. > The syntax I'm > > > alluding to would effectively give you both "out" and "const" > > > parameters. > >But that might result in a lot of incomprehensible code. I'm > not sure if > >I'm in favor of having 'out' parameters anyway. constness as > defined in > >C++ is also tricky, as it infects code; everything that touches it > >needs to be const-correct. Python tends to be less strict in > this area. > > Yes, another thing that I consider to be stupid in C++ is the > overuse of const, or its use at all. Again, generations of > programmers are taught into this thing about usage of const, > and buying into it without questionning. Const is overrated but often useful. Given C++'s absolutely antique object paradigm -- heap-based objects that aren't garbage-collected, meaning you end up dabbling with pointers *a lot*, or use confusing reference-counting smart-pointer template classes that go all over the place -- I like pass-by-reference better. I'm absolutely annoyed with C++. This is one reason: class Foo; class Bar { Foo F; }; class Foo { Bar B; } This, of course, won't compile -- the class Foo is undefined at the time Bar is declared. This means that a class A cannot contain a member of another class B if B already contains a member of class A, unless one of them stores the member as a pointer reference. This certainly screws up any reference-counting smart-pointer scheme, or at least makes it bloody hard to keep simple. > Keep Python simple. The role of Python is CP4E (Computer > Programming For Everyone.) In Java or C++, you have to type > all the extra stuff about public/ private/ protected/ void/ > abstract/ static/ synchronize/ final/ const/... before you can > do something. I know many people that live in that world and > refuse to simplify their lives... well, then again, I also > know people that lives in the Perl world and insist that Perl > is a very readable language. :) Readability and verbosity are not the same things. Java is at least an improvement on C++'s readability, but it is occasionally perhaps too verbose. But not compared to, say, Dylan, which has keywords like "required-init-keyword"; in spite of this, it's a great language once you get used to it. I rather like Borland's Object Pascal myself. It's suitably verbose to be readable, strict enough to catch most trivial errors in the compilation phase, statically-typed enough to perform really well, and just plain likeable. It doesn't have operator overloading, parameterized classes, multiple inheritance, or synchronized members, although it does have interfaces, static, abstract, const, and member visibility constructs. Here's the above snippet in OP: type Foo = class; Bar = class B: Bar; end; Foo = class F: Bar; end; (And this compiles.) > > Hung Jung -- Alexander Staubo http://alex.mop.no/ "`Ford, you're turning into a penguin. Stop it.'" --Douglas Adams, _The Hitchhiker's Guide to the Galaxy_

1 0

Redirection problems
by Stephen Pitts 12 Mar '00

12 Mar '00

Right now, visitors to my site at http://www.centralchurchyouth.org go through the following redirection: http://www.centralchurchyouth.org (running IIS) to http://www.centralchurchyouth.org:8100/ (running Zope) to http://www.centralchurchyouth.org:8100/Home/ (the real home page) This works in Netscape but doesn't work in IE. The user gets all the way to the third page but it doesn't render. Upon further analysis, all of the absolute_url calls (like "<dtml-var "stylesheet.absolute_url()">" produce http://www.centralchurchyouth.org/xxx instead of http;//www.centralchurchyouth.org:8100/xxx, so the page has a broken logo, etc. I think it has to go with the HTTP session between IE and http://www.centralchurchyouth.org:8100/, but I'm not sure what. Using wget also returns a correct page. Surely someone has come across this issue. -- Stephen Pitts smpitts(a)midsouth.rr.com webmaster - http://www.mschess.org

1 0

Re: [Zope] Zope needs this (and Dynamo has it)
by Hung Jung Lu 12 Mar '00

12 Mar '00

>alexander staubo <ale-(a)mop.no> wrote: > I think Zope's source code is one >huge, glowing argument in favour of > > having protected members. Having worked with C++ for a long time, and later with Java, I can tell you just how much I hated the whole thing about data "encapsulation." The whole mumbo-jumbo stuff about data hiding has one and one single purpose: divide the programmers into engine programmers and app programmers, so the engine programmers and exercise full control over app programmers. It has more to do with MONEY and corporate POWER CONTROL than with technology. The private/protected keywords are an enterprise feature... designed for big companies. And generations of students are taught into this stupid c**p about "data encapsulation." Funny thing is, many actually buy the idea, get burnt for a few years and refuse to acknowledge they are being burnt ("if it is mentioned in textbooks, there must be a reason... it must be good for me..."), and only then to realize much later... hmmm.... maybe "data encapsulation" should be done by convention and not by syntax. > > Python has no "out" parameter, only "in" parameters that > > are mutable depending on the type of the object passed. The syntax I'm > > alluding to would effectively give you both "out" and "const" > > parameters. >But that might result in a lot of incomprehensible code. I'm not sure if >I'm in favor of having 'out' parameters anyway. constness as defined in >C++ is also tricky, as it infects code; everything that touches it >needs to be const-correct. Python tends to be less strict in this area. Yes, another thing that I consider to be stupid in C++ is the overuse of const, or its use at all. Again, generations of programmers are taught into this thing about usage of const, and buying into it without questionning. Python uses references for object parameters in function calls. It can also return tuples. That's enough. Really. Keep Python simple. The role of Python is CP4E (Computer Programming For Everyone.) In Java or C++, you have to type all the extra stuff about public/ private/ protected/ void/ abstract/ static/ synchronize/ final/ const/... before you can do something. I know many people that live in that world and refuse to simplify their lives... well, then again, I also know people that lives in the Perl world and insist that Perl is a very readable language. :) Hung Jung ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Help with DTML
by Tom Wright 11 Mar '00

11 Mar '00

Hi DTML Gurus, I am a newbie with DTML and i am trying to do the following with this script 1) using the subdirectory RegisteredUsers, check if a ZClass object of type Player exists in the RegisteredUsers directory with an id that matches that in the Request ( a form from the client ). This currently doesnt work for some reason and i get the else case even if the object does exist. 2) In the else case i am then trying to create a new object of type Player a ZClass object defined in the GameSite product ). I am creating the object correctly in the correct place but the next bit of setting the properties of the player object does not work, and the object properties are blank. HELP !! I have checked all the documentation for zclasses, dtml faq etc. Can any one help? Is there an easier/better way of achieving what i am trying to do, or am i barking up the wrong tree ? <dtml-with RegisteredUsers> <dtml-if REQUEST['new_user_name']> User currently exists <dtml-else> New user <dtml-with "manage_addProduct['GameSite']"> <dtml-with "Player.createInObjectManager(REQUEST['new_user_name'], REQUEST)"> <dtml-call nage_changeProperties( user_name = REQUEST['new_user_name'], password = REQUEST['new_password'], player_name = REQUEST['new_player_name'], planet_name = REQUEST['new_planet_name'], email = REQUEST['new_email'], )" > </dtml-with> </dtml-with> </dtml-if> </dtml-with> Regards Tom Wright thomas.wright1(a)btinternet.com

2 1

RE: [Zope] Zope needs this (and Dynamo has it)
by Alexander Staubo 11 Mar '00

11 Mar '00

> From: 'Martijn Faassen' [mailto:faassen@vet.uu.nl] > Sent: Thursday, March 09, 2000 1:15 PM > To: Zope Mailing List (E-mail) > Subject: Re: [Zope] Zope needs this (and Dynamo has it) > Pardon me for sending off another email in mid-stride. Damn cat :-) Let me finish the last sentence first: I also have a database-centric Zope app that causing me headache. The ZODB is *way* too immature to replace a database right now -- fine for the kind of stuff that runs on zope.org, not for us. We're actually looking at alternative app servers and solutions (such as hardwired C++ CGI code) right now. It's a shame, and I'm fighting it, but we might end up with something like Dynamo. [snip] > > Python has plenty of problems, but they're tiny by > comparison and imho > > they're mostly artifacts of Python's currently somewhat > anemic syntax > > (eg., only two kinds of loops, no "switch", no protected members, no > > constants, no syntax for declaring mutability). > > I suggest you go discuss these things on comp.lang.python. :) I don't necessarily say they're _my_ problems, but some people think they are, and that counts. I don't miss "switch" myself, although I do miss a kind of enumerated type. > I don't miss switch. Functions are first class objects, and > dictionaries > can be used instead of switch when necessary. Also, good > object oriented > design tends to kill switch statements anyway. I remember sitting down with Python for the first time create a simple CGI type thing, and found that I could just do def DoSomething(): ... def DoSomethingElse(): ... DoSomething(eval('Do' + Args['cmd'])) and then call up the CGI using a query string such as /cgi-bin/foo.py?cmd=Something. Wonderful, and better than any kind of RTTI. > I think the two loops are fine, though it would be nice to have the > current constructs to know about iterators. I believe Guido is > taking that into consideration. Also there's the list-comprehension > proposal which may help here. The list comprehension syntax is cute, but not, I think, so clever. Perhaps it'll prove to be a nice feature, even a successful one, but personally I doubt, even with the knowledge in the back of my head of how this stuff works, that I would instinctively grasp for a list-comprehension expression as naturally as I grab for, say, a "while" loop. My head is just not wired that way, and I think the syntax looks positively alien for Python -- it's not "pythonic". > I don't think you'll see protected members any time soon. I think Zope's source code is one huge, glowing argument in favour of having protected members. > I'm not sure what you mean with syntax for declaring > mutability, though > it sounds interesting. I don't particularly take to the idea of a having mutability/immulatibility property burned into the type itself. Tuples are immutable, dicts and lists are mutable. Why? Because Guido says so. Jon Udell, I think it was, has argued that tuples are currently a redundant element in the language. Why have two kinds of lists? It just confuses people. A syntax for declaring the mutability of types would be helpful in clearing out this mess. For example, you should be able to declare a dict to be immutable when passed to a certain function call -- ie., forcing a copy. Python has no "out" parameter, only "in" parameters that are mutable depending on the type of the object passed. The syntax I'm alluding to would effectively give you both "out" and "const" parameters. > [snip code generator extension idea] > > Something like that would definitely be neat. The hard part would be > in the translation process, of course. The other part is in the > interfacing with regular Python; do you allow your translated function > to refer to other Python objects? If you do, you're opening a can of > worms. If you don't, then it starts to look like the 'Swallow' subset > of Python I proposed once; a strict subset of Python with > added full type > annotations, which is translatable into C or native machine code. I haven't thought it through. I just think it was potential. Why shouldn't the translated function refer to other objects? The function would essentially just constitute native calls to the Py* APIs -- in effect, a translated function would summarize the runtime calls made by the interpreter during normal execution. Therefore, non-translated Python code could just as easily refer to translated code (within a "translated module", which would be a special object), because the translator module would construct the necessary proxy object to forward external calls to the inner code. Or something. ;-) > > It would be an interim solution for certain CPU-intensive > modules, in > > anticipation of such built-in functionality in CPython > itself. Possibly. > > If you're starting such a project I want to hear more about it! I'll let you know. ;-) -- Alexander Staubo http://alex.mop.no/ The difference between theory and practice is that, in theory, there is no difference between theory and practice.

2 1

RE: [Zope] Zope needs this (and Dynamo has it)
by Alexander Staubo 11 Mar '00

11 Mar '00

> From: 'Martijn Faassen' [mailto:faassen@vet.uu.nl] > Sent: Thursday, March 09, 2000 1:15 PM > To: Zope Mailing List (E-mail) > Subject: Re: [Zope] Zope needs this (and Dynamo has it) > > > Alexander Staubo wrote: > > > From: Martijn Faassen [mailto:faassen@vet.uu.nl] > [I list a number of projects about improving Python] > > > People are indeed working on Python, but not to the extent of more > > popular projects like Linux or even, I believe, Perl. > > I don't know enough about Perl to judge this, but to me, there's > plenty of activity out there. Of course there could always be more, > but lots is happening.. We have _three_ independent implementations of > Python, for instance (Python, JPython and Vyper, and then there are > projects like Python2C). True enough, though I'd have liked to see more, and I'd have liked to contribute more, too, which is to say, I'd like to contribute at *all* -- no time for that at the moment, however. Ironically, I'm too busy using it to improve it. I find it ironic that JPython is even *slower* than CPython. Curious -- is anybody using it for anything worthwhile? > > Compiler/language projects have, historically, not thrived in the > > collaborative world of open source software -- for very > specific reasons > > inherent in the concept itself of languages and compilers. > Still, I'm > > very impressed with the evolution of next-gen GCC (formerly EGCS). > > Sure, it's not easy to do. I would debate that compiler/languages have > not thrived in the open source world, though. There seem to be > quite a few successful open source languages around. I'm not disputing the success of these languages. Perl, Python, PHP, Pike -- they're all quite successful at what they aim to be (*). But people tend to use languages rather than contributing to their development. You can't just evolve a language indiscriminantly, which is why we have Guido and Larry, the benevolent dictators. You can't just go, "oh, and I added iterated loops today". Every damn little feature requires at least some kind of ratification process. Languages are much more susceptible to breaking. (*) Except possibly Pike. I'm ashamed to say it, but I find myself oddly attracted to this language, if mostly because of its speed and interesting resemblance to C. Pike is a good example of "how to make a powerful language/interpreter system that's also very fast". Pike has had a type system from the outset, which is a definite edge over Python. > [assessment of Vyper with which I agree] > > > Anyway, while I have not been monitoring the Python > type/interface SIG, > > it seems to be moving quite slowly. > > That's the nature of discussion lists, almost. There are some > prototype > implementations of type-checking systems for Python, though (I think > two or three independent ones, in fact). Where? The type system SIG has a funny intro: "Recently, the types SIG has come under attack for inactivity, and in response Paul Prescod has offered to guide the SIG towards accomplishing a single specific goal: to develop an optional static typing system for Python. The December 1999 archives of the SIG show the discussion that lead to this decision." Reading this stuff now. It's interesting. I hope they get it right. Maybe I'll chip in. What's interesting about Dylan is that, because it relies on static information such as type hints and class/method relationships to be efficient, the developers of Functional Developer (formely Harlequin Dylan) are facing a design problem related to how they compile programs. They've actually put all of the various libraries into shared DLLs. Unfortunately, this means they lose the benefits of the optimizations that can be made through the use of static compiler information. When you load up the [latest beta of the] Developer IDE and compile a program, it consumes a whopping 45MB of RAM. And it's damn slow. The absence of such optimizations is one reason for this hogging tendency. So they're planning on providing a "whole program delivery" option whereby all libraries would be statically linked. > [Python people say speed is generally not the problem] > > > It is _less_ of a problem, but most Pythoneers are indeed > > > interested in > > > speeding of the language. I haven't heard of zealots who > want to hold > > > back speedups, as long as it doesn't do away with the power. > > > > I'm not saying they're holding back, but rather they're > dismissing speed > > and scalability as being a problem. I firmly believe that speed is > > Python's number of problem today, and it's keeping Python from being > > used in more applications. > > Hm, but in my experience Python has been shown to be plenty > fast enough > for the majority of applications. You're probably right though, and I > agree completely that a faster Python would be very nice. I have several apps where I would rather use Python, but where speed is so significant that I would either end up writing a lot of the code in C++ for speed (which is painful due to the lack of integration between the two languages -- Python classes can't inherit from stuff in the C++ extension, for example). I also have a database-centric Zope app that causing me headache. The ZODB is *way* too immature to replace a database right now -- fine for the kind of stuff that runs on zope.org, not for us. ream > > > Python has plenty of problems, but they're tiny by > comparison and imho > > they're mostly artifacts of Python's currently somewhat > anemic syntax > > (eg., only two kinds of loops, no "switch", no protected members, no > > constants, no syntax for declaring mutability). > > I suggest you go discuss these things on comp.lang.python. :) > > I don't miss switch. Functions are first class objects, and > dictionaries > can be used instead of switch when necessary. Also, good > object oriented > design tends to kill switch statements anyway. > > I think the two loops are fine, though it would be nice to have the > current constructs to know about iterators. I believe Guido is > taking that into consideration. Also there's the list-comprehension > proposal which may help here. > > I don't think you'll see protected members any time soon. > > I'm not sure what you mean with syntax for declaring > mutability, though > it sounds interesting. > > > Imho Python's second big problem is what you might call, in > lack of a > > better term (I'm not wearing my compiler-writer hat right > now, sorry), > > contractual semantics -- anything from static typing (pass > a string to a > > function that takes an int and you get either a compilation > error or an > > exception) to interfaces (the ability to enforce semantic > compatibility) > > to design-by-contract constructs. > > The types-sig is reaching consensus about optional static typing and > Guido does want to include that into the language in the > future (beginnings > in 1.7, full implementation in Python 3000 aka Python 2). > Interfaces are > being considered too, and Jim Fulton in fact has an > interfaces proposal > out there (that may get used in Zope's code base). > > I think using a unit testing framework can substitute for design by > constract constructs myself. > > [snip] > > > It'll be pretty difficult to make a beast like Zope exploit > > > type-hints, though, I think. > > > > I disagree, but there's only one way to find out -- implement it (or > > simulate it very carefully). > > Okay. > > [snip code generator extension idea] > > Something like that would definitely be neat. The hard part would be > in the translation process, of course. The other part is in the > interfacing with regular Python; do you allow your translated function > to refer to other Python objects? If you do, you're opening a can of > worms. If you don't, then it starts to look like the 'Swallow' subset > of Python I proposed once; a strict subset of Python with > added full type > annotations, which is translatable into C or native machine code. > > > It would be an interim solution for certain CPU-intensive > modules, in > > anticipation of such built-in functionality in CPython > itself. Possibly. > > If you're starting such a project I want to hear more about it! > > [snip] > > > All true. Anyway, the only thing you're wrong about is that > > > Pythoneers aren't > > > interested in improving performance. They are, but I grant > > > you they're not > > > performance nuts like users of C or C++. :) > > > > Well, I guess they're too busy arguing about whether Python > should allow > > assignments as expressions so you could do "while line = > f.readline():". > > ;-) > > Not to mention indentation! Anyway, the people who keep bringing these > things up don't tend to be the Python nuts (mostly they're > the newbies). > > Regards, > > Martijn > > > _______________________________________________ > 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

A ZCatalog ID bug?
by R. David Murray 11 Mar '00

11 Mar '00

I've got a simple CatalogAware ZClass. (CatalogAware is the only class I added to its inheritance list.) Everything seems fine, but if I access an instance of the ZClass through the Catalog by doing, say, getobject(data_record_id_), and then inspect the 'id' property of the returned object, instead of getting the id of the object I get the id of the folder in which the Catalog lives. When I create class instances, the 'id' in the meta-data is correct. If tell the catalog to update itself (or tell an item listed in the catalog to update itself through the catalog management screen), then suddenly the metadata id is also the id of the folder enclosing the Catalog. Is this a bug, or am I doing something stupid? The object appears under its id in all of the management screens, including the 'indexed items' tab of the Catalog. --RDM

1 0

Re: [Zope-dev] Missunderstanding of DTML Methods and acquisition?
by Michel Pelletier 11 Mar '00

11 Mar '00

This thread is more appropriate for the main list. zope-dev is for development topics. "R. David Murray" wrote: > > I'm finding this to be one of the trickiest "simple bits" of dtml to > learn, even after having read the docs. The following should work > in your /user/regions/index_html (tested): > > <dtml-var IManager> > > As you may already know, the following will instead get you quoted > text of the IManage method: > > <dtml-var "IManager"> > > The following will also work (tested): > > <dtml-var "IManager(_.None,_)"> > > This passes a 'client' of None and the namespace (that img exists > in) to the method. (I presume that in the first working example above > Zope supplies the client and namespace to the method when it evaluates > it). Correct. > This call form is of course what you'll need if you want to > pass arguments to the method: > > <dtml-var "IManager(_.None,_,somearg='someval')"> > > What I'm most confused about right now is when it is necessary to pass > the client and namespace and when you can omit it. It is necessary when you want to call a DTML Method or Document from a Python expression and you want that DTML Method or Document to be able to look things up as an attribute of a 'client' or in your current namespace (or any namespace you provide). You can omit it when you are using a DTML Method or Document _by name_ in DTML. Note that: <dtml-var IManager> is the same as: <dtml-var name="IManager"> and: <dtml-var "IManager()"> is the same as: <dtml-var expr="IManager()"> So most people use the first and third shorthand forms to use an object by name and to execute a python expression respectivly. When the DTML Engine sees that you are using an object by name, it tries to do clever things, like detect if it is a DTML object and to call the method and pass the namespace 'magically'. When the DTML engine sees that you are using an expression, it assumes you know what you are doing and does no magic for you. Therefore, you must explicitly pass in the namespace. > I'm also very unclear > as to just what the 'client' is, especially since most of the examples > I've seen involve passing in None for the client. The 'client' is an object that you want to use as a namespace. For example, if DTML Method 'IManager' wants to find the name 'img' you can pass a client object, and the method will try and do a getattr(client, name) (in this case, name being 'img'). If you pass a namespace, then it will try and do a namespace[name]. If neither of these succeed, it will look for the name in the optional list of keyword arguments you can provide. If that fails, it raises a NameError. The reason why it is None in most cases is because you want your method to look things up using the Zope DTML Namespace (affectionately known as '_'). In some special case however, you may want to explicitly provide some other object. This is single handedly the #1 obfusication in Zope and the most frequently asked question. We, of course, did not obfusicate this on purpose. When DTML was first concieved it worked by name only, so the behind the scenes magic was acceptable and intuitive. Later, we added python expressions, and the ugliness of calling DTML Methods and Documents became aparent. -Michel

1 0

Re: [Zope] zope.org Members list
by Martijn Pieters 11 Mar '00

11 Mar '00

From: "David Kankiewicz" <kankie(a)thegrid.net> > > A next call to Members will return this cached information. Timeout of the > > cache currently is 60 minutes. So, the batched pages and the searches use > > this cached information. > > What about a ZCatalog being updated every hour??? I would think two or > more hours would do... > Have a cron job do it... This might be a better idea. I'd use an external file, however. Thtis would indeed solve quite a few points on the list I gave: > > 1/ The cache has expired or is empty: we have to fill it again. User will alway read from file, is fast (shared locking). A cache update would do a exclusive lock at the end of the data gathering period, write quickly, unlock again. > > 2/ The cache is per-thread. <...> > > 3/ The volatile attributes don't hang around as long as I expect them to. <...> No longer. > > 4/ The dictionary containing the cache may be coming from swapped memory. > > Currently, the Zope.org process grows quite large. This may have to do with > > the up to 42000 Folder objects loaded into memory at any time. The Members > > Folder holds references to 6000 Member Folders, and there can be up to 7 of > > them (7 threads). This is an area where a BTree based folder would _really_ > > help. > > should solve this too, unless people are surfing all those folders... This doesn't solve this. It's not the surfing of all those folders, it's the accessing of the Members Folder itself. It's that folder that holds the references of 6000+ sub Folders. <...> > > 6/ CPU is hogged. The rendering of the ZQR is very expensive. If it runs, > > the whole of Zope.org suffers. I am seriously considering disabeling it. > > People really onlly need the pre-rendered version. I was testing just now, > > had to wait way too long, and noticed someone was looking at both the normal > > ZQR (rendering from XML), and the print preview version. The Members roster > > came from cache. > > I know would come one of these days :) > I'll be working on it tonight and starting to update it more actively. > (more complete, different format, etc.) > First thing I can think of is to make it all static, atleast the big > ones. Please. Amos was going to spend some time looking into optimizing the code, but not offering a dynamic version would bemuch better. There really is no need for one. Thanks! Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ | The Open Source Web Application Server ---------------------------------------------

1 0

Form Submit question
by Kulpinski, Dejan 11 Mar '00

11 Mar '00

Hello all, Is it possible to submit the form by clicking on the link and not on the submit button? In other words I would like to submit my form without having the submit button present. Now, I now I can do this using JavaScript on client side, by doing something like: <a href="MyFunc();"> The Link </a> MyFunc() { form.submit(); } So is it possible to do this without JavaScript ? Dejan Kulpinski Sierra Systems (604) 688-1371/450

3 2