Having multiple levels of shared look and feel is something that Aquarium does very well in Cheetah using multiple techniques. I do make use of heavy OO, etc. to make this happen. It's a requirement for my company where we need multiple applications to look pretty much the same, but not exactly. :-/
Best Regards, -jj On 9/21/05, Ian Bicking <[EMAIL PROTECTED]> wrote: > Ben Bangert wrote: > > On Sep 10, 2005, at 11:39 AM, Ian Bicking wrote: > > > >>> Thanks for the detailed example, I finally understand now what Paste > >>> does :). One question though, should I use environ for exchanging data > >>> between applications (e. g. some template object, that partly rendered > >>> by one application, and should be "finished" by News), or does Paste > >>> have some facility for that? > >>> > >> > >> You mean like a site template? I don't really have a very good idea of > >> how best to handle that :( > >> > >> One possibility is creating a rendering filter. So at the top of the > >> hierarchy, you have some code that filters the output. Outside of > >> Paste/WSGI I'm planning on doing this with Apache OutputFilters. In > >> WSGI I'm not sure how best to do it -- I think it's too inefficient for > >> an application to generate template source, and have it rendered later. > >> Something like server-side includes, edge-side includes, or XSLT seems > >> more efficient and reasonable. > > > > > > I was thinking the exact same thing earlier this morning. It wouldn't > > be hard to do, but in the process you'd want the app's deployed to be > > customized so a lot of the extra information is not returned. Then have > > them run through a webapp acting as a content filter. > > > > My main problem with doing this is speed, as there's now essentially > > two full web applications (to an extent) rendering a single page. > > > >> Also, you can do subrequests to render several portions of a page. A > >> good high-level templating language (like SSI) should make this easy > >> (should such a thing be written!). In Paste there is a > >> filter/middleware in paste.recursive to make subrequests easier. > > > > > > I'm voting to keep middleware at this point. Filter implies removing > > something from what is being 'filtered'. While middleware does that on > > occasion, a lot of the middleware I've seen adds to things, not removes > > (transaction, sessions, etc) which would make the term confusing. If > > there was some pretty graphic with colored boxes and such showing the > > WSGI flow and where middleware fits in, less people would have a > > problem with it (as I'm not really sure what else you'd call it). > > I don't think "middleware" actually means *anything*, though, except > that it's between two things. Everything is between two things. > > I'm comfortable with filters implying a filtered view of the request > (i.e., environ modifying filter), or filtered view of the response > (rewriter), and if it doesn't completely fit for things like > error-catching, that's okay. At least it isn't scary. > > >> Then lastly, what you might be thinking of, is a way of passing a > >> template object to subapplications. I'd imagine this template should be > >> fairly simple, at least if it is going to be able to handle applications > >> that use different templating languages. I'd imagine it being called > >> like: > >> > >> tmpl(var1=foo, var2=bar, ...) > >> > >> Where at least "body" and "title" are expected. But even then the > >> applications have to be modified, since most applications have their own > >> templating system. It won't be trivial in any case, but at least it > >> would be nice to be able (for each application) to have a generic > >> template. This is why I think a filter-based system will work better. > >> One example of a filter is here: > >> http://www.decafbad.com/blog/2005/07/18/ > >> discovering_wsgi_and_xslt_as_middleware > >> > >> Using XSLT it requires valid XHTML, I'd imagine. But a text-based > >> parser is easy enough to imagine. > > > > > > I think its ok to just try and skin each app deployed in a similar > > fashion. There's just too many things a sub-section of the page might > > rely on elsewhere to reliably skin it at a higher level. What if this > > particular page requires a different stylesheet? A different Javascript > > on body load? etc. > > > > There's so many things a page could require in the header, footer, etc. > > just to operate properly I can't see it being realistic to have a > > template filter act very reliably on different deployed apps. While it > > does take some extra work to make it all look right from the web users > > perspective, I think its worth it since you're at least sure the > > deployed apps will run properly. > > Well, right now at work we're looking at a three-level template: each > page has a template, that inherits from the application template, and > that inherits from the site template. And then the app can be installed > in different sites by switching the site template. > > Right now that's possible if you allow several template directories that > shadow each other. And you can switch any of the templates, e.g., > customizing a single page. A filter can't replace that functionality. > But to the degree that you can change the overall look of the site, you > have to do it for each application, and that makes me sad -- if I have > to use different templating languages for overriding individual pages of > an application, I don't see that as a problem. But I'd like to be able > to apply a site template ("skin" I guess it's usually called) without > quite so much effort. I think that's a useful goal. > > Right now at work we *are* going to do this, by using a filtered > templating language (SSIs, using an Apache OutputFilter). An in turn, > we'll create a Single Template for each application that translates that > application's look into SSIs. From that perspective, you don't actually > have to standardize on anything -- at least if you are deploying a small > number of applications widely it isn't so much of a problem, because the > time invested in converting each application is regained because you can > reuse that conversion for all sites. > > _______________________________________________ > Web-SIG mailing list > Web-SIG@python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: http://mail.python.org/mailman/options/web-sig/jjinux%40gmail.com > -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com