http://microapps.sourceforge.net/tasty/
I strongly recommend following the installation instructions:
http://microapps.sourceforge.net/tasty/installation.html
Upgrading from a previous version should mostly involve pulling in the
new requirements, making sure your configs haven't changed, and using
the start-tasty.py script instead of the old tasty_start.py.
--
anders pearson : http://www.columbia.edu/~anders/
C C N M T L : http://www.ccnmtl.columbia.edu/
weblog : http://thraxil.org/
After spending some time looking at the idea for microapps I thought it
might be useful to wrap access to a microapp from within TurboGears
into local and "proxied" controller methods. This allows you to run a
local copy of a microapp in your controller and gather data through
direct method calls or access the data remotely ... again through
direct method calls, this time on the proxy class.
Anyways, I wrote up the basic idea here:
http://docs.turbogears.org/1.0/TurboGearsAndMicroApps
Tasty looks pretty cool, glad to see it get updated for 1.0
-Adam
>
> --
> anders pearson : http://www.columbia.edu/~anders/
> C C N M T L : http://www.ccnmtl.columbia.edu/
> weblog : http://thraxil.org/
>
> --kORqDWCi7qDJ0mEj
> Content-Type: application/pgp-signature
> X-Google-AttachSize: 190
This is a really cool idea. Thanks for writing it up. The microapps
concept is still sort of coagulating and ideas for this kind of glue
are a big help.
On the implementation side of things, one idea that I had that I
haven't had time to code up a test of is to use wsgi_intercept[1] to
automatically bypass HTTP and make the calls to a microapp in-process
for situations where they microapp is running on the same server as
the main app and happens to also be written in python with a WSGI
capable framework.
That way, you could use your proxy idea and have a registry somewhere
else (per-app configured, or global to a machine, or whatever) where
you specify that certain URLs map to WSGI applications. Done right,
that lets you have your cake of nicely seperated microapps while
letting you eat it too by skipping the latency of HTTP calls. Then, if
you need to scale out by moving the microapp to another server, you
just remove the entry in the registry and it goes back to HTTP
requests.
My intention with the microapps stuff is to have it be a
cross-language idea, but IMO, WSGI gives Python a huge advantage as
the implementation language of choice.
1: http://darcs.idyll.org/~t/projects/wsgi_intercept/README.html
Nice writeup! After reading this, I realized that I did a similar thing to
integrate gravatars in my blog application, i.e. I wrote a special controller,
that encapsulates access to the gravatar.com URL interface.
So you see, this is not limited to Microapps using a REST interface, as long as
the remote service exposes an URL interface and delivers results over HTTP, the
basic mechanism is the same.
I didn't separate the controller into a local and a proxy service, rather I let
the local service act as a forwarder if the requested result is not in the
local storage/cache. You can check it out in the cblog/widgets/gravatar module
of my CBlog app:
http://chrisarndt.de/projects/cblog/download/CBlog-20061130.tar.bz2
As another step to ease the usage of remote services in TurboGears websites,
this module encapsulate the display of the result in a fitting widget, i.e. an
image tag for a gravatar or, for your quote example, a nicely styled
<blockquote> element. To use the remote service in you template, you then just
have to insert a simple function call, e.g.
${gravatar.display('f...@bar.com', size=40)}
I also plan to write something similar for different website thumbnail
services, like Alexa, websnapr.com, artviper.net, etc.
Chris