Hi guys. Sorry I missed the IRC conversation today. I was just reading 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 <i...@colorstudy.com> writes: > * 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...
> "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 Dangoor <dang...@gmail.com> writes: > 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 wrote: > 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:
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:
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.
Kevin Dangoor wrote: >> 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
>> "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 Valverde wrote: > 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:
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.
