- Zope - Zope lists

Perl Zope
by Adam Clark 26 May '00

26 May '00

Hope nobody minds a newbie perspective on this. I spent the last 4 years programming (and unabashedly loving) Perl, and I don't think adding Perl to Zope will attract a lot more people. The large scope of Zope and the similarities between Python and Perl mean that I've spent a whole lot more time struggling with the Zope pieces than with Python. What makes me most uncomfortable about this is the opportunity cost. Every hour of development time integrating Perl is one less hour 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. Just my $0.02 Adam

2 1

Re: [Zope] Re: [Zope-Annce] ANN: Perl For Zope - why I'm bummed
by Ken Manheimer 26 May '00

26 May '00

On 25 May 2000, Roman Milner wrote: > >>>>> "KM" == Ken Manheimer <klm(a)digicool.com> writes: > > KM> I have some misgivings with this outlook. It sounds like > KM> people who seek job security by having expertise with a system > KM> that closes out unfamiliar options - whether the options are > KM> better or worse. > > I'm not in any way unfamiliar with perl. If this had been a language > that I didn't know or, or any technology that I didn't know - I > would have an opened mind. I've been down the perl road, and have made a > personal choice never to do it again. I should have used "unwelcome" instead of "unfamiliar" in that sentence - i tried to say that in a number of ways, eg: Me> For all of you that love Python, and testify to either leaving perl Me> with great relief or not being willing to learn it in the first place > [...] > I think that anyone who wants to claim Zope expertise will need to > know and be willing to code in perl. I dunno. There may be some Zope jobs where knowing perl would be necessary, but there may also be some jobs where knowing XML, SQL, XLST(?), WebDAV, the ZODB, SSL, LDAP, Oracle, medusa, C, *all* sorts of things would be necessary. Maybe you're proficient with all those things - i'm not! The thing is, Zope is an extensible ORB whose primary purpose in life is to connect disparate things together - you shouldn't need to be proficient with every aspect of it, in order to have mastery with it. I guess i can understand being uncomfortable with seeing a transition from a somewhat closed, very attractive (python) world to a more wide-open one that includes less attractive elements. Nonetheless, i really think this ultimately means that your zope skills are going to be more valuable, whether or not they include the perl aspect, because zope as a whole will have wider acceptance, a firmer place in the world. (Do you think the perl folks are, conversely, going to feel they have to know python? I have to say, i esteem python enough to think that the ultimate result will be increasing prevalence and preference for python.) Ken Manheimer klm(a)digicool.com

1 0

RE: [Zope] The agony of the ZOPE Documentation
by Amos Latteier 25 May '00

25 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! I know that Zope's documentation is frustrating. However, I generally find searches on Zope.org to be helpful. I've forwarded your concerns to the Zope.org webmaster. I'd like to share some what Michel Pelletier and I have been doing to improve Zope documentation. * We conducted a poll to help us determine what was most needed. We found out that Zope docs are of middling quality and folks most want new user help. * We wrote an online help system for Zope and wrote help content for all management screens. Right now we are updating this content for Zope 2.2. The help system will ship with Zope 2.2 and an alpha is available right now. * We've started a Zope API documentation process. Right now there is an extensive Zope API documentation wiki on Zope.org. The fruits of this labor will be API docs that will ship with Zope in the online help system. Right now several API docs are complete and are included in the current 2.2 alpha. * We've overhauled Zope training materials and will make them available publicly in the next week or so. * We're still working on Zope Guides and References replacements. I think that the training materials will be quite useful for this effort. I hope to have Guide and Reference replacements done by the end of the summer. Thanks for listening. If you have specific comments or questions about Zope documentation, please don't hesitate to let me know at docs(a)digicool.com -Amos -- Amos Latteier mailto:amos@digicool.com Digital Creations http://www.digicool.com

1 0

ZopeDub-Babylon mix
by Jason Cunliffe 25 May '00

25 May '00

"... By the rivers of Babylon We sat down...Ahh Waiting for Zian ..." [ZopeInANutshell]

1 0

Re:[Zope] A similar issue with Perl for Zope
by Jason Cunliffe 25 May '00

25 May '00

Michel Pelletier <michel(a)digicool.com> wrote in message news:392D98AD.1592F4D9@digicool.com... > 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. Amen! - consistent object model - a map of the damn thing, with a poster of same which you can hang on your wall can meditate to - consistent interface syntax you can learn in 10 minutes and then repeat ad infinitum as you explore the map - "apples-for-apples" examples with side-by-side scripting language use [VBScript, JavaScript,PerlScript, PythonScript, etc..] - a welcome mat for all linguists - a copy of ZIAN [Zope-In-A-Nutshell] Jason ________________________________________________________________ Jason CUNLIFFE = NOMADICS.(Interactive Art and Technology).Design Director ________________________________________________________________ Jason CUNLIFFE = NOMADICS.(Interactive Art and Technology).Design Director

1 0

Re: [Zope] Re: [Zope-Annce] ANN: Perl For Zope - why I'm bummed
by Ken Manheimer 25 May '00

25 May '00

On 25 May 2000, Roman Milner wrote: > Well, my point is that I don't think you will be able to ignore it. > Your boss will give you a product to maintain that includes someone > else's perl code - sooner or later. Since it is "part of zope" and you > clearly "know zope" you should be able to maintain it. > > I'm not talking about maintaining zope itself. I'm talking about > maintaining web sites that use zope. I have some misgivings with this outlook. It sounds like people who seek job security by having expertise with a system that closes out unfamiliar options - whether the options are better or worse. For all of you that love Python, and testify to either leaving perl with great relief or not being willing to learn it in the first place - why don't you trust your judgement? Python *does* offer better a better foundation for persistence, acquisition, general object-oriented applications, etc - you should not be frightened of a level, open zope playing field that admits both python and perl! If you don't feel python is better, just what you prefer, then you should be happy to have the additional power of perl (and it's community) available to you without having to leave your favorite language! It's a win in either case. (And zope will never be an entirely level playing field, because python and C *will* continue to serve as the foundation for Zope. Oleg, your refutation of that has the smell of casting Fear, Uncertainty, and Doubt - treating digital creations with some serious and, i think, unwarranted disrespect, if i may say.) 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. It enables people to use facilities from other languages, without having to get their hands dirty with them. I never really learned C - but that doesn't mean i won't use other people's C extensions! Many many people have found Python to be the best way to get acquainted with Java, with jpython - and i wonder how many java folks got turned on to python's advantages, though the ability to use java interactively via jpython. Access to other languages via python isn't a problem, it's a solution - why should it be any different with Zope? Personally, i suspect that it's much less likely that someone will switch from python to perl than the reverse, perhaps a sign of my own python bigotry - but if you're similarly inclined, once again, i think you should appreciate the advantages of this new open door. Ken Manheimer klm(a)digicool.com

1 0

Architectural questions
by Roberto Faria 25 May '00

25 May '00

Hi everyone, I have recently joined a small software development team in South Africa comprising of the best object people in the country. We have been tasked to build a financial supermarket using the numerous distribution channels including the web, fax, email, wap. I am currently investigating the suitability of using Zope to implement my presentation layer (as apposed to using Java servlets). To complete my Zope study I need to answers to the following: (1) Is the Zope VM threaded? Do the VMs get pooled? What happens if a VM gets bloated and old? (2) Is there a limit to the number of objects in a Zope repository? Who is currently running the biggest Zope site in terms of Objects and hits per day? How many repositories are being used? Do you guys know of any other large python driven websites? (3) How does ZEO ensure View consistency when numerous clients are transacting? How are transaction conflicts handled? (4) Where is the transaction log stored? How does one rebuild a Zope database after a server crash? Can transactions be lost? (5) How does a development team debug DTML? (6) Does Zope provide any resource pooling such as the J2EE products? (7) How does one provide a 24x7 service? What happens if you need to upgrade the Zope server? (8) When will the object database provide indexed collections? Thanks in advance Roberto

1 0

Re: [Zope] Re: ZWiki Problems on Zope.org
by Simon Michael 25 May '00

25 May '00

"Rik Hoekstra" <rik.hoekstra(a)inghist.nl> writes: > I mailed you last week about changing the wiki_page_url method to > absolute_url. I did some experimenting with the method this week, > but found myself using things _very_ much like absolute_url > (URL1+parents+currentobjectid). You mentioned using absolute_url > would mean some types of acquisition couldn't be used. Would you > explain this, as I can't seem to see why this would be so, as > absolute_url _does_ use the current acquisition path. > > The use of absolute_url _did_ break the wiki_base_url, where I removed the > quote from the return method. Thanks Rik, I hope you don't mind me cc'ing the list. I moved away from absolute_url so as to preserve acquisition paths like those used in the zwiki_examples to implement different views of a wiki. /structured/wiki, /plain/wiki, etc. where / /wiki /structured /plain This has caused problems in other areas, like virtual hosting. I don't have a good fix at the moment. Anyone who is affected could try replacing the code in wiki_page_url() & wiki_base_url() with a call to absolute_url() to restore the behaviour of 0.5. Regards, Simon

1 0

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

25 May '00

>>>>> "HK" == Hannu Krosing <hannu(a)tm.ee> writes: HK> Some of its most significant features (Aquiition, HK> ExtensionClass) are even written in C and mess with guts of HK> python interpreter. HK> See for example PostgreSQL - it has C, SQL, PL/SQL, TCL, Perl, HK> Ruby and soon python as its server-side programming languages, HK> with no real argument about weather to include yet another HK> language - if you dont want/need/know how to use it you just HK> ignore it ;) And it was originally written in lisp ;-9 Well, my point is that I don't think you will be able to ignore it. Your boss will give you a product to maintain that includes someone else's perl code - sooner or later. Since it is "part of zope" and you clearly "know zope" you should be able to maintain it. I'm not talking about maintaining zope itself. I'm talking about maintaining web sites that use zope. ^Roman

1 0

SiteAccess and Subdomains
by J. Atwood 25 May '00

25 May '00

I am trying to get SiteAcess to work with a subdmain.. So I have added an empty SiteRoot in the /subdomain folder and added a DTML Method <dtml-let hostname="_.string.join(_.string.split(_.string.split(HTTP_HOST, ':')[0], '.')[-2:], '.')" sitemap="{'subdomain.domain.com': 'subdomain'}"> Do we have a match? <dtml-if expr="sitemap.has_key(hostname)"> Set the logical root: <dtml-call "REQUEST.set('SiteRootPATH', '/')"> Add physical root: <dtml-call "REQUEST.path.append(sitemap[hostname])"> </dtml-if> </dtml-let> But am not getting any anything (still just points to the root. Help? Thanks, J

2 1