Paste etc.
Ian Bicking
the logs, and a few thoughts:
"workingenv.py -r http://some/place.txt" is a way you can build
something like a distribution, that's separate from any of the pieces
that make it up. That way you can build a full stack with all the
components, without putting in any requirements in the individual pieces.
To realistically put multiple end-user-visible applications in one
process you need some styling system (for services/APIs it's not really
important). There's two layers where this can happen:
* You can use a filter that applies styling to unstyled content.
Deliverance, which I'm working on, does this
(http://openplans.org/projects/deliverance). We're going to add a few
features here and there, but the project is pretty far along. It works
as WSGI middleware, and we've built an HTTP proxy from that which is
what we're actually using in deployment.
* You can use a single templating system across all your applications
(or at least a small number of systems), and use a search path and
filename conventions to have them share style. This is probably more
comfortable to people, but of course requires a single templating
system. This also requires some improvements in the Buffet API (which
are long overdue anyway).
--
Ian Bicking | ia...@colorstudy.com | http://blog.ianbicking.org
Jorge Godoy
> * You can use a single templating system across all your applications (or at
> least a small number of systems), and use a search path and filename
> conventions to have them share style. This is probably more comfortable to
> people, but of course requires a single templating system. This also requires
> some improvements in the Buffet API (which are long overdue anyway).
This is not all that bad... But the other proposal seems much better when
glueing different projects. On the other hand, for writing one's own apps
(be it a company or an individual) sticking to one templating system looks
more interesting due to higher reusability...
Anyway, I'm curious about Deliverance. ;-)
--
Jorge Godoy <jgo...@gmail.com>
Kevin Dangoor
> "workingenv.py -r http://some/place.txt" is a way you can build
> something like a distribution, that's separate from any of the
> pieces that make it up. That way you can build a full stack with
> all the components, without putting in any requirements in the
> individual pieces.
oh yeah, that's handy.
> To realistically put multiple end-user-visible applications in one
> process you need some styling system (for services/APIs it's not
> really important). There's two layers where this can happen:
>
> * You can use a filter that applies styling to unstyled content.
> Deliverance, which I'm working on, does this (http://openplans.org/
> projects/deliverance). We're going to add a few features here and
> there, but the project is pretty far along. It works as WSGI
> middleware, and we've built an HTTP proxy from that which is what
> we're actually using in deployment.
There is another solution here. Genshi's match templates can be used
just like XSLT to add styling around the output that's coming from
the inside.
Kevin
Jorge Godoy
> There is another solution here. Genshi's match templates can be used just
> like XSLT to add styling around the output that's coming from the inside.
And using XInclude you also have a very powerful tool for that.
--
Jorge Godoy <jgo...@gmail.com>
Ian Bicking
> Anyway, I'm curious about Deliverance. ;-)
Basically Deliverance works with a "theme" (which is just a file or URL)
and some rules. The rules define how the content (what your app
produces) is injected into the theme. A simple rule set would be:
<rules xmlns:xi="http://www.w3.org/2001/XInclude"
xmlns="http://www.plone.org/deliverance" >
<xi:include href="standardrules.xml" />
<copy theme="//div[@id='container']"
content="//*[@id='portal-columns']" />
</rules>
The stuff in standardrules.xml just merges the <head>'s properly, and we
might get rid of that (as this is really HTML-oriented, so building in
HTML preconceptions is okay with me).
The <copy> rule says to take the div with id 'container' and put the
content in the element with id 'portal-columns' there. You can also do
things like:
<append theme="//div[@id='sidenav']"
href="/myapp/sidenav.html" />
Which would take the content in sidenav.html and add it to the element.
Or you can take navigation out of the content page itself, for another
style of customization. All the work happens after the content is
rendered, so it's completely neutral of any templating technique. At
it's simplest you can also tell people to install an application, point
Deliverance (or some configuration key, like theme_url) to a page they
want to copy, and that's it. With that minimal technique you lose a
little something, but you also get something workable very fast that way.
Ian Bicking
>> To realistically put multiple end-user-visible applications in one
>> process you need some styling system (for services/APIs it's not
>> really important). There's two layers where this can happen:
>>
>> * You can use a filter that applies styling to unstyled content.
>> Deliverance, which I'm working on, does this (http://openplans.org/
>> projects/deliverance). We're going to add a few features here and
>> there, but the project is pretty far along. It works as WSGI
>> middleware, and we've built an HTTP proxy from that which is what
>> we're actually using in deployment.
>
> There is another solution here. Genshi's match templates can be used
> just like XSLT to add styling around the output that's coming from the
> inside.
True; anything XSLT-like fits the bill. A lot of what we're doing with
Deliverance is aimed at making themable sites for untrusted users
(MySpace-like); it's not terribly constraining to do so, but some of the
choices we make are based on that. That will probably end up being a
distinction between something written in Genshi and Deliverance.
The actual filtering logic for Deliverance has mostly been extracted
into WSGIFilter, though I think I've probably broken that at the moment
because I've done a major refactoring of WSGIRemote (which is in the
process of a rename).
Proxying from Python to another service is also a useful way to apply
this kind of styling to non-Python content; this is actually going to be
our first deployment strategy with Deliverance. This just uses
paste.proxy, and some glue code in WSGIFilter.proxyapp
Alberto Valverde
On Jan 4, 2007, at 2:47 AM, Kevin Dangoor wrote:
>
> On Jan 3, 2007, at 7:43 PM, Ian Bicking wrote:
>
>> "workingenv.py -r http://some/place.txt" is a way you can build
>> something like a distribution, that's separate from any of the
>> pieces that make it up. That way you can build a full stack with
>> all the components, without putting in any requirements in the
>> individual pieces.
>
> oh yeah, that's handy.
(I told you... ;)
>
>> To realistically put multiple end-user-visible applications in
>> one process you need some styling system (for services/APIs it's
>> not really important). There's two layers where this can happen:
>>
>> * You can use a filter that applies styling to unstyled content.
>> Deliverance, which I'm working on, does this (http://
>> openplans.org/ projects/deliverance). We're going to add a few
>> features here and there, but the project is pretty far along. It
>> works as WSGI middleware, and we've built an HTTP proxy from that
>> which is what we're actually using in deployment.
>
> There is another solution here. Genshi's match templates can be
> used just like XSLT to add styling around the output that's coming
> from the inside.
I like this solution better because Genshi is going to be TG's
default templating language so forcing users to learn another way of
doing html transformation doesn't seem right.
A place in environ where controllers could dump their genshi
unserialized stream so upper layers have a chance to filter it and
finally serialize it sounds like a possible way to implement it...
I *believe* Elvelind is interested is interested in this part of
TG... (am I right?)
Alberto
Ian Bicking
> A place in environ where controllers could dump their genshi
> unserialized stream so upper layers have a chance to filter it and
> finally serialize it sounds like a possible way to implement it...
>
> I *believe* Elvelind is interested is interested in this part of TG...
> (am I right?)
The way I'm doing this in HTTPEncode is that the app_iter that is
returned has an attribute, that would probably be something like
app_iter.decoded = ('genshi.Markup', stream)
Then middleware can see that and get the unserialized data. The
app_iter itself serializes lazily. The lazy serialization should
actually only be done when it knows someone higher up might be looking
for unserialized data, which it would tell by a marker in the environ --
the flaw with lazy serialization being that you can't set a Content-Length.
Anyway, this degrades well for middleware that actually wants to look at
the text response. If you use the environ for the response, there's a
good chance that information could get lost, like in a stack like:
GenshiMarkupTransform
ProfileInfoAdder
Application
If the Application produces environ['genshi.output_markup'], and
ProfileInfoAdder (something like egg:Paste#profile) just works on text,
adding profiling information, GenshiMarkupTransform will end up throwing
away ProfileInfoAdder's information if it ignores the app_iter and reads
the output from the environ. By attaching the data to the app_iter
directly this case is avoided.