If in the torrent of messages you happened to notice ;-D, I'm implementing a class wrapper around an SQL result within a Zope product -- this now works thanks to the kind suggestion by Chris McDonough. Now that the wrapping part works, I've exposed another problem -- the main sort of method I want is one that renders the data into HTML for display purposes (i.e. the object draws itself). I was planning to use DTML for this, seeing as that's what's used elsewhere in the application. But when I try to render/run DTMLFile() methods in the wrapper I get complaints about acquisition failures (an error occurs in aq_parent()). Now I could probably go through some hoops to make acquisition happen (that is, give the object an acquisition parent) -- but actually, I don't need it -- all the variables I want rendered are attributes of the wrapper class. If I wanted to, I could give up on DTML and just use a Python format string. myform = """My stuff with %(data) inserted.""" % locals() instead of myform = DTMLFile("dtml/myform", globals(), **locals()) where dtml/myform is: """ My stuff with &dtml-data; inserted. """ However, that would break the "minimize the languages" rule -- I'd now have to use two different template systems in the same product. (I mainly mention it to prove the point that I don't need acquisition). Can I invoke DTML w/o invoking the acquisition mechanism (or at least tell the acquisition mechanism not to try to find a parent for my class)? I don't see how one could do this with DTMLFile, is there a way by actually invoking the DTMLMethod() constructor? Thanks for any suggestions! Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com "Some things are too important to be taken seriously"
Try this: def show_stuff(self): """obligatory doc string""" return DTMLFile(file_name, globals()).__of__(self)() Or, if you prefer, the ZPT version: from Products.PageTemplates.PageTemplateFile import PageTemplateFile def show_stuff(self): """obligatory doc string""" return PageTemplateFile(file_name, globals()).__of__(self)() Trust me, you don't want to go about implementing your own templating system. It sucks. HTH, Dylan At 04:48 PM 12/9/2002, you wrote:
If in the torrent of messages you happened to notice ;-D, I'm implementing a class wrapper around an SQL result within a Zope product -- this now works thanks to the kind suggestion by Chris McDonough. Now that the wrapping part works, I've exposed another problem -- the main sort of method I want is one that renders the data into HTML for display purposes (i.e. the object draws itself).
I was planning to use DTML for this, seeing as that's what's used elsewhere in the application. But when I try to render/run DTMLFile() methods in the wrapper I get complaints about acquisition failures (an error occurs in aq_parent()). Now I could probably go through some hoops to make acquisition happen (that is, give the object an acquisition parent) -- but actually, I don't need it -- all the variables I want rendered are attributes of the wrapper class. If I wanted to, I could give up on DTML and just use a Python format string.
myform = """My stuff with %(data) inserted.""" % locals()
instead of
myform = DTMLFile("dtml/myform", globals(), **locals())
where dtml/myform is: """ My stuff with &dtml-data; inserted. """
However, that would break the "minimize the languages" rule -- I'd now have to use two different template systems in the same product. (I mainly mention it to prove the point that I don't need acquisition).
Can I invoke DTML w/o invoking the acquisition mechanism (or at least tell the acquisition mechanism not to try to find a parent for my class)?
I don't see how one could do this with DTMLFile, is there a way by actually invoking the DTMLMethod() constructor?
Thanks for any suggestions! Terry
-- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
"Some things are too important to be taken seriously"
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
A DTMLFile is an object that explicitly requires an acquisition context (for security). There is another class that you can import named HTMLFile (from the same place as DTMLFile) that I believe will do what you want to do. It doesn't appear to require an acquisition context and it has roughly the same signature. If this fails, you can use the DocumentTemplate.HTML class directly and just pass in "raw" DTML to its constructor. - C On Mon, 2002-12-09 at 19:48, Terry Hancock wrote:
If in the torrent of messages you happened to notice ;-D, I'm implementing a class wrapper around an SQL result within a Zope product -- this now works thanks to the kind suggestion by Chris McDonough. Now that the wrapping part works, I've exposed another problem -- the main sort of method I want is one that renders the data into HTML for display purposes (i.e. the object draws itself).
I was planning to use DTML for this, seeing as that's what's used elsewhere in the application. But when I try to render/run DTMLFile() methods in the wrapper I get complaints about acquisition failures (an error occurs in aq_parent()). Now I could probably go through some hoops to make acquisition happen (that is, give the object an acquisition parent) -- but actually, I don't need it -- all the variables I want rendered are attributes of the wrapper class. If I wanted to, I could give up on DTML and just use a Python format string.
myform = """My stuff with %(data) inserted.""" % locals()
instead of
myform = DTMLFile("dtml/myform", globals(), **locals())
where dtml/myform is: """ My stuff with &dtml-data; inserted. """
However, that would break the "minimize the languages" rule -- I'd now have to use two different template systems in the same product. (I mainly mention it to prove the point that I don't need acquisition).
Can I invoke DTML w/o invoking the acquisition mechanism (or at least tell the acquisition mechanism not to try to find a parent for my class)?
I don't see how one could do this with DTMLFile, is there a way by actually invoking the DTMLMethod() constructor?
Thanks for any suggestions! Terry
-- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
"Some things are too important to be taken seriously"
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Thanks again Chris! On Monday 09 December 2002 05:12 pm, Chris McDonough wrote:
A DTMLFile is an object that explicitly requires an acquisition context (for security).
There is another class that you can import named HTMLFile (from the same place as DTMLFile) that I believe will do what you want to do. It doesn't appear to require an acquisition context and it has roughly the same signature.
Yes, that works! I guess I figured that HTMLFile() would differ by not allowing DTML tags. The only difference in the signature is that the filename doesn't automatically use the package_home(), so you have to do it explicitly. I am now a happy hacker. :-D
If this fails, you can use the DocumentTemplate.HTML class directly and just pass in "raw" DTML to its constructor.
Interesting to poke around in those modules. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com "Some things are too important to be taken seriously"
participants (3)
-
Chris McDonough -
Dylan Reinhardt -
Terry Hancock