From tsoehnli at gmu.edu Sat Sep 10 00:40:45 2005 From: tsoehnli at gmu.edu (tsoehnli@gmu.edu) Date: Fri, 09 Sep 2005 17:40:45 -0500 Subject: [Web-SIG] Global Variables Message-ID: Hello all, I am working on an ongoing project, and recently merged all the different segments of the request into a single variable. To propogate that variable,across function calls, and imported modules, I had to pass it as a variable to each function. As is visible, this is a very redundant, and unnecessary action. I recently discovered that I could imbed the variable into __builtins__, and the variable is accessible throughout the entire request process. This seems to work so far when the request is in CGI mode and when the request is being handled by mod_python. I was wondering if anyone out there has dealt with this before, and knows whether or not there is an issue in using __builtins__ as a way of handling global variables, especially in respect to the way mod_python handles the use of variables. I have no desire for the variable to be overwritten, or redefined in the middle of a request. Sincerely, Timothy Soehnlin -- I would rather be known as a Christian and despised, than to be overlooked, and thought of as one of the world. From fumanchu at amor.org Sat Sep 10 01:37:45 2005 From: fumanchu at amor.org (Robert Brewer) Date: Fri, 9 Sep 2005 16:37:45 -0700 Subject: [Web-SIG] Global Variables Message-ID: <3A81C87DC164034AA4E2DDFE11D258E377296E@exchange.hqamor.amorhq.net> Timothy Soehnlin wrote: > I am working on an ongoing project, and recently > merged all the different segments of the request into a > single variable. To propogate that variable,across function > calls, and imported modules, I had to pass it as a variable > to each function. As is visible, this is a very redundant, > and unnecessary action. I recently discovered that I could > imbed the variable into __builtins__, and the variable is > accessible throughout the entire request process. This seems > to work so far when the request is in CGI mode and when the > request is being handled by mod_python. I was wondering if > anyone out there has dealt with this before, and knows > whether or not there is an issue in using __builtins__ as a > way of handling global variables, especially in respect to > the way mod_python handles the use of variables. I have no > desire for the variable to be overwritten, or redefined in > the middle of a request. If you ever make your application multithreaded, that approach is going to cause problems, as competing threads overwrite your request object's attributes. You can do what CherryPy did, and use global threadlocal objects instead. Or you could save yourself the headache and just use CherryPy to develop your app. ;) Robert Brewer System Architect Amor Ministries fumanchu at amor.org From jjinux at gmail.com Sat Sep 10 18:36:10 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Sat, 10 Sep 2005 09:36:10 -0700 Subject: [Web-SIG] Global Variables In-Reply-To: <3A81C87DC164034AA4E2DDFE11D258E377296E@exchange.hqamor.amorhq.net> References: <3A81C87DC164034AA4E2DDFE11D258E377296E@exchange.hqamor.amorhq.net> Message-ID: I second the statement about multi-threading headaches if you use globals in this way. In Aquarium, since I have to support different threading API's (no threads, Python threads, coroutines), I put everything in a Context object, and then pass that Context object to everything's constructor. This isn't as bad as it sounds. It happens automatically when I call aquariumFactory(moduleName, *args, **kargs) which does a dynamic import, instantiates the class passing the Context object and the additional args, and then returns the instance. Best Regards, -jj On 9/9/05, Robert Brewer wrote: > Timothy Soehnlin wrote: > > I am working on an ongoing project, and recently > > merged all the different segments of the request into a > > single variable. To propogate that variable,across function > > calls, and imported modules, I had to pass it as a variable > > to each function. As is visible, this is a very redundant, > > and unnecessary action. I recently discovered that I could > > imbed the variable into __builtins__, and the variable is > > accessible throughout the entire request process. This seems > > to work so far when the request is in CGI mode and when the > > request is being handled by mod_python. I was wondering if > > anyone out there has dealt with this before, and knows > > whether or not there is an issue in using __builtins__ as a > > way of handling global variables, especially in respect to > > the way mod_python handles the use of variables. I have no > > desire for the variable to be overwritten, or redefined in > > the middle of a request. > > If you ever make your application multithreaded, that approach is going > to cause problems, as competing threads overwrite your request object's > attributes. You can do what CherryPy did, and use global threadlocal > objects instead. Or you could save yourself the headache and just use > CherryPy to develop your app. ;) > > > Robert Brewer > System Architect > Amor Ministries > fumanchu at amor.org > _______________________________________________ > Web-SIG mailing list > Web-SIG at 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. From titus at caltech.edu Sat Sep 10 18:45:34 2005 From: titus at caltech.edu (Titus Brown) Date: Sat, 10 Sep 2005 09:45:34 -0700 Subject: [Web-SIG] Global Variables In-Reply-To: References: <3A81C87DC164034AA4E2DDFE11D258E377296E@exchange.hqamor.amorhq.net> Message-ID: <20050910164534.GA23129@caltech.edu> -> I second the statement about multi-threading headaches if you use -> globals in this way. -> -> In Aquarium, since I have to support different threading API's (no -> threads, Python threads, coroutines), I put everything in a Context -> object, and then pass that Context object to everything's constructor. -> This isn't as bad as it sounds. It happens automatically when I call -> aquariumFactory(moduleName, *args, **kargs) which does a dynamic -> import, instantiates the class passing the Context object and the -> additional args, and then returns the instance. You can also write a function to get the variable, _global_var = None def init_global_var(): global _global_var _global_var = GlobalSomethingOrOther() def get_global_var(): return _global_var Then in the case of multithreaded apps, you can change these functions to use a dictionary of "global variables" indexed by thread-id. --titus From ksenia.marasanova at gmail.com Sat Sep 10 19:24:22 2005 From: ksenia.marasanova at gmail.com (Ksenia Marasanova) Date: Sat, 10 Sep 2005 20:24:22 +0300 Subject: [Web-SIG] using WSGI for standard pluggable applications Message-ID: <130df1930509101024549c62ab@mail.gmail.com> Hi, Sorry if this is a trivial question, but does it sounds reasonable to use WSGI for "pluggable" standard applications, instead of usual Python imports? For example, standard news module, like: app = NewsApp(path='/site/news/') The content of news app would be inserted into site template, generated by main publisher. If there are any examples of such WSGI use, I'll be glad to hear that... Thanks -- Ksenia From ianb at colorstudy.com Sat Sep 10 19:54:07 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 10 Sep 2005 12:54:07 -0500 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: <130df1930509101024549c62ab@mail.gmail.com> References: <130df1930509101024549c62ab@mail.gmail.com> Message-ID: <43231DBF.9020207@colorstudy.com> Ksenia Marasanova wrote: > Sorry if this is a trivial question, but does it sounds reasonable to > use WSGI for "pluggable" standard applications, instead of usual > Python imports? For example, standard news module, like: > > app = NewsApp(path='/site/news/') > > The content of news app would be inserted into site template, > generated by main publisher. If there are any examples of such WSGI > use, I'll be glad to hear that... I think you are describing something along the lines of what Paste Deploy is doing (http://pythonpaste.org/deploy/paste-deploy.html). It uses Eggs with entry points (though plain imports are also allowed). So if you have a news application, you'd add this to its setup.py: setup( name="NewsApp", ... entry_points={ 'paste.app_factory': 'main=news.wsgiapp:make_app'}) news.wsgiapp looks like: def make_app(global_conf, database): # database is a required configuration variable specific to news # you return a plain WSGI application here Then to deploy it, you create a configuration file (lets say site.ini): [composit:main] use = egg:Paste#urlmap /site/news = news /site/wiki = wiki / = static [app:news] use = egg:NewsApp database = sqlite:/path/to/db [app:wiki] use = egg:MoinMoin [app:static] use = egg:Paste#static document_root = /var/www Then to use the configuration file you do: from paste.deploy import loadapp app = loadapp('config:/path/to/site.ini') # app is now a WSGI application that dispatches # based on URL to the three configured applications Or you can do: paster serve site.ini At least this will work if you define a server in the config file, like: [server:main] use = egg:PasteScript#wsgiutils port = 8000 From ksenia.marasanova at gmail.com Sat Sep 10 20:20:17 2005 From: ksenia.marasanova at gmail.com (Ksenia Marasanova) Date: Sat, 10 Sep 2005 21:20:17 +0300 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: <43231DBF.9020207@colorstudy.com> References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> Message-ID: <130df1930509101120322e734e@mail.gmail.com> 2005/9/10, Ian Bicking : > Ksenia Marasanova wrote: > > Sorry if this is a trivial question, but does it sounds reasonable to > > use WSGI for "pluggable" standard applications, instead of usual > > Python imports? For example, standard news module, like: > > > > app = NewsApp(path='/site/news/') > > > > The content of news app would be inserted into site template, > > generated by main publisher. If there are any examples of such WSGI > > use, I'll be glad to hear that... > > I think you are describing something along the lines of what Paste > Deploy is doing (http://pythonpaste.org/deploy/paste-deploy.html). [snip] 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? -- Ksenia From ianb at colorstudy.com Sat Sep 10 20:39:48 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 10 Sep 2005 13:39:48 -0500 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: <130df1930509101120322e734e@mail.gmail.com> References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> <130df1930509101120322e734e@mail.gmail.com> Message-ID: <43232874.2040102@colorstudy.com> Ksenia Marasanova wrote: > 2005/9/10, Ian Bicking : > >>Ksenia Marasanova wrote: >> >>>Sorry if this is a trivial question, but does it sounds reasonable to >>>use WSGI for "pluggable" standard applications, instead of usual >>>Python imports? For example, standard news module, like: >>> >>>app = NewsApp(path='/site/news/') >>> >>>The content of news app would be inserted into site template, >>>generated by main publisher. If there are any examples of such WSGI >>>use, I'll be glad to hear that... >> >>I think you are describing something along the lines of what Paste >>Deploy is doing (http://pythonpaste.org/deploy/paste-deploy.html). > > [snip] > > 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. 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. 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. Ian From stephan.diehl at gmx.net Wed Sep 21 18:56:53 2005 From: stephan.diehl at gmx.net (Stephan Diehl) Date: Wed, 21 Sep 2005 18:56:53 +0200 Subject: [Web-SIG] Webapplication and Javascript Message-ID: <200509211856.53214.stephan.diehl@gmx.net> Hi, I'm in the process of developing a kind of web widget library. I guess that it will be similar to lifepage (nevow) :) The ultimate goal is to have a development platform that allows to write Webapplications exactly in the same way than other GUI applications. Obviously, I'm still far away from that goal... Anyway, the Javascript part will be (is) based on Mochikit. The backend part is basicly a JsonRpc Server (at the moment based on Webware). The (html) widgets render either as html, if they are served by the webserver end or in a json compatible format, if served by the JsonRpc end. Has anybody done anything like this before? Or thought about it? If there is real interest, I'd be putting together a release of what I have already. ---- Stephan From ben at groovie.org Wed Sep 21 20:16:51 2005 From: ben at groovie.org (Ben Bangert) Date: Wed, 21 Sep 2005 11:16:51 -0700 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: <43232874.2040102@colorstudy.com> References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> <130df1930509101120322e734e@mail.gmail.com> <43232874.2040102@colorstudy.com> Message-ID: <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> 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). > 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. - Ben From jjinux at gmail.com Wed Sep 21 20:18:05 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Wed, 21 Sep 2005 11:18:05 -0700 Subject: [Web-SIG] Webapplication and Javascript In-Reply-To: <200509211856.53214.stephan.diehl@gmx.net> References: <200509211856.53214.stephan.diehl@gmx.net> Message-ID: I've seen two things similar to this lately: http://www.innoscript.org/content/view/30/42/ http://www.turbogears.org/ Perhaps that aren't 100% matches with your project, but they're close. It'd be great if you guys could work together! Best Regards, -jj On 9/21/05, Stephan Diehl wrote: > Hi, > > I'm in the process of developing a kind of web widget library. > I guess that it will be similar to lifepage (nevow) :) > The ultimate goal is to have a development platform that allows to write > Webapplications exactly in the same way than other GUI applications. > Obviously, I'm still far away from that goal... > Anyway, the Javascript part will be (is) based on Mochikit. The backend part > is basicly a JsonRpc Server (at the moment based on Webware). > The (html) widgets render either as html, if they are served by the webserver > end or in a json compatible format, if served by the JsonRpc end. > > Has anybody done anything like this before? Or thought about it? > > If there is real interest, I'd be putting together a release of what I have > already. > ---- > Stephan > _______________________________________________ > Web-SIG mailing list > Web-SIG at 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. From renesd at gmail.com Thu Sep 22 02:56:08 2005 From: renesd at gmail.com (Rene Dudfield) Date: Thu, 22 Sep 2005 10:56:08 +1000 Subject: [Web-SIG] Webapplication and Javascript In-Reply-To: <200509211856.53214.stephan.diehl@gmx.net> References: <200509211856.53214.stephan.diehl@gmx.net> Message-ID: <64ddb72c0509211756174f02b5@mail.gmail.com> Hey, I have done something similar, but with xmlrpc ( using the jsolait library ) instead of jsonrpc. It is a Melbourne arts, music, and creative comunity site http://www.pretendpaper.com/ The current site is an old version of the code, and I have since done a lot to improve it. Refactoring, and cleaning up has been a big part of it, as the current live site was more a proof of concept to try different approaches. I like the approach because it makes it easy to write scripts that interact with the website remotely. However there are a lot of browser performance, and browser compatibility issues with generating pages based on dynamic requests. It was very time consuming, because a lot of it was working with new things, and working around bugs. But very interesting none the less :) I might think of swapping xmlrpc with jsonrpc later on. However when I started jsonrpc was not really working very well across implementations/languages. Cheers, Rene Dudfield. Melbourne websites, creative and technical services http://www.madecollective.com/ On 9/22/05, Stephan Diehl wrote: > Hi, > > I'm in the process of developing a kind of web widget library. > I guess that it will be similar to lifepage (nevow) :) > The ultimate goal is to have a development platform that allows to write > Webapplications exactly in the same way than other GUI applications. > Obviously, I'm still far away from that goal... > Anyway, the Javascript part will be (is) based on Mochikit. The backend part > is basicly a JsonRpc Server (at the moment based on Webware). > The (html) widgets render either as html, if they are served by the webserver > end or in a json compatible format, if served by the JsonRpc end. > > Has anybody done anything like this before? Or thought about it? > > If there is real interest, I'd be putting together a release of what I have > already. > ---- > Stephan From ianb at colorstudy.com Thu Sep 22 03:26:49 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Wed, 21 Sep 2005 20:26:49 -0500 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> <130df1930509101120322e734e@mail.gmail.com> <43232874.2040102@colorstudy.com> <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> Message-ID: <43320859.7000405@colorstudy.com> 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. From jjinux at gmail.com Thu Sep 22 06:41:33 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Wed, 21 Sep 2005 21:41:33 -0700 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: <43320859.7000405@colorstudy.com> References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> <130df1930509101120322e734e@mail.gmail.com> <43232874.2040102@colorstudy.com> <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> <43320859.7000405@colorstudy.com> Message-ID: 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 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 at 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. From jjinux at gmail.com Thu Sep 22 06:49:08 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Wed, 21 Sep 2005 21:49:08 -0700 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> <130df1930509101120322e734e@mail.gmail.com> <43232874.2040102@colorstudy.com> <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> <43320859.7000405@colorstudy.com> Message-ID: Sorry, I didn't mean to sound like I was bragging. I should note that imho this is a bit easier to do with Cheetah than with ZPT and Metal. In Cheetah, if I have a deep inheritance hierarchy: SharedLayout AppLayout SectionLayout Screen Then, within Screen I can override, extend, or define methods that are defined at any level of the hierarchy. Since everything is defined as a method somewhere, Screen can change any part of the look and feel it wants. So can SectionLayout and AppLayout change anything defined in SharedLayout. This is easier to do with inheritance in Cheetah than it is to do with Metal macros where the slot mechanism is a bit more tedious and explicit. In Metal you have to fill every slot. In Cheetah, there may be 30 different methods that come into play in the inheritance hierarchy, but I only have to redefine the ones I care about at the Screen level. Of course, take these statements with a grain of salt. I'm currently making use of Plone for one project (trying to learn something new), and my knowledge of Cheetah is better than my knowledge of ZPT and Metal. Perhaps I'm completely wrong. Best Regards, -jj On 9/21/05, Shannon -jj Behrens wrote: > 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 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 at 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. > -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From jjinux at gmail.com Thu Sep 22 06:54:11 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Wed, 21 Sep 2005 21:54:11 -0700 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> <130df1930509101120322e734e@mail.gmail.com> <43232874.2040102@colorstudy.com> <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> <43320859.7000405@colorstudy.com> Message-ID: Sorry to keep yacking, but one more thing comes into play. In Aquarium, I have this thing called inverseExtend. This allows a parent class, say SharedLayout, to completely and automatically wrap the child class. It gets to "go first", call the child when it wants, and do with the output what it wants. This is done in Webware too, but for only one level. I.e. someone has to define respond (is that the right method name?). If you want to repeat this for another step in the hierarchy, you have to come up with a new method name. In Aquarium, every level defines __call__, and the control flow starts at the top of the inheritance hierarchy and works its way down. Each parent wraps the child. I took this technique from Mason. It's amazing how helpful it is. Screen can redefine methods defined by SharedLayout, but SharedLayout can choose to do anything it wants with the output of, say AppLayout. Hence, you end up with: AppLayout SharedLayout SectionLayout Screen Section Layout Shared Layout AppLayout Ok, hopefully I'll shut up now ;) Best Regards, -jj On 9/21/05, Shannon -jj Behrens wrote: > Sorry, I didn't mean to sound like I was bragging. I should note that > imho this is a bit easier to do with Cheetah than with ZPT and Metal. > In Cheetah, if I have a deep inheritance hierarchy: > > SharedLayout > AppLayout > SectionLayout > Screen > > Then, within Screen I can override, extend, or define methods that are > defined at any level of the hierarchy. Since everything is defined as > a method somewhere, Screen can change any part of the look and feel it > wants. So can SectionLayout and AppLayout change anything defined in > SharedLayout. This is easier to do with inheritance in Cheetah than > it is to do with Metal macros where the slot mechanism is a bit more > tedious and explicit. In Metal you have to fill every slot. In > Cheetah, there may be 30 different methods that come into play in the > inheritance hierarchy, but I only have to redefine the ones I care > about at the Screen level. > > Of course, take these statements with a grain of salt. I'm currently > making use of Plone for one project (trying to learn something new), > and my knowledge of Cheetah is better than my knowledge of ZPT and > Metal. Perhaps I'm completely wrong. > > Best Regards, > -jj > > On 9/21/05, Shannon -jj Behrens wrote: > > 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 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 at 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. > > > > > -- > I have decided to switch to Gmail, but messages to my Yahoo account will > still get through. > -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From ben at groovie.org Thu Sep 22 07:59:07 2005 From: ben at groovie.org (Ben Bangert) Date: Wed, 21 Sep 2005 22:59:07 -0700 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> <130df1930509101120322e734e@mail.gmail.com> <43232874.2040102@colorstudy.com> <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> <43320859.7000405@colorstudy.com> Message-ID: On Sep 21, 2005, at 9:54 PM, Shannon -jj Behrens wrote: > Sorry to keep yacking, but one more thing comes into play. In > Aquarium, I have this thing called inverseExtend. This allows a > parent class, say SharedLayout, to completely and automatically wrap > the child class. It gets to "go first", call the child when it wants, > and do with the output what it wants. This is done in Webware too, > but for only one level. I.e. someone has to define respond (is that > the right method name?). If you want to repeat this for another step > in the hierarchy, you have to come up with a new method name. In > Aquarium, every level defines __call__, and the control flow starts at > the top of the inheritance hierarchy and works its way down. Each > parent wraps the child. I took this technique from Mason. It's > amazing how helpful it is. Screen can redefine methods defined by > SharedLayout, but SharedLayout can choose to do anything it wants with > the output of, say AppLayout. Hence, you end up with: > > AppLayout > SharedLayout > SectionLayout > Screen > Section Layout > Shared Layout > AppLayout > > Ok, hopefully I'll shut up now ;) Myghty has inheritance that does the same thing (as its a port of Mason). Whether a framework like Myghty or Aquarium can do inheritance skinning isn't completely relevant I believe. In this case the example I perceived was having a unified template for multiple, quite likely different, webapps running entirely different frameworks. That's why Ian was referring to having Apache run output filters, and why Ian and I were referring to a middleware/ filter layer that adds the consistent site feel. Ksenia's original post was talking about having the content from an entire webapp would be wrapped into a site template generated by main publisher. This would have the advantage of skinning any webapp the user wishes to run. (I hope this is what the actual meaning was at least) The reason I say its not really relevant, is because how or what a user uses to skin the site, may or may not work well depending on how the webapp functions. If the webapp uses an inheritance template scheme (like Myghty/Aquarium/others?), then it could be relying on the ability to insert code higher up the template chain, all the way back to the HTML head. This is why having a generic skinning webapp thats outside the webapp itself (whether a filter/middleware app OR Apache output filter), won't really work unless the webapp designer is aware of this and can handle the user stripping away sections of the page the webapp designer is assuming will exist... Hopefully that actually makes sense. But in short, some template languages lose a lot of power without the ability to do this kind of hooking into functions up the inheritance chain. This is why webapp ignorant output filters running over the output won't work for those webapps. Maybe people distributing such a webapp should do something to indicate that skinning should occur "inside" the app vs having something applied "outside"? Cheers, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/web-sig/attachments/20050921/2772ba5a/attachment.html From stephan.diehl at gmx.net Thu Sep 22 09:13:39 2005 From: stephan.diehl at gmx.net (Stephan Diehl) Date: Thu, 22 Sep 2005 09:13:39 +0200 Subject: [Web-SIG] Webapplication and Javascript In-Reply-To: References: <200509211856.53214.stephan.diehl@gmx.net> Message-ID: <200509220913.39527.stephan.diehl@gmx.net> On Wednesday 21 September 2005 20:18, Shannon -jj Behrens wrote: > I've seen two things similar to this lately: > > http://www.innoscript.org/content/view/30/42/ this is certainly quite an interesting project. I'm aiming at something a bit lighter :) > http://www.turbogears.org/ If my stuff were ready and Kevin liked it, it could go in there... --- Stephan > > Perhaps that aren't 100% matches with your project, but they're close. > It'd be great if you guys could work together! > > Best Regards, > -jj > > On 9/21/05, Stephan Diehl wrote: > > Hi, > > > > I'm in the process of developing a kind of web widget library. [...] From dangoor at gmail.com Thu Sep 22 15:59:48 2005 From: dangoor at gmail.com (Kevin Dangoor) Date: Thu, 22 Sep 2005 09:59:48 -0400 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> <130df1930509101120322e734e@mail.gmail.com> <43232874.2040102@colorstudy.com> <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> Message-ID: <3f085ecd05092206595c45dd8f@mail.gmail.com> On 9/21/05, Ben Bangert wrote: > 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. For API ideas here, you all might be interested in looking at SiteMesh, which is popular in Javaland: http://www.opensymphony.com/sitemesh/ Not that Java APIs tend to be all that much fun to work with, but SiteMesh is all about glomming together bits from webapps into a coherent whole. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: kid at blazingthings.com company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com From m at keysolutions.ru Fri Sep 23 10:49:11 2005 From: m at keysolutions.ru (Mikhail Kashkin) Date: Fri, 23 Sep 2005 12:49:11 +0400 Subject: [Web-SIG] Repository for python developers Message-ID: Moscow, Russia, September 23th, 2005 We are happy to spread good news about `Key Solutions' `_ new initiative. We have created a new public repository for python developers. The ulitimate goal of this project is to unite companies and people under the umbrella of Russian-speaking-python (Zope/Plone/Zope3/Twisted/etc) open source programmers community, so that we could jointly push forward new programs and technologies in Russia. The repository powered by `subversion `_. **Links**: - `Press release in russian `_ - `??????? ?? ??????? `_ - `Subversion `_ About Key Solutions -------------------- Key Solutions is an open source company with primary focus in development of corporative CRM Internet/intranet systems and web-communities. The company promotes and supports Zope, Plone, Asterisk platforms in Russia. To learn more about Key Solutions visit `eng.keysolutions.ru `_ and `keysolutions.ru `_ -- Mikhail Kashkin, Key Solutions (http://keysolutions.ru/) Director Zope/Asterisk/Plone - Solutions/Consulting/Support Plone ?? ??????? http://plone.org.ru/ Plone Foundation Member (http://plone.org/foundation/members/) From jjinux at gmail.com Thu Sep 29 11:45:46 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Thu, 29 Sep 2005 02:45:46 -0700 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> <130df1930509101120322e734e@mail.gmail.com> <43232874.2040102@colorstudy.com> <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> <43320859.7000405@colorstudy.com> Message-ID: On 9/21/05, Ben Bangert wrote: > On Sep 21, 2005, at 9:54 PM, Shannon -jj Behrens wrote: > Sorry to keep yacking, but one more thing comes into play. In > Aquarium, I have this thing called inverseExtend. This allows a > parent class, say SharedLayout, to completely and automatically wrap > the child class. It gets to "go first", call the child when it wants, > and do with the output what it wants. This is done in Webware too, > but for only one level. I.e. someone has to define respond (is that > the right method name?). If you want to repeat this for another step > in the hierarchy, you have to come up with a new method name. In > Aquarium, every level defines __call__, and the control flow starts at > the top of the inheritance hierarchy and works its way down. Each > parent wraps the child. I took this technique from Mason. It's > amazing how helpful it is. Screen can redefine methods defined by > SharedLayout, but SharedLayout can choose to do anything it wants with > the output of, say AppLayout. Hence, you end up with: > > AppLayout > SharedLayout > SectionLayout > Screen > Section Layout > Shared Layout > AppLayout > > Ok, hopefully I'll shut up now ;) > Myghty has inheritance that does the same thing (as its a port of Mason). Yep, I stole it from Mason ;) > Whether a framework like Myghty or Aquarium can do inheritance skinning > isn't completely relevant I believe. > > In this case the example I perceived was having a unified template for > multiple, quite likely different, webapps running entirely different > frameworks. That's why Ian was referring to having Apache run output > filters, and why Ian and I were referring to a middleware/filter layer that > adds the consistent site feel. > > Ksenia's original post was talking about having the content from an entire > webapp would be wrapped into a site template generated by main publisher. > This would have the advantage of skinning any webapp the user wishes to run. > (I hope this is what the actual meaning was at least) > > The reason I say its not really relevant, is because how or what a user uses > to skin the site, may or may not work well depending on how the webapp > functions. If the webapp uses an inheritance template scheme (like > Myghty/Aquarium/others?), then it could be relying on the ability to insert > code higher up the template chain, all the way back to the HTML head. > > This is why having a generic skinning webapp thats outside the webapp itself > (whether a filter/middleware app OR Apache output filter), won't really work > unless the webapp designer is aware of this and can handle the user > stripping away sections of the page the webapp designer is assuming will > exist... > > Hopefully that actually makes sense. But in short, some template languages > lose a lot of power without the ability to do this kind of hooking into > functions up the inheritance chain. This is why webapp ignorant output > filters running over the output won't work for those webapps. > > Maybe people distributing such a webapp should do something to indicate that > skinning should occur "inside" the app vs having something applied > "outside"? I completely agree. Is this a real problem that a lot of people face or is it of academic interest only? It seems to me that sticking to a framework for your own code is a very helpful thing. If you must support 2 frameworks, recode the common look and feel as you transition from one framework to the newer framework. I think trying to always be completely framework neutral is like trying to use C with no pointers :-D I have to deal with upwards of 10 apps across many departments that all use my shared look and feel. The way the different apps use inheritance hooks to subtly change various parts of the page is intricate. I'd hate to have to do that using a filter :-/ Oh well, YMMV. Best Regards, -jj -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through. From ianb at colorstudy.com Thu Sep 29 20:04:19 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 29 Sep 2005 13:04:19 -0500 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: References: <130df1930509101024549c62ab@mail.gmail.com> <43231DBF.9020207@colorstudy.com> <130df1930509101120322e734e@mail.gmail.com> <43232874.2040102@colorstudy.com> <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> <43320859.7000405@colorstudy.com> Message-ID: <433C2CA3.3000906@colorstudy.com> Shannon -jj Behrens wrote: >>Hopefully that actually makes sense. But in short, some template languages >>lose a lot of power without the ability to do this kind of hooking into >>functions up the inheritance chain. This is why webapp ignorant output >>filters running over the output won't work for those webapps. >> >>Maybe people distributing such a webapp should do something to indicate that >>skinning should occur "inside" the app vs having something applied >>"outside"? > > > I completely agree. Is this a real problem that a lot of people face > or is it of academic interest only? Yes, it is a real problem! I face it every day, it seems. It is the nature of life in a heterogeneous shop. Of course, that also includes non-Python apps, which rules out a bunch of possible solutions for me. > It seems to me that sticking to a > framework for your own code is a very helpful thing. If you must > support 2 frameworks, recode the common look and feel as you > transition from one framework to the newer framework. I think trying > to always be completely framework neutral is like trying to use C with > no pointers :-D If I don't want to fall into complete NIH syndrome, I must face the fact that I don't have one framework. Obviously not everything can be framework neutral, but it's really just a desire to keep the number of hacks to a minimum. > I have to deal with upwards of 10 apps across many departments that > all use my shared look and feel. The way the different apps use > inheritance hooks to subtly change various parts of the page is > intricate. I'd hate to have to do that using a filter :-/ Oh well, > YMMV. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From jjinux at gmail.com Thu Sep 29 23:49:01 2005 From: jjinux at gmail.com (Shannon -jj Behrens) Date: Thu, 29 Sep 2005 14:49:01 -0700 Subject: [Web-SIG] using WSGI for standard pluggable applications In-Reply-To: <433C2CA3.3000906@colorstudy.com> References: <130df1930509101024549c62ab@mail.gmail.com> <43232874.2040102@colorstudy.com> <847056F3-2B97-49B5-B1E6-11FB106DEB30@groovie.org> <43320859.7000405@colorstudy.com> <433C2CA3.3000906@colorstudy.com> Message-ID: Thanks, Ian. Now I understand your problem. If I were in your shoes, I would make use of dom manipulation on the server side. I.e., I would use the same "inheritance" tricks, but instead of using inheritance via code, I would have the filters look for certain div's with certain id's. In effect, these div's would act as methods for the wrapped applications. In this way, the wrapper and the application wrapped can have a better channel for communication. You can even implement inheritance in this manner. Just throwing ideas out, you might also want to consider using JSON as a communication medium that is language neutral. The wrapped application can embed some JSON data. The wrapper application can make use of that data. Viola, rich communication. Of course, you're a smart guy, so you don't need me telling you how to write apps ;) -jj On 9/29/05, Ian Bicking wrote: > Shannon -jj Behrens wrote: > >>Hopefully that actually makes sense. But in short, some template languages > >>lose a lot of power without the ability to do this kind of hooking into > >>functions up the inheritance chain. This is why webapp ignorant output > >>filters running over the output won't work for those webapps. > >> > >>Maybe people distributing such a webapp should do something to indicate that > >>skinning should occur "inside" the app vs having something applied > >>"outside"? > > > > > > I completely agree. Is this a real problem that a lot of people face > > or is it of academic interest only? > > Yes, it is a real problem! I face it every day, it seems. It is the > nature of life in a heterogeneous shop. Of course, that also includes > non-Python apps, which rules out a bunch of possible solutions for me. > > > It seems to me that sticking to a > > framework for your own code is a very helpful thing. If you must > > support 2 frameworks, recode the common look and feel as you > > transition from one framework to the newer framework. I think trying > > to always be completely framework neutral is like trying to use C with > > no pointers :-D > > If I don't want to fall into complete NIH syndrome, I must face the fact > that I don't have one framework. > > Obviously not everything can be framework neutral, but it's really just > a desire to keep the number of hacks to a minimum. > > > I have to deal with upwards of 10 apps across many departments that > > all use my shared look and feel. The way the different apps use > > inheritance hooks to subtly change various parts of the page is > > intricate. I'd hate to have to do that using a filter :-/ Oh well, > > YMMV. -- I have decided to switch to Gmail, but messages to my Yahoo account will still get through.