May 2000 - Zope - Zope lists

Re: [Zope] Re: [Zope-Annce] ANN: Perl For Zope
by Dieter Maurer 29 May '00

29 May '00

Heiko Stoermer writes: > Zopistas, > > Paul Everitt wrote: > > > > Digital Creations, creators of the Open Source Zope application server, > > announced today that it is teaming with ActiveState, a leading provider > > of > > Internet programming software, to make Perl a scripting language for > > Zope. > All I can say for myself is this: > I know several people - myself included - who moved from perl to > python/java/c++ for many very good reasons. > > What are the benefits? > - being able to use DBI when I have Zope Database connectors? > - finally having people doing obfuscated perl contests again in their > products, when I was just glad to having gotten rid of all this? 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. Dieter

5 7

Re: [Zope] Building ZPyGreSQLDA on Linux
by Hung Jung Lu 29 May '00

29 May '00

Let me try again, does any of you guys have a "config" subfolder inside your /usr/lib/python1.5/ folder? I guess the "config" subfolder maybe an feature from the old python1.5, because in the new python1.5.2 there is no such a folder. Also, in an error like: make[1]: *** No rule to make target `/usr/lib/python1.5/config/Makefile', needed by `sedscript'. Stop. Is it complaining that the config/Makefile cannot be made? Or is it complainig that the Makefile cannot be found? It the Makefile a target or a source in this particular case? That is, is the "config" folder to be generated, or is it supposed to be there from a start? I guess RedHat Python RPMs set up folder structures very differently from the plain source files build of Python. I am using the source file build of Python and there is no "config" folders anywhere. Contacted the author of ZPyGreSQLDA but so far no response... Hung Jung >From: "Hung Jung Lu" <hungjunglu(a)hotmail.com> >To: cobrien(a)Radix.Net, hungjunglu(a)hotmail.com, phd(a)phd.russ.ru, >zope(a)zope.org >Subject: Re: [Zope] Building ZPyGreSQLDA on Linux >Date: Fri, 26 May 2000 22:38:41 PDT > >>From: "Cary O'Brien" <cobrien(a)Radix.Net> >>Ok, the build procedure can't find the Makefile supplied >>by the standard python install (the python-development package >>if you are installing via RPMS). It looks as if you >>have python installed in /u/c2/hjlu/lwc_zope... rather than >>/usr/local/... or something like that. Either the Makefile >>is missing, or the build procedure is looking in the wrong >>place. > >Does any of you know where to obtain the Python-dev files? I searched all >over www.python.org but could not find anything on Python-dev. I am not >using RPMs, I just download source directly from www.python.org. > >regards, > >Hung Jung > ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

4 3

RE: [Zope] ANN: Perl For Zope
by Paul Everitt 29 May '00

29 May '00

Bill wrote: > Now, for those still reading... some technical issues. > > Have you SEEN perl's OO code?? I have actually compared perl > and python > objects, and even my anti-python friends (they are decreasing very > quickly) admit that perl's handling of objects stinks to high > orbit. It > may be a Object publishing environment, but it still needs > topublish one > basic type of object. Here is where I think we will see the > biggest part > of the prblems on the technical side. Perl's objects are of a > lesser ... > refinement than Python's, and interfacing the two directly is not > pretty, nor easy. That is why I favor supporting perl through > CORBA, let > an independant system designed specifically for that 'type' of thing > handle it. It's funny that you bring this up. One of the really interesting things about this project so far is learning about Perl internals. You're description is, apparently, pretty accurate. However, the way we've done this mitigates the issue in two ways. First, Perl doesn't need objects to fulfill its job. Functions are bound to the object system. All the real stuff (persistence, transactions, etc.) is in Zope (read: Python). Honestly, the goal really _is_ to make Perl a scripting language for Zope, not an implementation language! The contract says so! Second, ActiveState will work on improving facilities missing in Perl, such as reflection, to support our requirements (e.g. sniffing at method signatures). --Paul

3 3

Deprecation of <dtml-var "">?
by Kevin Dangoor 29 May '00

29 May '00

I've noticed that just about every new Zope user gets bitten by <dtml-var foo> == <dtml-var name="foo"> and <dtml-var "foo"> == <dtml-var expr="foo">. Messages reflecting this confusion come to the Zope list frequently. Everyone appreciates the shorthand, and everyone does eventually learn the difference between <dtml-var foo> and <dtml-var "foo">. Perhaps it would be better to use <dtml-var name="foo"> and <dtml-var expr="foo"> more often on the list for the sake of newcomers? Or perhaps there should be a whole (but short) chapter in the DTML that is nothing but boldface "<dtml-var "foo"> is actually running a python expression". Or, how about a <dtml-expr> tag (which could even start out as a simple synonym for <dtml-var>) so that people won't be confused about what is python and what is a variable lookup with the special calling properties. I think DTML is quite nice and works very well, but I see a lot of people get caught on this, and almost anything that can be done to remove the barriers of entry to Zope is a good thing. Kevin http://www.byproducts.com - Humor and Novelties

4 5

Another question
by Patrick J.M. Keane 29 May '00

29 May '00

By default, when a new instance of a ZClass is created, it is dropped into the same directory as the calling forms and instance creation methods... Is there an easy way to designate the final location for the instance. Say, as an example that I had administrative methods and documents all under foo/admin, but wanted new products to be placed in a parallel directory such as foo/toys, so that the permissions could be properly set for admin, allow just managers to access those methods, while letting the results show publicly in foo/toys? Thanks pk

2 1

RE: [Zope] Perl Zope
by Paul Everitt 29 May '00

29 May '00

Adam wrote: > What makes me most uncomfortable about this is the opportunity > cost. Every hour of development time integrating Perl is one > less hour As I tried to mention in my "Redux" post a few moments ago, this isn't the case. ActiveState is doing the engineering. > working on other parts. I can say without any reservation > that the lack > of documentation has done ten times as much as lack of Perl support to > make my time with Zope difficult. You're absolutely right on this. Amos' post recently described the various things in various stages of release that should give some hope for the situation. These things really are an improvement. I'm crossing my fingers that this turns into a torrent of material that turns an area that is a nightmare into an area of great pride. At least that's the hope. :^) --Paul

3 3

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

29 May '00

> -----Original Message----- > From: Tino Wildenhain [mailto:tino@wildenhain.de] > Sent: 29 May 2000 15:44 > To: Marcus Collins > Cc: 'Chris Withers'; Martijn Pieters; Patrick J.M. Keane; > zope(a)zope.org > Subject: Re: [Zope] Traceback? Codechange! > > Hi, [...] > This is very ugly imho. It schould be sufficient, if one includes the > traceback-variable into the standard-error where its appropriate. > In the current implementation it will break the HTML-standard with > code outside <HTML></HTML> and additionally makes it impossible to get > error-messages to picky browsers, such as WAP-devices. I second this -- despite the traceback being sometimes crucial to debug errors, its inclusion after the closing HTML tag goes against the standard. Furthermore, the traceback *could* sometimes be considered to pose a security risk, since it exposes the names of methods in the call stack, some of which should not necessarily be callable through the web. Or am I just being paranoid? > Is it ok if we remove these lines? I think there should be a knob to turn it off... and not for the whole site, but for a subtree (perhaps even on a folder-by-folder basis). That way, the folks who develop and deploy on a single Zope server (does anyone do this?) can keep their tracebacks on sites under development, but get rid of them on live sites. > Do I have to copy this message to the collector and wait for > a couple of months or can we do it instantly? ;-) *grin* > Regards > Tino Wildenhain -- Marcus

3 3

The agony of the ZOPE Documentation
by jiva＠devware.com 29 May '00

29 May '00

I'm sorry, but I have to say, the ZOPE documentation, despite efforts to improve it, is absolutely, positively horrible. Not because the content isn't there, but because the tools to access it simply suck. I can type in searches on both zope.org and zdp.zope.org and though I KNOW the information is there, I can't get the results I want! Constantly, when I am recommending ZOPE to people, the ONE thing I and they complain about is the horrible documentation! Is there some way that I can get a copy of all of the FAQ's, HOW-TOs, Ref manuals, etc in some kind of raw ASCII text format or HTML or something, so that I can build some kind of useful search engine for this stuff? The search engines on www.zope.org and zdp.zope.org just plain suck. Additionally, the zdp web site is a real nice idea that is SO poorly executed IMO as to make it totally unusable. You can't even browse the documentation without clicking through a thousand different links. (I can give you specific examples of how to improve the site if you want.) Please, anyone? Save Zope's documentation! -- Some husbands are living proof that a woman can take a joke.

13 17

Q: Accessing a ZSQL Method from an External Method
by a.wacknitz＠francotyp.com 29 May '00

29 May '00

Hi all, I want to use ZSQL Methods from within External Methods and have already read the appropriate HowTo but it is somehow vague in some respects and I have some problems with my adaption. I have ZSQL methods in a subfolder /SQL, eg. /SQL/sqlZuordnung My External Method named "extShow" should use the ZSQL method sqlZuordnung: def Show(self, zuordnungsbereich, zuordnung): """Show retrieves some database items.""" res=self.SQL.sqlZuordnung(zuordnungsbereich=zuordnungsbereich, zuordnung=zuordnung) fields2index={} fieldnames=res._schema.items() for i in range(len(fieldnames)): fields2index[fieldnames[i][0]]=fieldnames[i][1] id_val=res[0][fields2index['ID']] return id_val First, I want to know how to call this function, especially how to submit the correct namespace. Calling it with <dtml-var "extShow(_, zuordnungsbereich, zuordnung)"> results in an AttributeError (SQL). Here's a TraceBack:  So, what am I doing wrong here? TIA, Andreas ********************************************************************** This email message has been swept by MIMEsweeper for the presence of computer viruses. Francotyp-Postalia AG & Co.

1 0

Hadar's Thoughts on Perl for Zope (LONG)
by Hadar Pedhazur 29 May '00

29 May '00

It's been a while since I've communicated directly with the Zope community, and I am truly sorry for that. I have been so busy, that I have actually disengaged from the mailing lists, something I was hoping to avoid doing. I have maintained the same level of involvement with Digital Creations, and therefore Zope as well, but the amount of traffic on the lists was overwhelming me given my current activity level at Opticality. I have only seen a single post to the list regarding the recent announcement of Perl for Zope. Paul Everitt was kind enough to directly forward to me Eric Sink's post, because he knows how highly I regard Eric's opinions. The most important part of that post was Eric's clear statement that there was discord in the community over this announcement. Having been one of the instrumental people in bringing Zope to the community, and having likely been the driving force behind the decision to create Perl for Zope, I would like to directly share the thoughts behind that decision. Please recognize that I have not read any of the posts on the list, and therefore, could very well be repeating important concepts written by others. I apologize if that ends up being the case, but rest assured that this would only mean that I am further underscoring those thoughts, because I didn't have the benefit of reading them first. First, a brief history lesson. I was a major Perl coder for 5 years. I built multi-thousand line Perl programs that did pretty sophisticated things, so I knew Perl pretty well. Then I discovered Python. I haven't written a line of Perl since then. This is not a put-down of Perl, but rather an elevation of Python, IMHO. It is through my discovery of Python that I came across Digital Creations (DC), in 1995. I contacted DC in 1997, and asked them if they were interested in funding. We consummated a deal in October of 1998. The deal happened only because they were a Python shop. A month later, after lots of "active discussion", we decided to Open Source the then named Principia application server. I was a driver of that decision as well. So, for the record, I'm a deeply rooted Python person, and believe it to be the ideal foundation for Zope. So, why would I push for the decision to create Perl for Zope? When I was at Union Bank of Switzerland (UBS), I used a tool that hooked into the Objective-C runtime, and unified the object model so that it was equally accessible from Objective-C, TCL, Perl and Python. Classes, methods, instance data, etc., were interchangeable, and worked transparently across languages. This was simply magic, and we made excellent use of this in a variety of our applications. Given how wonderful Zope was, it seemed to me that it too could be the foundation for people who had skills in other languages. My original thought was to use the same tool I used at UBS and incorporate it into Zope. This would have allowed TCL to interact as a first class citizen along with Perl. After much thought on the subject, we decided instead to partner with ActiveState (AS). This adds only Perl support (for the moment), but accomplishes a number of other goals, which will hopefully give the community some insight as to DC's direction on this. AS has significant Perl Zen, but has also recently hired some of the top Python talent around. They are embracing Python in a significant way, through Zope, but also as a standalone programming and scripting environment. For more on that, read: http://www.activestate.com/Corporate/Media_Center/News/Press959117519.html (the above will likely have wrapped poorly, and should be re-pasted as one long URL.) There's a more important point here though, and that is that if DC had taken my original approach, we'd have been in the business of managing the cross-platform codebase directly. In fact, that alone was one of the gating factors in not doing it. By outsourcing the cross-platform parts to AS, we each continue to concentrate on our own core competencies. For DC, that's Python, through and through. We've got a world-class team of Python experts, and that hasn't (and won't) change just because our platform will now allow others to hook their code into it. The people internally view this as a positive thing, so they don't feel that they will be forced to code in Perl. To reiterate, Zope is Python, and always will be. Meaning, the core of Zope will continue to be developed in Python (and C), and no one today envisions that changing. However, there was no uproar when we introduced XML-RPC. No one said "Hey, I don't want to be able to communicate with other systems, Zope rules, and others must perish!" Likewise, introducing a tighter coupling, giving others a choice in using their favorite language shouldn't cause you any more grief. To me, it's about "inclusion", not about change. I'm told that one of the protestations is that people will be expected to know Perl if they want to get a job coding in Zope. I guess I have a hard time understanding the problem here. Today, those shops that do most of their work in Perl, don't use Zope. So, they won't hire you anyway. Those who have already embraced Zope, will want you for your knowledge of Zope, and probably Python specifically. If Perl for Zope ends up getting Zope installed in a wider variety of shops and sites, then the above might become true. Wouldn't it also be true that there never would have been an opportunity for you to get a job there had they not adopted Zope either? My point is that if Zope gets wider adoption because it permits a wider range of programming choices to script its core, then more jobs will be available. At some shops, those jobs will have to be in Perl. But at others, "Best Practices" will rule, and we at DC (and I too) believe that this will continue to be Python. In fact, I could argue strongly that indeed even in the pure Perl shops that adopt Zope, they'll want/need a Python guru or two to track the core of Zope, in case they ever need to tweak that as well. This will create a larger job-base for the Python people than we have now. Here's my bottom line, and a bit of a rub as well. The Perl for Zope initiative is meant to be one which purely and simply helps the community, by broadening support for Zope, and getting it more widely adopted. DC is not intending to become a Perl consulting shop, so it likely won't have a near-term direct influence on our revenues. In fact, it will add to our expenses, as we support this wider community. So, we've undertaken this with a view toward others, rather than what's best for us in a "mercenary" sense. I would hope that you would all join us in that view and mission. Finally, I apologize deeply for the fact that I won't have the time to debate this interactively with the community. I will ask Paul to keep me up to speed on the nature of the responses, and if requested, or required, I'll post again with a summary follow-up of my views. I wish to conclude by repeating the original introduction here. I am a deep supporter of Python, as are all of the employees at DC. I am deep supporter of the Open Source movement, as are all of the employees at DC. I am deeply committed to keeping the core of Zope in pure Python and C, so that we can continue to deliver on the promise of our Services-based business. I hope that my prior actions on behalf of the community will at least earn me a "wait and see" attitude on the part of the community as to whether the above turns out to be true! Thanks for reading, and good luck to us all in this, and the remaining Zope Adventures!

3 2