Using Cheetah with twisted.web
Hello all, I have just recently started working with twisted.web and think is great. I would like to use Cheetah templates with it - should I be doing something more complicated than the following? ################# # alf.rpy from twisted.web import resource from Cheetah.Template import Template f = "foo" b = ["bar", "baz"] class Resource(resource.Resource): def render(self, request): return Template(file="alf.tmpl", searchList = [{'f': f, 'b': b}]).__str__() resource = Resource() ################# Thanks, Matt
On Tue, 14 Feb 2006 10:41:24 -0600, Matt Helm <code.name.eric@gmail.com> wrote:
Hello all, I have just recently started working with twisted.web and think is great.
I would like to use Cheetah templates with it - should I be doing something more complicated than the following?
Probably. Rendering your template in this way will most certainly block the reactor, since Cheetah templates don't support Deferreds. On the other hand, if the template is rendering *very* quickly, then this code might not block for long enough to actually matter.
################# # alf.rpy from twisted.web import resource from Cheetah.Template import Template
f = "foo" b = ["bar", "baz"]
class Resource(resource.Resource): def render(self, request): return Template(file="alf.tmpl", searchList = [{'f': f, 'b': b}]).__str__()
resource = Resource()
#################
Thanks, Matt
I'd suggest you do some timing tests, varying the size of the data passed to the template, the complexity of the template, etc. If it turns out that rendering the template synchronously blocks the reactor for too long, you can look at breaking the rendering up into stages, using reactor.callLater, or a separate rendering thread. Hope this helps, L. Daniel Burr
On 2/14/06, L. Daniel Burr <ldanielburr@mac.com> wrote:
Probably. Rendering your template in this way will most certainly block the reactor, since Cheetah templates don't support Deferreds. On the other hand, if the template is rendering *very* quickly, then this code might not block for long enough to actually matter.
That is what I suspected. I will call the Cheetah template in deferToThread. Matt.
On 2/15/06, Matt Helm <code.name.eric@gmail.com> wrote:
On 2/14/06, L. Daniel Burr <ldanielburr@mac.com> wrote:
Probably. Rendering your template in this way will most certainly block the reactor, since Cheetah templates don't support Deferreds. On the other hand, if the template is rendering *very* quickly, then this code might not block for long enough to actually matter.
That is what I suspected. I will call the Cheetah template in deferToThread.
Matt.
_______________________________________________ Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
Why not just compile your template at the head of the file using, Template.compile(file="path"). I did some experimentation with this, and it is very fast. Only time I could see where deferred would be useful is when you are compiling it initially, if you precompile your templates and dont call any blocking functions within it, it will be more than fast enough. ToddB
On 2/18/06, Todd Thomas <caliban19@gmail.com> wrote:
On 2/15/06, Matt Helm <code.name.eric@gmail.com> wrote:
On 2/14/06, L. Daniel Burr <ldanielburr@mac.com> wrote:
Probably. Rendering your template in this way will most certainly block the reactor, since Cheetah templates don't support Deferreds. On the other hand, if the template is rendering *very* quickly, then this code might not block for long enough to actually matter.
That is what I suspected. I will call the Cheetah template in deferToThread.
Matt.
_______________________________________________ Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
Why not just compile your template at the head of the file using, Template.compile(file="path"). I did some experimentation with this, and it is very fast. Only time I could see where deferred would be useful is when you are compiling it initially, if you precompile your templates and dont call any blocking functions within it, it will be more than fast enough.
ToddB
One other thing, rpy will automatically cache the instance you create if its in your resource class. Which means you will only take the hit once when initially creating class. So it may block briefly depending on size of template, but afterwards, should be as fast as calling request.write on a class directly, which is basically what your are doing. ToddB
One other thing, rpy will automatically cache the instance you create if its in your resource class. Which means you will only take the hit once when initially creating class. So it may block briefly depending on size of template, but afterwards, should be as fast as calling request.write on a class directly, which is basically what your are doing.
ToddB
Putting it in a defertothread was no problem. The same resource class also has to pull some data by way of xmlrpc but everything works very clean and fast. Matt
Hello. I am just getting started with Twisted and I must say it is a very nice package! I am trying to write a SOAP application (server side). In the C/C++ I would use gSOAP to take a WSDL and generate the support libraries. What I like about Twisted is that introspection is available to make this, more or less, automatic. I searched around trying to find an example of using a WSDL file along with Twisted so that I would only need to write the supporting functions. I found nothing very useful. I am wondering if anyone can give me some pointers to using WSDL under Twisted (I know something of SOAPpy but I am not sure I can use it directly under Twisted). Peace, and thanks in advance, Chuck Wegrzyn
On Tue, 14 Feb 2006 10:59:49 -0600, C Wegrzyn <lists@garbagedump.com> wrote:
Hello. I am just getting started with Twisted and I must say it is a very nice package! I am trying to write a SOAP application (server side).
You have my sympathies. Seriously, unless you really have to write a SOAP application, please don't. SOAP is totally unnecessary for web services, despite what corporations and large technology firms claim. Ok, now that I've made my token attempt to save you from committing to crappy technology, on to your actual question.
In the C/C++ I would use gSOAP to take a WSDL and generate the support libraries. What I like about Twisted is that introspection is available to make this, more or less, automatic. I searched around trying to find an example of using a WSDL file along with Twisted so that I would only need to write the supporting functions. I found nothing very useful. I am wondering if anyone can give me some pointers to using WSDL under Twisted (I know something of SOAPpy but I am not sure I can use it directly under Twisted).
There is only one WSDL library that I am aware of, and it is available as part of the pywebsvcs project. The same place where you got SOAPpy, actually, so you most likely already have it. You will have to do a fair amount of work to integrate all of that auto-generated gobbledygook with twisted, up to and including replacing the network communications portion of said auto-generated code. Others here with more positive views on WSDL and friends may give you a more optimistic answer, and after all, the problem does just boil down to a Simple Matter of Programming. Then again, you want all this auto-generated code in order to avoid programming, right? Catch-22. Hope this helps, L. Daniel Burr
C Wegrzyn wrote:
Hello. I am just getting started with Twisted and I must say it is a very nice package! I am trying to write a SOAP application (server side).
In the C/C++ I would use gSOAP to take a WSDL and generate the support libraries. What I like about Twisted is that introspection is available to make this, more or less, automatic. I searched around trying to find an example of using a WSDL file along with Twisted so that I would only need to write the supporting functions. I found nothing very useful. I am wondering if anyone can give me some pointers to using WSDL under Twisted (I know something of SOAPpy but I am not sure I can use it directly under Twisted).
Chuck, Take a look at the 'ZSI' project. http://pywebsvcs.sourceforge.net/ If you check out the serialize-dom-scheme branch, you get a really nice WSDL code generator for Python (much, much better than SOAPpy or normal ZSI). Then, go get pyGridWare. It adds a Twisted service container that can house ZSI-based web services. If you want a working example, with documentation: http://dsd.lbl.gov/gtg/projects/PythonCLServiceTool/ Good luck, Dave
On 2/15/06, David E. Konerding <dekonerding@lbl.gov> wrote:
If you check out the serialize-dom-scheme branch, you get a really nice WSDL code generator for Python (much, much better than SOAPpy or normal ZSI). Then, go get pyGridWare. It adds a Twisted service container that can house ZSI-based web services.
WSDL code generation completely defies the purpose of having WSDL in the first place, refer: http://webservices.xml.com/pub/a/ws/2003/07/22/wsdlfirst.html <Rant> Its a shame that no python soap implementation supports WSDL first approach, while PHP being a weakly typed language does. More at http://nerdierthanthou.nfshost.com/2005/09/soaped-django.html </Rant> -- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay +91-9867-359-701
Amit, With out starting a lot of flaming and religious wars, I think the whole idea of using WSDL to dynamically build message handling is over-blown. Sure, the message interface might change but will my program be able to handle the changes without involving code changes? Maybe, for simple things but for those who cares. For complex changes it is a whole different story. I am happy to have something handle all the mundane things even if it statically built. Chuck Wegrzyn Amit Upadhyay wrote:
On 2/15/06, *David E. Konerding* <dekonerding@lbl.gov <mailto:dekonerding@lbl.gov>> wrote:
If you check out the serialize-dom-scheme branch, you get a really nice WSDL code generator for Python (much, much better than SOAPpy or normal ZSI). Then, go get pyGridWare. It adds a Twisted service container that can house ZSI-based web services.
WSDL code generation completely defies the purpose of having WSDL in the first place, refer: http://webservices.xml.com/pub/a/ws/2003/07/22/wsdlfirst.html <http://webservices.xml.com/pub/a/ws/2003/07/22/wsdlfirst.html>
<Rant> Its a shame that no python soap implementation supports WSDL first approach, while PHP being a weakly typed language does.
More at http://nerdierthanthou.nfshost.com/2005/09/soaped-django.html </Rant>
-- Amit Upadhyay Blog: http://www.rootshell.be/~upadhyay <http://www.rootshell.be/%7Eupadhyay> +91-9867-359-701 ------------------------------------------------------------------------
_______________________________________________ Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
Amit Upadhyay wrote:
On 2/15/06, *David E. Konerding* <dekonerding@lbl.gov <mailto:dekonerding@lbl.gov>> wrote:
If you check out the serialize-dom-scheme branch, you get a really nice WSDL code generator for Python (much, much better than SOAPpy or normal ZSI). Then, go get pyGridWare. It adds a Twisted service container that can house ZSI-based web services.
WSDL code generation completely defies the purpose of having WSDL in the first place, refer: http://webservices.xml.com/pub/a/ws/2003/07/22/wsdlfirst.html <http://webservices.xml.com/pub/a/ws/2003/07/22/wsdlfirst.html>
You misunderstood me. Perhaps if I call it a "python code generator from WSDL descriptions", you would have understood more clearly. Even though I fall into the camp of "write your wsdl, generate language specific bindings, implement service and client using specific langauges", I am not vehemently opposed to features like those in WSRF.NET. In that toolkit, users use C#-specific language features to mark up their C#-written classes. Those markups are used to guide the generation of WSDL. From what we can tell (as implementers of Python-based grid services that have been tested to interoperate with C# WSRF grid services) there are no problems with this approach. In fact, the process is so natural we have considered using decorators in Python to do the same thing. This sort of feature really only exists to provide developers who prefer to work in a native language rather than specifying the messages they want to exchange. I read the article you cited. It is only an opinion piece, and provides no coherent, logical argument for their viewpoint. Further, the article is obviously dated due to its focus on RPC encoding, which is not a viable approach for writing web services these days. Dave
participants (7)
-
Amit Upadhyay -
C Wegrzyn -
Chaz. -
David E. Konerding -
L. Daniel Burr -
Matt Helm -
Todd Thomas