- Zope - Zope lists

Really Dumb Question...
by Samuel A. Falvo II 28 Sep '99

28 Sep '99

Is there a way to edit Python code //in Zope itself// yet? I'm currently using an External Method, and it works just dandy. I love the ability. But having to rlogin to the server (or Telnet, i fyou prefer), changing to /usr/local/zope/Extensions, and use a manual text editor is a bit tedious. I'm just looking for ways to be lazy. :-) Thanks in advance. ========================================================================== KC5TJA/6 | -| TEAM DOLPHIN |- DM13 | Samuel A. Falvo II QRP-L #1447 | http://www.dolphin.openprojects.net Oceanside, CA |......................................................

1 0

What to do when an External Method returns a dictionary
by Morten W. Petersen 28 Sep '99

28 Sep '99

returns a list, however, I can't seem to fetch the variables it returns.. :\ Any ideas, a pointer to the relevant python code, etc.? -Thank you

2 2

RE: [Zope] What to do when an External Method returns a dictionar y
by Jeffrey Shell 28 Sep '99

28 Sep '99

>  returns a list, > however, I can't seem to fetch the variables it returns.. :\ > > Any ideas, a pointer to the relevant python code, etc.? If it returns a dictionary, use dtml-with <dtml-with expr="core.newcurrenttime(nowtime())" mapping> <dtml-var key1>, <dtml-var keyfoo> </dtml-with> If it returns a list (sequence), use dtml-in. If it's a list of dictionaries, use the mapping attribute on the dtml-in tag (this lets the dtml-in and dtml-in tags know to use getitem instead of getattr).

2 1

RE: [Zope] Allaire Spectra
by Jay, Dylan 28 Sep '99

28 Sep '99

> -----Original Message----- > From: Brian Lloyd [mailto:Brian@digicool.com] > Sent: Wednesday, September 29, 1999 00:03 > To: 'chas'; Zope Mailing List (E-mail); 'Jay, Dylan' > Subject: RE: [Zope] Allaire Spectra > > I think that this is an important thread - while we do not > necessarily want to compete with every other product in the > marketplace on a feature-by-feature basis, it _is_ important > to keep an eye on the competition and to learn from both their > successes and failures. > > Zopistas with significant experience using other systems are > invaluable in this process - you have enough of a foot in both > worlds to give informed feedback as to what we can learn from > the other guys out there. > > The main general points I see above: > > o short learning curve, quick tutorials and productivity > > o very good docs/organization/presentation > > ...are things that (believe me) we have been hearing loud and > clear for a while now. We (and the Zopista community) have been > focusing a lot of effort on HowTos, better documentation and > improving zope.org as a learning resource to make progress on > these concerns. That doesn't mean that the problem is solved, > of course, but the community as a whole is certainly aware of > it and taking action. > > That said, are there other particular lessons that you think we > should learn from CF/Spectra? I think one big thing you missed was marketing. Have a look at the spectra web-site. It says in very clear terms what it will give you from a buisiness point of view. Zope may have some description of its technical archetecture (which is great for those that want to cut through the BS) but this makes it a lot harder to gleam the the direct benifits of using Zope are. Things like collaborative editing, robustness from intergrated transactions etc. I'm going to give a seminar on Zope to the lucent web community (not a small thing) in a month and this what I'm going to have to do. I realized that rattling of what it is is only half effective, I have to say what it can do for people and then say how. Also, I think a good analysis of the buisness case for using Zope, esp comparing it to what the spectre rhetoric says, will hopefully make clear where Zope is falling down. For all the patting on the back everyone does Zope still has problems. It has fantastic promise and in most areas does a great job, but I think it has a long way to go before it can be said to be way ahead of the competition. Anyway, my point is that we should examine Zope from the point of view of what it offers to non technical people who can't afford to experiment. At the moment my particular headache is ZClasses. Great idea just to complicated and hard to get working.

1 0

RTF documents from Zope
by Jason Spisak 28 Sep '99

28 Sep '99

zopists, Anyone have any luck with converting DTML/HTML stuff from inside Zope to RTF that can be sent to another party via email? I'm sure I'm not alone in the world searching for the document format that I can send to people that everyone can read. I though html would do it, but the Mimetools haven't been friendly in sending out readable attatchments. Any thoughts? -- Jason Spisak webmaster(a)hiretechs.com

6 7

Re: [Zope] Experimental searchable mail list archive
by Michel Pelletier 28 Sep '99

28 Sep '99

Loren Stafford wrote: > > Michel, > > When I click on the link you published below, my browser says your server is > not responding -- from 11:00 til now 14:45 PST. > > -- Loren > This is fixed, thanks. Don't forget folks, there's a searchable archive! http://www.zope.org:12080/archives/Catalog/S -Michel

1 0

ZCatalog / Zsearch dates?
by Kuraiken 28 Sep '99

28 Sep '99

Hi all, I've come across another problem about searching. A ZCLass has a date property. (yyyy/mm/dd) The instances stores the dates no prblem. The catalog also stores it in the meta-data table. I've also got it in the index list. (tried both textIndex and fieldIndex) - rebuilt the search interfaces both times. Even though in the "search" dtml, the field "date" appears, filling this field for a search turn up zero matches every time! Even though there are clearly instances with those dates stored - (searching for items while leaving the "date" field empty indicates that the date _is_ stored by the catalog. How do I get searches for dates to work? (date type in the class property sheet) Could it be a bug in the search interface methods? I'm using the generated methods...is there something I need to add? -- ----------------------------------------- Kuraiken - Python fanatic. ----------------------------------------- Python. Try it. It'll swallow you whole! -----------------------------------------

1 0

Allaire Spectra
by Jay, Dylan 28 Sep '99

28 Sep '99

Has anyone had a good look at Allaire Spectra? It looks like Zope on steriods. Or at least marketed that way. Perhaps someone can do a feature for feature comparrison. http://www1.allaire.com/products/Spectra

2 1

Re: [Zope] Zope in Portals
by Christopher Petrilli 28 Sep '99

28 Sep '99

> Alternatively, simply distribute the DA as-is, make it very clear that the > underlying database does not support transactions, and if you use it > anyway and something needs to be rolled back, you're screwed, and you were > warned that this sort of thing could happen... This is fine by me. More complexity would be silly, as it is the developers responsibility. I just wanted to make sure it was clear what the limits of various databases were. Perhaps we should clarify the DA levels to include whether they implement transactional semantics or not. I hadn't thought to be that picky, but perhaps it is important in certain cases. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

1 0

Re: [Zope] Zope in Portals
by Andy Dustman 28 Sep '99

28 Sep '99

How about this: Obviously there are some applications which need transactions (ACID properties) and so the DA they use must support transactions. Likewise, there are other applications which don't need a transactional database. So: Is it feasible to add a method to the DA class which succeeds if the database supports transactions fails/raises an exception if it does not? I think the ZSQL Method would then need an extra property: transactional (boolean). If a ZSQL Method is transactional, then it won't accept a database connection which is not transactional. Alternatively, simply distribute the DA as-is, make it very clear that the underlying database does not support transactions, and if you use it anyway and something needs to be rolled back, you're screwed, and you were warned that this sort of thing could happen... -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d

1 0