- Zope - Zope lists

Wanted: graphic designer
by Bruce Byfield 29 May '00

29 May '00

Progeny Linux Systems, a Debian-based Linux development company, has an immediate need for a graphic designer to assist in the design of its corporate logo and website. Candidates should have experience designing websites on Linux using free software tools, and a portfolio of their work. This position is presently contract, but could develop into full-time, depending on results and the candidate's willingness to relocate. Contact jobs(a)progenylinux.com. -- Bruce Byfield, Outlaw Communications "The Open Road" column, Maximum Linux 3015 Aries Place, Burnaby, BC V3J 7E8, Canada bbyfield(a)axionet.com 604.421.7189

1 0

Zope-Edu Wiki
by Shane Hathaway 29 May '00

29 May '00

Your attention please! The following persons will report at once to the new Zope-Edu wiki at http://www.zope.org/Wikis/zope-edu . They will then proceed to the Contributors page, click the question mark by their name, and enter biographical information and what projects they are working on related to Zope in education. It may be necessary to first log in or create a new account. Serge Stinckwich, Timothy Wilson, Rik Hoekstra, Ron Gines, Van Lindberg, Chris Blackall, Darcy Clark, Chris Abraham, Jim Harrison, Robert Doiel, Alan Pogrebinschi, Bill Ries-Knight, Jim Washington, Paul Browning, Mark Levinson, Bryan Hann, Steve Spicklemire, Andrew Bunney, Phil Harris, Stuart Bishop, David Kankiewicz, LD Landis, Ray Thompson, Alexandre Ratti, Li Dongfeng, John Wenger, Ibañez Palomar Juan David, Henny van der Linde, Martin Dougiamas, John Edstrom, Bruno Vernier, Lamar Zabielski, Kent Tenney, PhilAustin. They are then requested to add their contributions to any page on the wiki. The former Zope-Edu list ( http://pi.slcc.edu/lists/zope-edu ) had a great deal of good ideas which need to be incorporated into the wiki, ideally by the original posters. Do not delay, soldiers! Shane P.S. I wrote this on Memorial Day. <g>

1 0

A new python object which analyse HTML files and...
by Frederic QUIN 29 May '00

29 May '00

Hello everybody, I would like to create a python object which : * analyse traditional HTML files * indexe "IMG" tags and "A" tags * replace "IMG" tags by appropriated dtml tags * replace "A" tags by appropriated dtml tags * create all the resultant objects Did someone ever do that ? Anyway, if someone with more experience than me, have some advices, I'll get them... Thanks Frederic

4 3

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