- Zope-Dev - Zope lists

ANN: VisualZope 0.1alpha
by Anthony Pfrunder 14 Nov '99

14 Nov '99

Hi, VisualZope 0.1a is now available! It has the following features: * Included "GeoCities" watermark example widget * Two behaviours - draggable and resizeable (resizing may not occur) * Extensive code streamlining and documentation in tutorial format (the README_txt files) It should be easy to create simple floating and inline widgets with this version. A static (non-active) version of the UI is provided under the Editor tag. Note, behaviours cannot be recursive at the moment. Further info is available at: http://163.182.196.200/zwiki/VisualZope (download via the "available" link) Cheers, Anthony Pfrunder

1 0

Re: [Zope] DTML Syntax contd. + rant
by Ethan Fremen 13 Nov '99

13 Nov '99

Here's my take: When my bid was accepted to redesign the site I'm working on, I settled on Zope instead of PHP (it compiled without error.) I knew nothing about Python or Zope. Now I'm happily using Zope and I just got Learning Python. I'm not very far into it, but just learning some of the basics I'm starting to realize how close to the surface Python is. I would love to see Python Methods take over more of the "engine" behavior from DTML. I assume, however, that ngDTML would still include things like <dtml-in>, otherwise I'll pull my hair out. I also think there's some things that can/should be pushed elsewhere- REQUEST.set is a good example- I get a content-type for images, why not let me do that with other objects? Maybe the drop-down list of properties could be like the object-selection, so you could add new property types (content-type, tinytable...) Simultaneously, the last thing I want to see is for HTML to get imbedded in python. I used a Perl module where I built forms programmatically, and I don't want to go back to that. I've spent most of my time on this project getting out from under some developer who thought implementing HTML in javascript was a good idea. I'm also frustrated with things like TreeTag.py that imbed HTML into them, not allowing me to change their output to fit my fancy. I don't really have a problem with PythonMethods being scattered throuought my hierarchy: indeed, if they live with aquisition the same as everybody else, this could be quite useful. (as an aside, I'd like to be able to use factories like this, so that certain objects are only creatable at certain places in the hierarchy) Perhaps if DTML has a consistent method of dealing with things passed to/from npythonMethods, and a way of invoking them (dtml-call?), they would be more used. I know I stay as far away from the _ stuff as I can. If I have to use one of those _[blarg._['foo']] things, i copy it from someone else and hope that it works. It sure reminds me of something somebody called another language- "executable line noise". anyway, python seems to me to be a transparent enough language that there's no compelling need to obfuscate it for things it does well enough already. Plus, the "closer" python is in the upgrade path from content manager -> developer -> zope source contributor, the sooner you'll have more of the latter. wannabe zope hacker, -- Ethan "mindlace" Fremen you cannot abdicate responsibility for your ideology.

1 0

ZDOM BUGS: Anyone know a workaround?
by Anthony Pfrunder 13 Nov '99

13 Nov '99

Hi, I've found two bugs in the ZDOM (Zope/Lib/Python/Ofs/ZDOM.py) and was wondering if someone knew a workaround. 1 - getAttributes() only returns attributes of type string, not tokens, selections etc. Example: * Add some properties of various types to a ZClass instance * Add the following to a Python Method of the ZClass: parameters: self, REQUEST t = '' for i in self.getAttributes(): t = t + i.getNodeName() + ',' + i.getNodeValue() return t * View the Python Method of the zclass instance (ie tryit) 2 - REQUEST throws "Unauthorized access" for objects stuffed into it. Even as superuser you get the unauthorized message. Example: * Create an XML document (myxml) in the ZClass * Create a Python Method: parameters: self, REQUEST REQUEST.set('node', self.myxml.getFirstNode()) return self.dump(REQUEST) * Create a DTML Method (dump): <dtml-var "node.getNodeName()"> * View the Python Method of the ZClass (ie TryIt) Anyone? Anthony Pfrunder

1 0

Adding a Control Panel?
by Stefan Langerman 13 Nov '99

13 Nov '99

Hi, I am getting tired of manually downloading packages, esp. since I access my server remotely, and it's a pain to have to telnet to do the job, so I thought it would be a good idea to make a control panel to download and install products automatically. You would just provide the URL of the product tarball, and that would be it. If this thing works, then what about adding an automatic install button on the zope Products pages. Your Zope member info could contain the name(s) of your server(s), and the install button would just link to something of the kind: http://yourserver.org/install?http://www.zope.org/.../stuff.tgz Wouldn't that be cool? Anyway, I am trying to do this, but since this is my first serious Zope thing, I would need some help. Here are my questions: - Can I add something to the ApplicationManager? How do I do this? - Another way would be to add an entry to the manage_options of the ProductFolder, but again, I have no clue on how to do that. - How should I package my thing? In a Product or some external method or something else? Product seems to be cleaner, but I really haven't seen anything like what I want to do... Any suggestions are welcome. Altough I am a newbie, I am good at learning from examples, so feel free to throw sample code at me from similar projects, or just give me some pointers to code/doc/faq. Thanks, Stefan.

1 0

Re: [Zope-dev] Generated Images Again
by Jeff Rush 13 Nov '99

13 Nov '99

On Fri, 12 Nov 1999 11:48:33 -0800, David S. Harrison wrote: >Well, this successfully calls the function but substitutes >the bits from the PNG image directly into the <IMG> tag. >I mean the image tag becomes: '<IMG SRC="jfdla;jgadjklh32kjhkjhfdkahlfdsa;'g...">' >where the garbage is the bits from the image. The browser barfs >on this in a major way. Looks like it is still not quite there. You need to look at it as two transactions -- one to generate the HTML and another when the browser _comes back_ and gets the image. Now since you can't easily cache the image btw those two times, you need to defer generation of the image until the browser asks for it. So in your DTML code, you need to return a URL indicating _where_ to get the image and _what parameters_ to use when doing so. <IMG SRC="<dtml-var SCRIPT_NAME>/GenerateImage?xsize=300&colors=16">> And then create an external method named "GenerateImage" that looks like: def GenerateImage(self, xsize=800, ysize=600, colors=256, REQUEST=None, RESPONSE=None): # Spin the Pixels -now- ..... if REQUEST and 'image/png' in map(strip, split(REQUEST.get_header('Accept', ''), ',')): outformat = 'PNG'; outmime = 'image/png' else: outformat = 'GIF'; outmime = 'image/gif' if RESPONSE: RESPONSE.setHeader('content-type', outmime) ofd = StringIO() ; im.save(ofd, outformat) return ofd.getvalue()

1 0

Re: [Zope-dev] Generated Images Again
by David S. Harrison 12 Nov '99

12 Nov '99

"Andrew M. Kuchling" wrote: > This isn't invoking your function; read the DTML manual about > <dtml-var>. Instead, try this: > > <IMG SRC="<dtml-var "GenerateImage(RESPONSE,arg)">"> Well, this successfully calls the function but substitutes the bits from the PNG image directly into the <IMG> tag. I mean the image tag becomes: '<IMG SRC="jfdla;jgadjklh32kjhkjhfdkahlfdsa;'g...">' where the garbage is the bits from the image. The browser barfs on this in a major way. Looks like it is still not quite there. David S. Harrison (dsh(a)magma-da.com)

2 1

Re: [Zope] DTML Syntax contd. + rant
by Stuart 'Zen' Bishop 12 Nov '99

12 Nov '99

(Originally to zope, but should have been to zope-dev) On Wed, 10 Nov 1999, Martijn Faassen wrote: > If I ever get the time I'd be tempted to work on a DTML 'cleanup' > project. DTML is currently *far* too much like Perl and not enough like > Python. *some* easy things are very easy, but as a consequence some > other easy things become far too hard, or at least look far too > complicated. You can spell the same thing in too many ways. The > community encourages and praises additions for convenience (like the > 'default' option, or the new extended &entity; syntax) but as a result > DTML loses its conceptual integrity. It becomes too big and not easy to > understand. > > I understand the argument that DTML shouldn't be used for complicated > purposes, and that you should use Python. This is fine and good, but in > practice people *do* use DTML for complicated purposes. ZClasses in fact > encourage this. > > DTML should be more like Python. Luckily the Zope framework does allow > new objects to be plugged in using something else than DTML, so not all > hope is lost. :) > > Feedback on this rant would be appreciated. I'm with you 100%. It makes me feel like I'm programming a reverse polish calculator sometimes :-) A low-level user (one not confidant in writing external methods) shouldn't have use magic constructs like <dtml-var "_['sequence-item'].title_or_id()"> dtml-in is the main culprit - a synonyms for the magic variables that conform to python naming standards need to be created and the old ones depricated. Is there any reason why I should fix this and submit the patch for 2.1? (or 2.2?) Possibly REQUEST needs to be available through aquisition rather than having to be passed to everything. How about <dtml-python> print "<p>" print html_quote('''The <dtml-ver2> tag is executed, the code contained between the tags simply writing to standard out to produce the rendered version.''') print '''<p>This could be done either through stealing from the existing PythonMethods code if it can be proven to be as secure as DTML''' if untrusted_pythonmethods: print '''<p>An alternative approach would be to run the code using r_eval. A BastionClass wrapper would be used to protect access to objects - the code would initially only have access to the bastionised _ object, and all the getattr and getitem methods would aquire objects as normal, but return another bastion wrapper instead of the real object. <p>Of course, this may be how PythonMethods already works for all I know....''' print ''' <p>Currently, calling python functions needs to be done through the current namespace, with calls like _.string.split(...). This seems arse over tit - wouldn't it conceptually be better to use a prefix for aquisition? _.standard_html_header() for example - this makes it much clearer IMHO what is going on and easier to grasp. It might be too late in the day to change this however.''' </dtml-python> Is existing DTML good enough for 'simple' scripting? I think the current confusion threshold occurs when people start needing to pass parameters to methods (and the whole quoted and unquoted thing kicks in, and suddenly they have to understand about the _ namespace, and the magic variables to pass a DTML method to make it work). - Zen, who is still a bit grumpy today. ___ // Zen (alias Stuart Bishop) Work: zen(a)cs.rmit.edu.au // E N Senior Systems Alchemist Play: zen(a)shangri-la.dropbear.id.au //__ Computer Science, RMIT WWW: http://www.cs.rmit.edu.au/~zen

13 20

Re: [Zope] Setting SERVER_NAME for ZServer
by Bill Anderson 12 Nov '99

12 Nov '99

Itamar Shtull-Trauring wrote: > > The ZServer SERVER_NAME can be set by editing ZServer/medusa/http_server.py, > and adding > > server.server_name = "www.example.com" > > at line 554, right before server_port is set but after the unwanted > server_name is set, so the new value replaces the unwanted one. > Any reason the following code: ---------------------------------------- if not ip: self.log_info('Computing default hostname', 'warning') ip = socket.gethostbyname (socket.gethostname()) try: self.server_name = socket.gethostbyaddr (ip)[0] except socket.error: self.log_info('Cannot do reverse lookup', 'warning') self.server_name = ip # use the IP address as the "hostname" ---------------------------------------- can't be replaced with: ---------------------------------------- if not ip: self.log_info('Computing default hostname', 'warning') ip = socket.gethostbyname (socket.gethostname()) try: self.server_name = os.environ['SERVER_NAME'] except KeyError: self.server_name = socket.gethostbyaddr (ip)[0] except socket.error: self.log_info('Cannot do reverse lookup', 'warning') self.server_name = ip # use the IP address as the "hostname" --------------------------------------- And then the start script (or Zope.pcgi) could then set SERVER_NAME prior to calling the server proper? Just curious ... Bill -- "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." -- Carl Sagan

1 0

Generated Images Again
by David S. Harrison 12 Nov '99

12 Nov '99

As you might recall, I am on a quest to get Zope to serve up automatically generated images. I am nearly there. In a simple example, my DTML looks like the following:  <h2></h2> <p> <IMG SRC="GenerateImage"> </p>  My external method kind of looks like this: def GenerateImage(self, RESPONSE): bits = functionThatWritesImageIntoAString() RESPONSE.setHeader('content-type', 'image/png') return bits This works fine. However, functionThatWritesImageIntoAString() actually takes arguments. So, I attempted the following: def GenerateImage(self, RESPONSE, arg): Then I tried several possibilities in DTML: <IMG SRC="GenerateImage(arg)"> <IMG SRC="GenerateImage(RESPONSE,arg)"> I tried permuting arguments. I can't convince it to work. It appears that I don't know the magic to tell Zope to pass arguments to the external method. I am looking for suggestions. There is a really nasty workaround: I could use <dtml-call> before the <IMG> tag to pass arguments implcitly (through globals) to the GenerateImage method. But this seems really ugly. I am looking for a more graceful solution. David S. Harrison (dsh(a)magma-da.com)

1 0

Re: [Zope] Setting SERVER_NAME for ZServer
by Bill Anderson 12 Nov '99

12 Nov '99

Itamar Shtull-Trauring wrote: > > The ZServer SERVER_NAME can be set by editing ZServer/medusa/http_server.py, > and adding > > server.server_name = "www.example.com" > > at line 554, right before server_port is set but after the unwanted > server_name is set, so the new value replaces the unwanted one. > Any reason the following code: ---------------------------------------- if not ip: self.log_info('Computing default hostname', 'warning') ip = socket.gethostbyname (socket.gethostname()) try: self.server_name = socket.gethostbyaddr (ip)[0] except socket.error: self.log_info('Cannot do reverse lookup', 'warning') self.server_name = ip # use the IP address as the "hostname" ---------------------------------------- can't be replaced with: ---------------------------------------- if not ip: self.log_info('Computing default hostname', 'warning') ip = socket.gethostbyname (socket.gethostname()) try: self.server_name = os.environ['SERVER_NAME'] except KeyError: self.server_name = socket.gethostbyaddr (ip)[0] except socket.error: self.log_info('Cannot do reverse lookup', 'warning') self.server_name = ip # use the IP address as the "hostname" --------------------------------------- And then the start script (or Zope.pcgi) could then set SERVER_NAME prior to calling the server proper? Just curious ... Bill -- "They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown." -- Carl Sagan

1 0