May 2000 - Zope - Zope lists

RE: [Zope] Traceback?
by Marcus Collins 29 May '00

29 May '00

> -----Original Message----- > From: Chris Withers [mailto:chrisw@nipltd.com] > Sent: 29 May 2000 14:01 > To: Martijn Pieters > Cc: Patrick J.M. Keane; zope(a)zope.org > Subject: Re: [Zope] Traceback? > > Martijn Pieters wrote: > > If you switch debug mode off, tracebacks will be included > > in error messages as HTML comments, thus rendering them > > invisible from the unsuspecting site visitor. > > Is that true even if you override standard_error_message? I believe so, and empiracally this appears to be the case. From HTTPResponse.py: def _traceback(self,t,v,tb): tb=self.format_exception(t,v,tb,200) tb=join(tb,'\n') tb=self.quoteHTML(tb) if self.debug_mode: _tbopen, _tbclose = '<PRE>', '</PRE>' else: _tbopen, _tbclose = '' return "\n%s\n%s\n%s" % (_tbopen, tb, _tbclose) which is appended to the body of the error message when an exception occurs. hth, -- Marcus

3 2

FYI: Recap of Perl For Zope thread
by Paul Everitt 29 May '00

29 May '00

This has been a wonderful and useful discussion. I'd like to summarize some of the points made, and on the next post, give some more information about what we're trying to accomplish. First, I'm surprised nobody flamed me for the stupid linewrapping. All I can say: Outlook. :^) On to the summary... ----- My main man J. Atwood led things off with, "Why not Java?" Denis Frere floated the worry that Perl would take over Zope. Heiko brought up an oft-repeated statement: I intentionally left Perl, why is it following me around? Andrew Kenneth Milton pointed out this could increase the gravity of Zope, plus be a good re-education center for Perl folks. :^) Ragnar pointed out: "I don't mind if it is _possible_ to use external perl functions as long as I don't _have_to_." John Chandler helped put this in perspective: "whether or not people like the language, it does have a lot of existing support and developers who might find this a useful way to get involved in exploring the wonderful world of Zope." J. Atwood summed up the sentiments of a lot of people: "if you introduce Perl into Zope it would be like throwing a pair of red socks in your white wash, we all go pink." Rik brought up the looming issue: "Agreed, but the need for a Zope best practices guidelines (when to use what, and when _not_ to use it) is growing with every new language/method ;-)". I say "looming" becuase it highlights what Patrick said (see below). Martijn Faassen, head zope-xml guy, chipped in: "[as long as] I can't *see* the Perl if I don't want to see it". Chris McDonough said: "Honestly I'm sort of surprised that there is such a strong reaction to this." Brian Lloyd wrote: "You certainly wouldn't have to worry about Perl unless you choose to." Unlike what _I_ usually say, when Brian talks it's accurate. :^) Oleg Broytmann wrote: "A year ago I resigned from a web development company because they forced me to write Perl." Steve Alexander said, regarding the thought of stumbling across Perl in Zope: "When people can write their site half in Perl, I could well be stuck." Very good point. John Chandler wrote: "I'm personally looking forward to being able to use Perl with Zope, so long as the Perl support is implemented in a Zope-consistent fashion." Kevin Dangoor wrote: "I was a little puzzled when I first read the announcement, but after reading the FAQ I think it sounds like a great idea!" Chris Withers replied: "Further from this, I think diversifying the language base to Python/Perl/XSLT/etc is bad. It means that for someone to be 'proficient in Zope' form a marketing or job hunting point of view, they also have to know Perl, XSLT, etc rather than just Python and DTML. It defocuses Zope from what it is." Oleg Broytmann said: " Very soon we'll be forced, 'cause most Products will be in Perl (yse, I've read the FAQ and saw "no Perl Products"; it's temporary, mark you)." J. Atwood said everything I could hope to say, so I'll quote it all: """ The head of my company here has a theory that all "techies" have a religion when it comes to tools/languages/application environments. To a certain degree he is right. I believe in Python. I use it, love it and live by it. I have faith that if I write something in Python I can come back to it in a day or a year and understand it in minutes. I am also a believer in Zope, first for its power but second because it uses Python. Zope will benefit from the Perl community just as it has with XML. I agree with some of the comments that I don't want to see Perl code floating around in my management screen but it would also be very powerful to have modules/products written in Perl and dealt with in DTML. There are tens of thousands of Perl programmers out there, just think of all the cool things they write (especially if they found a better tool). """ (See, triple quotes, you guys thought I was giving up on Python. :^) John Chandler wrote: "Even as a Perl fan, I agree and don't see the sense in placing Perl-style expressions in DTML." (Let's get rid of _all_ expr, that's my vote.) Chris Withers wrote: "Suddenly Zope is a total mess of perl and python and the whole community shifts onto something cleaner leaving DC high and dry and spoiling a perfect solution..." Brad Clements wrote:"The undisputed leader in programmer's narcotics on the east coast was the DC Gang, whose leader, master Zope, developed a bold plan for stealing clients from the Perl gang by secretly pushing Python through free code and a framework to hang it on." Andrew Kenneth Milton wrote: "I don't think I've ever seen paranoia and religious fervour mixed in quite the same way before. Anyone would think that people think that python is inadequate as a language." Chris McD wrote: "There are *lots* of smart Perl people, and personally I look forward to seeing some of them join the community." Ethan Freemen wrote: "Zope's problem domain is simply too wide to be addressed by anything but an all-inclusive approach." John Sutherland said: "If they want to open it to Perl/Java/ etc, more power to them, more products for us to use.." Roman Milner said: "...were I to want to find a different job now coding Zope - perl will be expected to be in my skill set." Bill Anderson said: "Even if it isn't done by DC, a large perl user base *will* come up with perl products. At which point DC will either be pressured into accepting them into thecore, or watching the branch become the dominant Zope." Michel Pelletier wrote: "We don't want these folks coming in here with their years of experience and thousands of lines of code and snub them." Kevin Dangoor mentioned: "It's a fact of web programming that there are lots of tools written in different languages." Tom Neff said: "My primary worry (if you're listening, Digicool) is that integrating the Python and Perl runtime environments on various platforms will lead to unexpected conflicts and performance problems." Eric Sink said: "Maybe it's about "scripting languages vs. Java"...I don't see this announcement as a major shift toward Perl on the part of the Zope developers." In fact, Eric also gets a triple quoted section: """ Let's suppose for a moment that Zope's ambitions are much bigger than we think, and that its commitment to purity is slightly lower than we think. In other words, let's just suppose that Zope really wants to be 'The Scripting-Language Application Server'. If so, then why should it not invite the [enormous] Perl crowd into its community? """ Roman Milner said: "Perhaps this is a disadvantage to the DC company-owned open-source project model. They will make bad decisions based on potential profit." Hannu Krosing said:"See for example PostgreSQL - it has C, SQL, PL/SQL, TCL, Perl, Ruby and soon python as its server-side programming languages, with no real argument about weather to include yet another language." Dieter Maurer wrote: "There are many Internet Sites using lots of Perl. If you allow them to use Zope and retain lots of their Perl infrastructure, you have a much better chance to convert them to Zope...This, e.g., is the case with the company, I work for." Ken Manheimer wrote: "I also think these objections are contrary to one of the principle reasons that python itself is so attractive - it's a glue language, after all." Daryl Tester says two things that bear mention: "I think there is a significant proportion of Python programmers who are Perl refugees (funny, you don't hear much about the flip-side of that equation), so this announcement was bound to rub a few raw nerves the wrong way (if you pardon the metaphor mix)...But I figure DC are pretty smart guys...so let's give them the benefit of the doubt." Roman Milner gets another mention: "I think that anyone who wants to claim Zope expertise will need to know and be willing to code in perl." Michael Oas wrote: "Actually, I'd like to see Zope interface with "more" languages (Java, C++ etc.)...The fact that we can leverage Perl resources now and port them over time (if it even makes sense to do so) is beneficial." Anthony Baxter wrote: "After thinking about it some more, I'm still a bit concerned, but I also think that this will be a nice bit of bait to use when hooking in new developers. If it including building Products in Perl, I'd be a bit more concerned..." Patrick Phalen said: "Had the documentation been brought up to par some time ago (say around the time of the 2.0 release), then I doubt that the Zope community would now feel any need or desire to embrace the Perl (or any other) user community in order to gain support for Zope." Kevin Dangoor wrote: "Zope is a very powerful framework that is already fairly language agnostic." Ethan Freemen wrote: "If someone has a substantial investment in Perl, and they want to keep that as an External Method in order transition to Zope, then they should be able to. It has been a barrier to the adoption of Zope more than once, I would imagine." Sin Hang Kin wrote: "Zope needed to clean up before it goes too bad. Zope is powerful, but is already too difficult for beginner to learn." (Very, very good point!) Bill Anderson brought up: "I believe that at least a good portion of the reason for the negative reaction is not just perl, but also due to this 'community' we hypothetically acquire." Tom Neff replied: "The fallacy here is simply that Zope is adding a language, not a newsgroup." Karl Anderson wrote: "It's also an even more excellent time to be a sklled Zopista looking for a job. Find a good place looking to start a Zope project, build them a site, & you'll be deciding whether to use Perl products or not." Graham Chiu brought up: "What I would like to see first is support for Rebol." ...and I'm caught up! That only took 3 hours! :^) --Paul Paul Everitt Digital Creations paul(a)digicool.com 540.371.6909 ----------------------------------------- The Open Source Zope application server http://www.zope.org/ -----------------------------------------

2 1

A similar issue with Perl for Zope
by Michel Pelletier 29 May '00

29 May '00

Jon Udell wrote: > > BTW, there is essentially no difference between VBScript, JavaScript, > PerlScript, or PythonScript when used at this level. All can make the > same CreateObject call, and diddle the controlled app's object model in > the same ways. It ends up not being a language issue at all, but more a > case of, as I said, what the heck is that object model anyway, and then > why doesn't it behave as expected? This is such a good point I wanted to share it with the Zope community as well. The language issue is minor to the need for a definate object model with clear interfaces. It shouldn't matter if the core of Zope is written in Python or FORTH, from your perspective and the perspective of your language the model and interfaces should be well definded. -- -Michel Pelletier http://www.zope.org/Members/michel/MyWiki Visit WikiCentral for the latest Zen: http://www.zope.org/Members/WikiCentral

2 1

RE: [Zope] Re: [Zope-Annce] ANN: Perl For Zope - why I'm bummed
by Paul Everitt 29 May '00

29 May '00

Roman wrote: > Perhaps this is a disadvantage to the DC company-owned open-source > project model. They will make bad decisions based on potential > profit. I wanted to address this specifically. This is, in the abstract, a legitimate concern that comes up repeatedly about Netscape/Mozilla. Obviously that kind of model has some tremendous benefits, namely paid resources and clarity of vision. At the same time, though, there is the potential for abuse. As the person that made the decision, I can at least testify that no ulterior motives were behind it. Still, Zope is a community thing, and we here at DC need our heads bopped on a regular basis, lest we ever forget it. Consider our heads bopped. :^) --Paul

2 1

Re: [Zope-Annce] ANN: Perl For Zope - why I'm bummed
by Roman Milner 29 May '00

29 May '00

Here is why I'm bummed about this. Like other people who have posted - after years of coding perl for money, I have vowed never to do it again. (I find that it produces encourages unmaintainable code.) Also, I think my main marketable skill now is Zope. So, were I to want to find a different job now coding Zope - perl will be expected to be in my skill set. Other companies using zope will almost certainly have perl methods laying around that need to be maintained. So, basically, in order to find a job using zope - I'll have to relearn, and code in perl at that job. So, I believe this is enough reason for me to start considering other web technologies for me, and my company. ^Roman >>>>> "PE" == Paul Everitt <Paul(a)digicool.com> writes: PE> Howdy gang. Below is an announcement that we'll start PE> distributing over the next 24 hours. I wanted to let you PE> folks see it first. In summary: Perl Methods. PE> This isn't a press release, which we'll be doing in the run-up PE> to the O'Reilly Open Source conference in July, when the code PE> is closer to being available. PE> ----------- PE> Digital Creations, creators of the Open Source Zope PE> application server, announced today that it is teaming with PE> ActiveState, a leading provider of Internet programming PE> software, to make Perl a scripting language for Zope. PE> Perl is the predominant scripting language for Internet PE> applications and is a key success story for the Open Source PE> software movement. Zope is written in Python, the fastest PE> growing Open Source scripting language. PE> "It is clear that the strength of Zope realizes the future PE> architecture of the Web," says Paul Everitt, CEO of Digital PE> Creations. "This dynamic architecture, and the people working PE> with it, are a fantastic match for scripting languages. Thus PE> it is natural that Digital Creations would team with PE> ActiveState to make Perl a scripting language for Zope." PE> "Zope is a powerful content management system that we use PE> internally," said Dick Hardt, CEO of ActiveState. "By adding PE> the power of Perl to Zope, we will be able to leverage all the PE> existing Perl technology that we have as well as bring the PE> worlds of Python and Perl closer together." PE> Under this agreement, ActiveState will get Python and Perl to PE> run in the same application. More specifically, Perl PE> programmers can code critical pieces of business logic in Zope PE> solutions. PE> "The Perl for Zope project brings the worlds of the two most PE> important open source programming languages together," stated PE> Gisle Aas, Senior Developer, ActiveState. "Python programmers PE> will be able to directly take advantage of the large PE> collection of reusable Perl program modules, like DBI, found PE> on CPAN. Perl programmers will be able to program and PE> customize the Zope web application server using their favorite PE> language." PE> The initial developer release of Perl For Zope will coincide PE> with the O'Reilly Open Source Software Convention in July PE> 2000. For more information on the project, please visit the PE> Perl For Zope project page at PE> http://www.zope.org/Wikis/zope-perl/. PE> Contact Information PE> For Digital Creations, contact Paul Everitt, PE> paul(a)digicool.com, 540.371.6909x102. For ActiveState, contact PE> Lori Pike, lorip(a)activestate.com, 604.713.8433. PE> --Paul PE> Paul Everitt Digital Creations paul(a)digicool.com 540.371.6909 PE> ----------------------------------------- The Open Source Zope PE> application server http://www.zope.org/ PE> ----------------------------------------- PE> _______________________________________________ Zope-Announce PE> maillist - Zope-Announce(a)zope.org PE> http://lists.zope.org/mailman/listinfo/zope-announce No cross PE> posts or HTML encoding! (Related lists - Users: PE> http://lists.zope.org/mailman/listinfo/zope Developer: PE> http://lists.zope.org/mailman/listinfo/zope-dev )

7 8

Why Perl for Zope is good
by Itamar Shtull-Trauring 29 May '00

29 May '00

1. Zope is complicated 2. Adding Perl to Zope makes it more complicated 3. Most of us here have some Zope knowledge 4. All the Perl programmers who will flock to Zope won't have this knowledge 5. Zope with Perl will be even more popular RESULT: We can get rich as Zope consultants. All the arguments I've heard here are rather fanciful - Zope will be less stable, Zope will be corrupted, the majority of Products will be written in Perl and destroy Zope. This is ridiculous. It's like saying DC should take out DTML cause people might try to write business-logic in it (which I have done, but I know better now.) Perl is better than Python in some things (a lot more available modules, for one thing), and Python is better than Perl in most other things. For example, my co-worker Noa once ported the Perl module for making english words plural to Python - if we had Perl Methods we could simply use that and not waste time porting it. And again - You don't have to use it (TM). And if the thought of maintaining someone else's Perl code is so horrible, think about maintaining someone else's DTML code. Like, I once tried to write a workflow system in DTML :) -- Itamar S.T. itamar(a)maxnm.com

2 1

Traceback?
by Patrick J.M. Keane 29 May '00

29 May '00

I would like to ultimately remove the python traceback error code display from messages (printed after standard_html_error fires off). However, I'm not sure how to disable this? Thanks PK

4 4

SQL-Query works with MySQL-monitor but not with ZMySQLDA
by Andy Pahne 29 May '00

29 May '00

Hi, there, if I use my mysq-monitor to execute the following query, everything works fine: SELECT YEAR(START_DATE) FROM EVENT; but it doesn't work via the ZMySQLDA!?! Here's the traceback: Error, exceptions.KeyError: unhandled Traceback (innermost last): File /zope/ttl/Zope-2.0.1-src/lib/python/ZPublisher/Publish.py, line 214, in publish_module File /zope/ttl/Zope-2.0.1-src/lib/python/ZPublisher/Publish.py, line 179, in publish File /zope/ttl/Zope-2.0.1-src/lib/python/Zope/__init__.py, line 201, in zpublisher_exception_hook (Object: sql_get_years_unique) File /zope/ttl/Zope-2.0.1-src/lib/python/ZPublisher/Publish.py, line 165, in publish File /zope/ttl/Zope-2.0.1-src/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_test) File /zope/ttl/Zope-2.0.1-src/lib/python/ZPublisher/Publish.py, line 102, in call_object (Object: manage_test) File /zope/ttl/Zope-2.0.1-src/lib/python/Shared/DC/ZRDB/DA.py, line 316, in manage_test (Object: sql_get_years_unique) File /zope/ttl/Zope-2.0.1-src/lib/python/Shared/DC/ZRDB/DA.py, line 297, in manage_test (Object: sql_get_years_unique) File /zope/ttl/Zope-2.0.1-src/lib/python/Shared/DC/ZRDB/DA.py, line 401, in __call__ (Object: sql_get_years_unique) File /zope/ttl/Zope-2.0.1-src/lib/python/Products/ZMySQLDA/db.py, line 191, in query KeyError: (see above) Andy Pahne ap@net22 net22 GmbH Bad Meinberger Strasse 1 32760 Detmold Tel.: 05231 - 580 640

2 1

RE: [Zope] SQL-Query works with MySQL-monitor but not with ZMySQL DA
by Marcus Collins 29 May '00

29 May '00

> -----Original Message----- > From: Andy Pahne [mailto:ap@net22.net] > Sent: 29 May 2000 13:03 > To: zope(a)zope.org > Subject: [Zope] SQL-Query works with MySQL-monitor but not > with ZMySQLDA > > Hi, there, > > if I use my mysq-monitor to execute the following query, > everything works fine: > > SELECT YEAR(START_DATE) FROM EVENT; > > but it doesn't work via the ZMySQLDA!?! > > Here's the traceback: > > Error, exceptions.KeyError: unhandled [...] IIRC, this problem (which occurs when the results of functions, instead of columns, are returned) was mentioned some time back. You should be able to resolve it by aliasing the result: select YEAR(START_DATE) as START_DATE_YEAR from EVENT You can then refer to START_DATE_YEAR in your DTML. hth, -- Marcus

1 0

Expression syntax for sort= attribute in <dtml-in ..> tag.
by Agnieszka Karpierz 29 May '00

29 May '00

It's very, very... great news that Ross Lazarus's multikey sort patch for dtml-in tag is included in current Zope CVS and will be included in Zope 2.2. <dtml in "foo" sort=akey,anotherkey> But for me one important think is very missed. Possibillity of use expression syntax for sort= attribute. Maybe syntax: <dtml in "foo" sort="expression_which_ruturns_sort_keys"> would be possible ? eg. <dtml in "foo" sort="foo()"> where foo() will returns appropriate Python string eq. 'firstname,surname,height, width,weight' :) I hate constructions like this: <dtml-if something> <dtml in "foo" sort=key1,key2,key3> <dtml-elif something> <dtml in "foo" sort=key1,key3,key2> <dtml-elif something> <dtml in "foo" sort=key2,key1,key3> <dtml-elif something> <dtml in "foo" sort=key2,key3,key1> <dtml-elif something> <dtml in "foo" sort=key3,key1,key2> <dtml-else> <dtml in "foo" sort=key3,key2,key1> ... </dtml-in> What we think about ?. Adam Karpierz karpierz(a)itl.pl

1 0