[ANN: Zope source and binaries for Windows v3]
Hi all, I've posted a new release of the Zope source (and binary) patches. Located at http://student.uq.edu.au/~s341625/ temporarily until I move to a machine with a faster network connection. This file includes: * Binaries for Zope under windows * Makefiles for Visual C 5.0+ * Scripts to generate the above You need the Python 1.5.2 and Zope a2 sources to use the binaries. What's new? * Patches & fixes so it works with SquishDot * Streamlined install * Binary patches so the DC staff can get back to work instead of answering questions about windows binaries ;) * Modified README.txt slightly NOTE: This file is completely unsupported but does work;) I suggest people using old versions upgrade as old versions may have other, undiscovered bugs. Cheers all, Anthony Pfrunder
Tired of typing <!--#foo--><!--#/foo--> until your fingers bleed? Eyes going numb trying to read unindented (and unindentable because it would change the output) DTML code? Ever wished you could return something other than a string from a DTML method, so you wouldn't have to write an ExternalMethod? Waiting with bated breath for a "safe Python method" product? Or perhaps you'd like to easily do streaming output from Zope without dropping to Python? Well, guess what... now you can fix 80-90% of the above, with the new, free (and absolutely without warranty), ZScript classes. In a ZScript, you can write DTML like this: ================================================ if spam with "foo.bar" let goats="fish and not fowl" #embedded comment \ pigs="green.eggs and ham" \ fool="'on the hill'" # Make sure we use the widget! call "manage_editProperties(...)" /let /with else return "['red','herring']" end if call "RESPONSE.redirect('/wazoo')" ================================================ Notice that each tag *must* begin on a seperate line, with no exceptions. \ is used to continue tag arguments on subsequent lines. # begins a comment which runs until the end of the line. There is no "content" here - ZScripts always return an empty string unless a var or similar tag was executed in the script body. Also notice that you can use "/tag" or "end tag" to close blocks as suits your fancy. Indentation is ignored unless it's part of a quoted argument to a tag (in which case it's passed through to the tag's parser), so you have to close all of your blocks. The ZScript classes also add a 'return' tag which can take a name or expr, just like var. Unlike var, however, the result is not converted into a string, but instead is returned to the ZScript's caller, breaking out of the entire method in the process. With this addition to the existing DTML vocabulary, ZScript can do pretty much all the "safe" things Python can. (The only significant item remaining is setting local variables, but that'll have to wait till I upgrade DT_Let to support a 'set' block continuation. Arguably, a "finally" clause for the try tag would be the only other ommission to speak of.) Because ZScripts can't contain any "content", you must use var or similar tags to insert any constant text. If you're doing significant content, you should put it in regular DTML methods and call them from your ZScript. The benefit of not generating any text by default, is that it makes 'return' more useful, and also allows you to do streaming output using: call "RESPONSE.write('text')" and call "RESPONSE.flush()" Thus, you can display in-progress data as a complex method executes. Of course, if an error occurs in your script once a RESPONSE.write() has taken place, no error message will be displayed (although any side-effects of standard_error_message or other error handlers would still apply). This is because there's no way to "take back" streamed output, and the current HTTPResponse class doesn't check for streamed output when outputting exception data. Still, if you can accept this limitation, streamed output can easily be yours. Obligatory disclaimers: I wrote this code today, because I just had the idea and I couldn't get it to go away. It has received only minimal testing, which attempted to exercise all the code paths through the parser. That doesn't mean that all the paths actually got tested, that it doesn't have bugs, or that it will work in your application. Also, it is an extension of DocumentTemplate, not a Zope Product, so some Productmeister (perhaps the folks at DC?) will need to package it up as a Product if you want to be able to drop ZScript Methods into a Zopelication. Finally, it installs the 'return' tag globally, which means return can be called from regular DocumentTemplates. This will throw an exception unless the template was called from inside a ZScript, in which case the ZScript will act as though the return came from within itself. But anyway, if you like living dangerously, can implement a Product with one hand behind your back, and don't mind tinkering with alpha software, then copy this file into your DocumentTemplate package directory: http://telecommunity.com/DT_Script.py Please note that if you want to use the 'let' tag as shown in the examples, you will also need to import: http://telecommunity.com/DT_Let.py Finally, to use a ZScript once the package(s): from DocumentTemplate.DT_Script import ZScript, ZScriptFile, ZScriptDefault And then use any of the three classes as you would the corresponding DocumentTemplate.HTML* classes. Don't forget to import DT_Let if you want the 'let' tag as well.
"Phillip J. Eby" wrote:
(snip) .. Ever wished you could return something other than a string from a DTML method, so you wouldn't have to write an ExternalMethod? Waiting with bated breath for a "safe Python method" product?
(snip)
The ZScript classes also add a 'return' tag which can take a name or expr, just like var. Unlike var, however, the result is not converted into a string, but instead is returned to the ZScript's caller, breaking out of the entire method in the process.
I like the idea of the return tag so much, I just checked it in. In Zope 2.0, DTML will have a return tag that works as you describe. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Way cool. Guess I can simplify the ZScript code a bit now, and drop out the return tag stuff. :) I'm also feeling a certain amount of ego inflation since I can now bag bragging rights for having proposed and/or contributed code for, three 'core DTML' tags. By the way - why did you make return an always-loaded tag instead of a dynamically loaded one the way let, try, raise, with, etc. are? At 02:28 PM 6/30/99 -0400, Jim Fulton wrote:
"Phillip J. Eby" wrote:
(snip) .. Ever wished you could return something other than a string from a DTML method, so you wouldn't have to write an ExternalMethod? Waiting with bated breath for a "safe Python method" product?
(snip)
The ZScript classes also add a 'return' tag which can take a name or expr, just like var. Unlike var, however, the result is not converted into a string, but instead is returned to the ZScript's caller, breaking out of the entire method in the process.
I like the idea of the return tag so much, I just checked it in.
In Zope 2.0, DTML will have a return tag that works as you describe.
"Phillip J. Eby" wrote:
Way cool. Guess I can simplify the ZScript code a bit now, and drop out the return tag stuff. :)
I'm also feeling a certain amount of ego inflation since I can now bag bragging rights for having proposed and/or contributed code for, three 'core DTML' tags.
Actually 4: 'with', 'call', 'let' and 'return'.
By the way - why did you make return an always-loaded tag instead of a dynamically loaded one the way let, try, raise, with, etc. are?
Because I needed to import the module, which also exports an exception type that gets used in exception handlers in DT_String and DT_Try. (Return values are propigates via an exception.) Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
At 10:06 AM 7/1/99 -0400, Jim Fulton wrote:
"Phillip J. Eby" wrote:
Way cool. Guess I can simplify the ZScript code a bit now, and drop out the return tag stuff. :)
I'm also feeling a certain amount of ego inflation since I can now bag bragging rights for having proposed and/or contributed code for, three 'core DTML' tags.
Actually 4: 'with', 'call', 'let' and 'return'.
I forgot about "call", mainly because you came up with the name - I proposed it as "do", if you recall. :) I similarly don't count the "_.namespace" feature among my brags, because you not only named it, but I wasn't really proposing it as an addition in the first place. You just liked the idea and ran with it. :)
At 10:06 AM 7/1/99 -0400, Jim Fulton wrote:
Because I needed to import the module, which also exports an exception type that gets used in exception handlers in DT_String and DT_Try. (Return values are propigates via an exception.)
Duh. I didn't think about that part, because in the ZScript module, the try block that does that is in the same module where the exception is defined. :) Actually, it's kind of funny - at first when I looked at your code, I thought you had lifted it from the example in ZScript, and then I realized we just both did the exact same thing: copied the code from the 'var' tag and hacked on it a little. :) Speaking of peeking over your shoulder, I see some new goodies appearing in ZPublisher's type marshalling code. If you have a moment to comment on the new "record" type, I'd love to know what's up with that. If not, that's cool, I'll just try and figure it out from the source. :)
participants (3)
-
Anthony Pfrunder -
Jim Fulton -
Phillip J. Eby