http://radio.weblogs.com/0100887/categories/zope/ Copyright 2002 Jon Udell Sat, 25 May 2002 10:55:41 GMT http://backend.userland.com/rss092 5/25/2002; 6:51:07 AM http://radio.weblogs.com/0100887/categories/zope/2002/05/25.html#a266 Jeffrey P Shell follows up with more on Zope Page Templates: <b>...</b> <P>Jeffrey P Shell follows up with more on Zope Page Templates:</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P><EM>Page Templates have a wonderfully clean syntax in the TAL/TALES combination. There are very few TAL attributes, and their operations and operational order are clearly defined. TALES eliminates much of DTML's guesswork by eliminating the whole "is it an expression? a literal? a name lookup?" game.</EM> </P></BLOCKQUOTE> <P dir=ltr>I should clarify my <A href="http://radio.weblogs.com/0100887/2002/05/23.html#a263">earlier comments</A> about ZPT. What I do in Zope, nowadays, requires minimal to no design. I have therefore abandoned DTML almost entirely in favor of Python Scripts which are so much cleaner and more powerful. From script, I emit quoted chunks of HTML. This works fine for a simple and purely functional application.</P> <P dir=ltr>Writes Jeffrey of DTML:</P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P dir=ltr><EM>Its namespace stack is a powerful but often untamed beast, and its full of grotesque shortcuts and workarounds. Anyone who's seen _[_['sequence-item']] knows what I mean.</EM></P></BLOCKQUOTE> <P dir=ltr>Yes. I finally decided to just say no to DTML. If and when I need to coordinate with heavily-designed pages, I'll certainly want to give ZPT a spin. It's just overkill for my needs right now.<BR></P> 5/23/2002; 9:08:06 AM http://radio.weblogs.com/0100887/categories/zope/2002/05/23.html#a263 <FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Jeffrey P Shell gives us a Zope insider's view of </FONT><A href="http://radio.weblogs.com/0106123/2002/05/22.html#a113"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>working with ZPT</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2> (Zope </FONT><A href="http://www.zope.org/Documentation/Articles/ZPT1"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Page Templates</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>). I'm a Zopista who's yet to take the plunge into ZPT, </FONT><A href="http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>TAL</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>, and </FONT><A href="http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TALES"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>TALES</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>. Jeffrey's essay confirms for me what I've suspected about these technologies: </FONT> <b>...</b> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Jeffrey P Shell gives us a Zope insider's view of </FONT><A href="http://radio.weblogs.com/0106123/2002/05/22.html#a113"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>working with ZPT</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2> (Zope </FONT><A href="http://www.zope.org/Documentation/Articles/ZPT1"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Page Templates</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>). I'm a Zopista who's yet to take the plunge into ZPT, </FONT><A href="http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TAL"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>TAL</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>, and </FONT><A href="http://dev.zope.org/Wikis/DevSite/Projects/ZPT/TALES"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>TALES</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>. Jeffrey's essay confirms for me what I've suspected about these technologies: </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>1. The learning curve (for me) would be fairly steep.</FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>2. The benefits would be substantial if I had to work closely with a GoLive- or Dreamweaver-based designer.</FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>We could further </FONT><A href="http://scriptingnews.userland.com/backissues/2002/05/19#l6cc7894806642236e3b8f4b0b7682163"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>triangulate</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2> on this if another ZPT user, ideally one less Zope-savvy than Jeffrey (who used to work for Digital Creations) were to weigh in.</FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>I can remember debates, a few years ago, about whether and how to implement a rating system for CPAN modules. The problem was (and is) that you go to CPAN, find four modules that address some problem, and can't easily figure out which would be right for you without investing a lot of time.&nbsp; A formal rating mechanism is fraught with problems. But the informal triangulation effects that we see happening in blogspace are becoming a Googlish solution.</FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Jeffrey said a while back, of his blogging experience, "</FONT><A href="http://radio.weblogs.com/0106123/2002/05/09.html#a99"><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>the sense of community hasn't really hit me yet</FONT></A><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>." Understood. It's more of an act of faith than it should be, right now, to put stuff out there as you've been doing. </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>A next level of organization will happen. Ad-hoc blog registries will surely emerge, around topics like Zope, and will restore some of the architecture of shared public space that we are currently sacrificing in order to make progress in other ways. </FONT></P> <P><FONT face=Verdana,Geneva,Arial,Helvetica,Sans-Serif size=2>Meanwhile I very much appreciate that Jeffrey has opened a window into his always-agile mind. I know others do too.</FONT></P> Industrie Toulouse 4/18/2002; 3:39:10 PM http://radio.weblogs.com/0100887/categories/zope/2002/04/18.html#a197 I had a nice response to a recent <A href="http://www.byte.com/documents/byt1018644007316/">column on Zope</A> from Jeffrey P Shell, a longtime Zopista and former Digital Creations guy who has decamped&nbsp;to&nbsp;the skiiing life in Utah. Jeffrey wrote one of the first BYTE columns on Python, longer ago than the web seems to remember. Anyway, in my column I talked about scripting Zope from the outside, using the RESTian approach of reverse-engineering its HTML management forms and calling them as URLs. I knew that XML-RPC was another way to do this. Jeffrey pointed out a third, little-known approach that taps into Zope's "lizard brain." <b>...</b> <P>I had a nice response to a recent <A href="http://www.byte.com/documents/byt1018644007316/">column on Zope</A> from Jeffrey P Shell, a longtime Zopista and former Digital Creations guy who has decamped&nbsp;to&nbsp;the skiiing life in Utah. Jeffrey wrote one of the first BYTE columns on Python, longer ago than the web seems to remember. Anyway, in my column I talked about scripting Zope from the outside, using the RESTian approach of reverse-engineering its HTML management forms and calling them as URLs. I knew that XML-RPC was another way to do this. Jeffrey pointed out a third, little-known approach that taps into Zope's "lizard brain." </P> <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px"> <P><EM>Did you know that Zope has always had a simple RPC mechanism, predating XML-RPC, and even predating Zope itself? There was a little piece of Bobo, which is now ZPublisher, called 'bci' for 'Bobo Call Interface'. I'm almost ashamed that more wasn't done to promote BCI, or turn it into an actual RPC mechanism (it doesn't marshal return data), because XML-RPC, while simple, is just a little too simple (no concept of None/NIL? No concept of authentication except as part of the API?). And SOAP.. *sigh*.</EM></P> <P><EM>Anyways, ZPublisher.Client (which can be used without any other Zope modules, so you could install a copy of it into a common place) is another wy to do that Perl script that you wrote, while maintaining a cleaner syntax than writing a long URL. It basically generates the same URL (with all of the correct Zope marshalling, although I don't know if it knows of the more recent marshalling options) and does the same job.</EM></P><PRE><EM><FONT face=Verdana>from ZPublisher.Client import Object myCatalog = Object (<BR>&nbsp; <A href="http://host:port/repository/myCatalog"><a href="http://host:port/repository/myCatalog">http://host:port/repository/myCatalog</a></A>) <BR>myCatalog.manage_catalogFoundItems( <BR>&nbsp; obj_metatype=['Image', 'File'], <BR>&nbsp; obj_permission="Access contents information", <BR>&nbsp; search_sub=1, btn_submit="Find and Catalog"<BR></FONT></EM></PRE> <P><EM>You can see the similarities to XML-RPC, which you might even be able to use in this situation, but there are some niceties about BCI. When constructing a ZPublisher.Client.Object or ZPublisher.Client.Function method, you can specify a username and password and you will be authenticated over Basic Auth. You can specify which HTTP method to use (GET/POST/PUT). You can upload files just by passing a Python file object (basically anything with a 'read()' method).&nbsp; You can also catch remote exceptions. While I recognize that XML-RPC has the concept of 'fault', for more intimate Zope scripting, sometimes more knowledge of the cause of the fault is required. This is the only real marshalled data that ZPublisher.Client (BCI) sends back.</EM></P></BLOCKQUOTE> <P dir=ltr>Cool! By the way, Jeffrey is trying out <A href="http://radio.weblogs.com/0106123/">a blog</A>. I hope he sticks with it. He's a wonderfully thoughtful and articulate writer, and a really clever guy.&nbsp; l&nbsp; bet he'll have OmiOutliner hooked in before long.</P> <P dir=ltr>Looking into blogspace with fresh eyes, Jeffrey wondered "Why write when there's so much else to do? Who's reading?" </P> <P dir=ltr>These are&nbsp;great questions. I of course get paid for my writing, though not for what I write here. But what about most folks? Why write? Who will read? Lots of people have lots of different reasons. For me, it's&nbsp;mainly about optimizing information flow and managing attention.&nbsp;In a <A href="http://www.byte.com/documents/byt20010524s0001/">recent column</A> I explored the idea of storytelling as a tool for project coordination. That's closely related to what Dave Winer means&nbsp;by "narrating work" (and is demonstrating in his outline). We do this narration all the time in interpersonal email. Something interesting happens when we instead write <A href="http://radio.weblogs.com/0100887/2002/01/23.html#a35">messages addressed to spaces</A>.&nbsp;</P> <P dir=ltr>Defining why it's interesting is&nbsp;hard to do. But I'm closing in on it. Today I realized the following <A href="http://www.byte.com/documents/byt1016214357418/">analogy</A> may hold:&nbsp;loosely-coupled message-driven architecture,&nbsp;the&nbsp;mantra of the web services movement, is precisely what blogspace is becoming for the realm of human communication. When we adopt this style of communication, we give up some of the benefits of tight coupling: message acknowledgement, tight feedback loops. But we gain (maybe) the ability to scale beyond what is possible when tightly-coupled messaging (email, discussion groups) is the only available mode. This doesn't mean there's no benefit to tightly-coupled interpersonal messaging.&nbsp;It only suggests that the loosely-coupled mode is also important.</P>