Is it possible to have an external method return a string which would be treated by zope as a dtml page, i.e. to have the return string contain dtml commands which would execute?
On Thu, 2003-10-23 at 18:02, Ted holden wrote:
Is it possible to have an external method return a string which would be treated by zope as a dtml page, i.e. to have the return string contain dtml commands which would execute?
Possibly... but it wouldn't be easy and it's hard to imagine why it would be necessary or desirable. You can pass parameters to DTML (or better yet, Python) and you can call arbitrary methods/names from the DTML namespace. Between these two abilities, you should be able to code up just about anything. If that's not hard-core enough, Python is perfectly capable of executing self-generated code: ---
exec 'a = "hello world"' a 'hello world'
You'd need to do that in an external method or product. You may wish to look up the compile and eval statements if you plan on doing this regularly. Perhaps you could provide an example of the problem you're trying to solve & we can take a whack at the easiest way to solve it? Dylan
On Friday 24 October 2003 00:51, Dylan Reinhardt wrote:
... Perhaps you could provide an example of the problem you're trying to solve & we can take a whack at the easiest way to solve it?
Dylan
Again, thanks. I pretty much gave up on using zclasses and products at least for the time being, and I've actually gotten something like 98% of the application working; there's just the one little detail left. This is a text indexing and retrieval methodology and the assumption is that an organization has a directory containing text files or some sort of files with ascii text in them, which it wishes to make available to users over the web. This might consist of large numbers of html files as is the usual case, or it could just as easily consist of two or three large or gigantic files, possibly several gigabytes. The user enters a search term, and the application returns a list of hits in the form of file-name/byte-offset pairs, e.g.: Verified hits * /home/bear/Text/SHAKE/MACBETH 71680 * /home/bear/Text/POE/ANNABEL 0 * /home/bear/Text/POE/ELDORADO 0 Now, once that screen comes up (is returned by the application and displayed), I'd like to have the user be able to click on one of the lines and thereby execute a method which would read a couple of thousand bytes around the indicated byte offset in the given file, and display them. The problem is that once a screen like that returns, you're outside the confines of zope and dtml. Inside a dtml method, something like: <a href=<dtml-call 'function('arg1', 'arg2')"> > first hit </a><br> works well enough. That's basically the kind of effect I need. I'm guessing at this point that the best shot might be to write the list of hits to a file, and then return a handle to a dtml file which would pick up the list of hits from the file and do the right things with them, and include the user's name or id in the name of the hit file to keep users separate. The question at that point would be whether an external method could return the handle of a dtml method created within Zope or whether something like dtmlfile could work outside of zclasses. That's just a guess; I'd be glad to hear any suggestions. Ted
On Fri, 2003-10-24 at 07:40, Ted holden wrote:
This is a text indexing and retrieval methodology and the assumption is that an organization has a directory containing text files or some sort of files with ascii text in them <snip> Now, once that screen comes up (is returned by the application and displayed), I'd like to have the user be able to click on one of the lines and thereby execute a method which would read a couple of thousand bytes around the indicated byte offset in the given file, and display them.
OK. Sounds like a Zope system so far.
The problem is that once a screen like that returns, you're outside the confines of zope and dtml.
Yep. By the time that screen renders, you're waiting around for the client to make their next request.
Inside a dtml method, something like:
<a href=<dtml-call 'function('arg1', 'arg2')"> > first hit </a><br>
works well enough. That's basically the kind of effect I need.
Sounds workable... what is it about passing the user a correctly-formed link that doesn't meet your needs?
I'm guessing at this point that the best shot might be to write the list of hits to a file, and then return a handle to a dtml file which would pick up the list of hits from the file and do the right things with them, and include the user's name or id in the name of the hit file to keep users separate.
I'm a bit confused at this. Is this a logging solution? A caching solution? In terms of performance, it's tough to see how it could possibly improve on knowing a file name and a byte offset.
The question at that point would be whether an external method could return the handle of a dtml method created within Zope
Sure. The easiest thing to do is return a string that corresponds with a dtml method (or anything) available in the current namespace. Ex: <dtml-call "REQUEST.set('some_name', ext_method(arg1, arg2))"> <dtml-var "_[some_name]"> You could also grab a reference to a method, but it's not clear what that could gain you in this situation. Are you trying to embed dtml tags in your text documents? If so, why not just store them as dtml methods in the ZMI?
or whether something like dtmlfile could work outside of zclasses.
Well... you can create a DTML method anywhere in the ZMI. Perhaps you want to use a Python script to coordinate the efforts of DTML methods and external methods. Honestly, I'm not entirely clear what the goal is, so it's tough to say.
That's just a guess; I'd be glad to hear any suggestions.
Sorry I couldn't offer better ones. Maybe some more detail about your problem would help. HTH, Dylan
On Friday 24 October 2003 12:35, Dylan Reinhardt wrote:
Sounds workable... what is it about passing the user a correctly-formed link that doesn't meet your needs?
Not in all cases. I could easily end up passing him a link to a half gigabyte file, and I suspect he'd not be happy...
I'm guessing at this point that the best shot might be to write the list of hits to a file, and then return a handle to a dtml file which would pick up the list of hits from the file and do the right things with them, and include the user's name or id in the name of the hit file to keep users separate.
I'm a bit confused at this. Is this a logging solution? A caching solution? In terms of performance, it's tough to see how it could possibly improve on knowing a file name and a byte offset.
No caching. All I'm trying to do is get that filename and offset to another external method while avoiding all the catch-22s and sticky-wickets and what not.
The question at that point would be whether an external method could return the handle of a dtml method created within Zope
Sure. The easiest thing to do is return a string that corresponds with a dtml method (or anything) available in the current namespace. Ex:
<dtml-call "REQUEST.set('some_name', ext_method(arg1, arg2))"> <dtml-var "_[some_name]">
Sorry but I don't quite understand that. I need to have the external method return something which causes a dtml page to be acted upon and shown. Presumably I have a dtml page called dtmlpage1 and an external method called externalmethod1 both registered within the folder I'm using in zope: what exactly does the python function associated with externalmethod1 need to return to ensure that the next thing the user sees on his browser is dtmlpage1? I'm assuming also that the external method cannot return both a list of file and offset pairs and the information to execute a dtml page, which is why I assume I'd need to save the list to a file and have the dtml page pick it up. Ted
On Fri, Oct 24, 2003 at 01:33:09PM -0400, Ted holden wrote:
Presumably I have a dtml page called dtmlpage1 and an external method called externalmethod1 both registered within the folder I'm using in zope: what exactly does the python function associated with externalmethod1 need to return to ensure that the next thing the user sees on his browser is dtmlpage1?
two options in your external method function: 1) REQUEST.RESPONSE.redirect('/path/to/the/dtml?param1=foo¶m2=bar') this limits you to whatever parameters you can stuff into a query string. 2) my_dtml = self.unrestrictedTraverse('/path/to/the/dtml') return my_dtml(args) ... where the args needed for calling a DTML mehod or document are specified in teh online Zope book, in the API reference and also in the Advanced Scripting chapter. I haven't done this in a long time so i forget the signature DTML call signature. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE SUPERDEAD PELICAN! (random hero from isometric.spaceninja.com)
On Fri, 2003-10-24 at 10:33, Ted holden wrote:
On Friday 24 October 2003 12:35, Dylan Reinhardt wrote:
Sounds workable... what is it about passing the user a correctly-formed link that doesn't meet your needs?
Not in all cases. I could easily end up passing him a link to a half gigabyte file, and I suspect he'd not be happy...
So don't do that. :-) Pass a link to a *method* that takes the filename and offset as arguments. Assuming you want a per-page limit of 1024 bytes, have your method return the first 1024 bytes after the specified offset. While you're rendering that content, you should include a "continued" link that points to the same method and file, but increments the offset value 1024. Ta-da! Instant buffering. Alternately, you could easily indicate the size of the document next to the link and leave it for the client to determine whether they want to blow the bandwidth downloading it.
I'm guessing at this point that the best shot might be to write the list of hits to a file, and then return a handle to a dtml file which would pick up the list of hits from the file and do the right things with them, and include the user's name or id in the name of the hit file to keep users separate.
I'm a bit confused at this. Is this a logging solution? A caching solution? In terms of performance, it's tough to see how it could possibly improve on knowing a file name and a byte offset.
No caching. All I'm trying to do is get that filename and offset to another external method while avoiding all the catch-22s and sticky-wickets and what not.
My advice is to do as little in your external method as possible. Short of accessing something on the file system, there's not much here that *needs* to be done externally. Rather than fuss with having it maintain its own state, just make it fully parameterized.
The question at that point would be whether an external method could return the handle of a dtml method created within Zope
Sure. The easiest thing to do is return a string that corresponds with a dtml method (or anything) available in the current namespace. Ex:
<dtml-call "REQUEST.set('some_name', ext_method(arg1, arg2))"> <dtml-var "_[some_name]">
Sorry but I don't quite understand that. I need to have the external method return something which causes a dtml page to be acted upon and shown.
Hopefully Paul's explanation clarifies this.
I'm assuming also that the external method cannot return both a list of file and offset pairs and the information to execute a dtml page, which is why I assume I'd need to save the list to a file and have the dtml page pick it up.
It can only return one object, but that object *could* be a dictionary containing an arbitrarily complex collection of values, if necessary. Ex: ---- def my_method(args): do_stuff return {'path': '/path/to/file', 'offset': 10, 'dtml_method': 'some_name', 'sub_dict': {'value':'I think you get the point'}} --- which could then be obtained thus: --- info = my_external_method(args) my_path = info.get('path') my_offset = info.get('offset') --- Etc, etc. HTH, Dylan
On Friday 24 October 2003 12:35, Dylan Reinhardt wrote:
Sure. The easiest thing to do is return a string that corresponds with a dtml method (or anything) available in the current namespace. Ex:
<dtml-call "REQUEST.set('some_name', ext_method(arg1, arg2))"> <dtml-var "_[some_name]">
Sorry, I was looking at something the wrong way this afternoon; that actually does work and is probably all I need for this particular application. Again many thanks. Ted
participants (3)
-
Dylan Reinhardt -
Paul Winkler -
Ted holden