From: <pau...@em...> - 2003-06-12 09:49:50
|
Ian Bicking [mailto:ia...@co...] wrote: >=20 > Well, I'm not exactly objective, but then while Webware is my > preference, Zope is my current reality in professional programming. You're relatively lucky, then. The closest to job-related Web = applications I get these days involves vanilla J2EE technologies. =20 > > I have had weird ZODB issues in the past. >=20 > ZODB seems kind of separate from Zope -- you can use Zope without = making > any interesting use of ZODB (just using it as a container for your > scripts), or you can use ZODB without using Zope. In the golden age of Bobo, I noticed some unreliability with ZODB (as it = probably wasn't known back then) and I do confess to being somewhat = unnerved by pickle-based persistence. However, the main advantage with = using ZODB outside Zope is that you can easily split your data into many = databases - a huge single file ZODB database (Data.fs?) would scare me = in a production environment. > Webware servlets are the one and only frontend to your application.=20 > Most applications don't have a huge number of servlets. But there's a > lot of objects and modules. Since Webware doesn't publish everything, > you don't have to worry about this stuff. Yes, in contrast, if you want to take full advantage of Zope's = management capabilities, it would seem that everything runs the risk of = being exposed unless protected by various access rules. It's a bit like = someone insisting that you perform all your life's activities on a = public beach. > Also, because Webware doesn't publish everything, you can use Python > modules and objects that aren't Zope-aware. Zope makes this really = hard > -- like, for some reason a Postgres connection is returning an > mxDateTime (un-Zope-aware) object periodically, instead of a Zope > DateTime object. Trying to access the .year attribute, I get a not > authorized error. That's just stupid. I had a small demo application working in Zope 2.5 (I think) and upon = upgrading to Zope 2.6 it stopped working for exactly the reasons = described. My reaction: "WTF?!" Moreover, this all seemed so obvious to = those already familiar with Zope that it took a while before I found the = magic words to unbreak my application in some documentation or mailing = list archive or other. It wasn't as if the offending objects were doing = anything unreasonable - they were just simple data containers. > For deployment, Webware is much lighter than Zope (and not just > CPU-wise), and I think that makes deployment easier. But you won't = find > things prepackaged, or many hosts that specifically support Webware, = so > you do have to do deployment on your own. But it's not hard, and you > get to use file-based tools. One thing that has reportedly been problematic with Zope and Webware is = the choice of threads for distributing work and the scalability issues = that this brings with it. Having said that, the threaded paradigm is = probably so entrenched in the average Webware application (or in = power-user applications, at least) that I can't see a process-oriented = variant of Webware any time soon. Paul |
From: Geoffrey T. <gta...@na...> - 2003-06-12 13:16:23
|
pau...@em... wrote: > One thing that has reportedly been problematic with Zope and > Webware is the choice of threads for distributing work and > the scalability issues that this brings with it. Having said > that, the threaded paradigm is probably so entrenched in the > average Webware application (or in power-user applications, > at least) that I can't see a process-oriented variant of Webware any > time soon. I love the coding convenience that Webware's threaded architecture gives me. It makes caching things like SQL results in memory trivially easy. It's memory-efficient. And so forth. But there is a drawback. If there's a bug in any of your C-coded extension modules that causes the process to crash, it kills the whole app server including any other requests that were being processed. And then you lose all of the current sessions. This has bitten some people on this mailing list in the past because of bugs in database adapters. And right now I'm trying to track down a problem where I have a servlet that makes an HTTPS request to another web site (using Python's built-in SSL support), and it looks like every once in a while, something happens during that outgoing HTTPS request that crashes the app server. It only happens like once a week, so I haven't had any luck tracking this down. If Webware used some sort of process pool instead of a thread pool, and served only one request per process, this wouldn't be as much of a problem. - Geoff |
From: Chuck E. <Chu...@ya...> - 2003-06-16 03:35:34
|
On Thursday 12 June 2003 06:16 am, Geoffrey Talvola wrote: > This has bitten some people on this mailing list in the past because > of bugs in database adapters. And right now I'm trying to track down > a problem where I have a servlet that makes an HTTPS request to > another web site (using Python's built-in SSL support), and it looks > like every once in a while, something happens during that outgoing > HTTPS request that crashes the app server. It only happens like once > a week, so I haven't had any luck tracking this down. If Webware > used some sort of process pool instead of a thread pool, and served > only one request per process, this wouldn't be as much of a problem. Could you factor this out to another WebKit instance which you would hit with Pickle-RPC or XML-RPC from the main one? Then when your HTTPS code crashed, your main app server would be intact. I realize that solution isn't on a silver platter, but then setting up and calling RPC services with WebKit *is* fairly straightforward. -- Chuck http://ChuckEsterbrook.com |
From: <pau...@em...> - 2003-06-12 13:46:49
|
Geoffrey Talvola [mailto:gta...@na...] wrote: >=20 > If Webware used some sort of process pool instead of a > thread pool, and served only one request per process, this=20 > wouldn't be as much of a problem. It could be interesting to investigate the tantalising, but still = apparently obscure, POSH (poshmodule.sf.net) mechanism for sharing data = between processes in an apparently "thread-like" fashion. Sadly, I don't = have the time (or mandate) to look into that, but it could address the = various scalability and reliability complaints that have come up, at = least if it didn't disrupt the programming model employed by most = Webware applications too much. On a more mundane level, I should really send some patches in around = "classic" CGI environment variables, and possibly around URLs and paths, = although I imagine that Ian Bicking's work probably conflicts with the = latter somewhat. Paul |
From: Hancock, D. (DHANCOCK) <DHA...@ar...> - 2003-06-12 13:58:42
|
Two cents worth from an not-very-informed user. We had problems with Zope vs. long-running processes initially and that drove us to Webware, and we've been happy with it ever since. With Zope, if a web request spawned one long-running process, no problem: other web requests would continue to be answered. As soon as you spawned a second long-running request, all other web requests would hang until one of the two long-running processes ended. We tried the same with Webware, and had no problems at all handling many concurrent requests, even when some of them spawned lengthy processes. It seems to me that adopting a process-based architecture would reduce performance considerably, but maybe there's some middle ground using FastCGI or mod_python. My main concern about mod_python (and mod_perl, which I have more experience with) is that they bloat up httpd processes considerably. I haven't used either with Apache 2.0 in its threaded mode, so I don't know if it's an issue there or not. Cheers! -- David Hancock | dha...@ar... | 410-266-4384 -----Original Message----- From: Geoffrey Talvola [mailto:gta...@na...] Sent: Thursday, June 12, 2003 9:16 AM To: web...@li... Subject: RE: [Webware-discuss] Zope vs Webware (Not Really) pau...@em... wrote: > One thing that has reportedly been problematic with Zope and > Webware is the choice of threads for distributing work and > the scalability issues that this brings with it. Having said > that, the threaded paradigm is probably so entrenched in the > average Webware application (or in power-user applications, > at least) that I can't see a process-oriented variant of Webware any > time soon. I love the coding convenience that Webware's threaded architecture gives me. It makes caching things like SQL results in memory trivially easy. It's memory-efficient. And so forth. But there is a drawback. If there's a bug in any of your C-coded extension modules that causes the process to crash, it kills the whole app server including any other requests that were being processed. And then you lose all of the current sessions. This has bitten some people on this mailing list in the past because of bugs in database adapters. And right now I'm trying to track down a problem where I have a servlet that makes an HTTPS request to another web site (using Python's built-in SSL support), and it looks like every once in a while, something happens during that outgoing HTTPS request that crashes the app server. It only happens like once a week, so I haven't had any luck tracking this down. If Webware used some sort of process pool instead of a thread pool, and served only one request per process, this wouldn't be as much of a problem. - Geoff ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Webware-discuss mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: <pau...@em...> - 2003-06-12 14:17:57
|
Hancock, David (DHANCOCK) [mailto:DHA...@ar...] wrote: >=20 > It seems to me that adopting a process-based architecture would reduce > performance considerably, but maybe there's some middle ground using = FastCGI > or mod_python. I suppose I should have said "process pooling" rather than = process-oriented, because people do tend to think of CGI or intensive = process creation/destruction when processes are mentioned. > My main concern about mod_python (and mod_perl, which I have > more experience with) is that they bloat up httpd processes = considerably. I > haven't used either with Apache 2.0 in its threaded mode, so I don't = know if > it's an issue there or not. I haven't looked *that* deeply into mod_python, but I have also heard = scary things about mod_perl. As for the thread vs. process situation, it = seems to me that the main benefit of using threads is the reduced = overhead in inter-thread communication and access to shared data, but = I'm not entirely convinced that this is always going to be a dominant = factor in Web applications. Any comments on that? Paul |
From: Chris B. <ch...@ch...> - 2003-06-12 14:32:16
|
I think the process issue lies within the Webware application server, and not the connection from Apache to Webware. ----- Original Message ----- From: <pau...@em...> To: <web...@li...> Sent: Thursday, June 12, 2003 7:17 AM Subject: RE: [Webware-discuss] Zope vs Webware (Not Really) > Hancock, David (DHANCOCK) [mailto:DHA...@ar...] wrote: > > > > It seems to me that adopting a process-based architecture would reduce > > performance considerably, but maybe there's some middle ground using FastCGI > > or mod_python. > > I suppose I should have said "process pooling" rather than process-oriented, because people do tend to think of CGI or intensive process creation/destruction when processes are mentioned. > > > My main concern about mod_python (and mod_perl, which I have > > more experience with) is that they bloat up httpd processes considerably. I > > haven't used either with Apache 2.0 in its threaded mode, so I don't know if > > it's an issue there or not. > > I haven't looked *that* deeply into mod_python, but I have also heard scary things about mod_perl. As for the thread vs. process situation, it seems to me that the main benefit of using threads is the reduced overhead in inter-thread communication and access to shared data, but I'm not entirely convinced that this is always going to be a dominant factor in Web applications. Any comments on that? > > Paul > > > ------------------------------------------------------- > This SF.NET email is sponsored by: eBay > Great deals on office technology -- on eBay now! Click here: > http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 > _______________________________________________ > Webware-discuss mailing list > Web...@li... > https://lists.sourceforge.net/lists/listinfo/webware-discuss > |
From: <pau...@em...> - 2003-06-13 11:32:18
|
Ian Bicking [mailto:ia...@co...] wrote: >=20 > I would also like to see a standard "container". I don't think it = even > has to be terribly intrusive or conformist -- it just has to create > request and response objects, and map those to some "resource", which > would be somewhat more abstract than servlets. My private experiments suggest that it isn't that hard to make an = abstraction layer for Webware and mod_python - in these cases, the main = differences are where one finds certain facilities (eg. request and = response streams, content type and encoding information) and whether = those facilities are implemented by separate objects or not. Providing = an environment for a Webware-style plug-in (which takes responsibility = for certain resource types) within mod_python isn't an insurmountable = problem either, and I'm convinced that there's enough common ground in = Twisted and Zope to cover those frameworks as well. Under the covers, in = Zope Products, Zope isn't so different after all. > I was trying to pursue this kind of unification after PyCon, but I'm > afraid I lost momentum, and actually writing code is much more > satisfying than trying to organize stuff. I'd still like to pursue = it, > though. The "shootout" paper was certainly very interesting, and recent coverage = of Twisted Web suggests that it wouldn't be absolutely necessary to put = the whole of Webware on top of Twisted to get a decent application = environment with a different execution model: http://twistedmatrix.com/users/nafai/pycon-paper/tw_deploy-01.html That would be compelling: a common environment which runs on servers = with completely different underlying "scalability" models (threads, = processes, asynchronous tasks) - I doubt that there's such diversity = between the mainstream Java application servers. > I've been working on a component idea, for adding functionality to > servlets -- a bit finer grained than plugins. It's in the Webware > sandbox (webware-sandbox.sf.net), in ianbicking/Component, with a user > authentication component as an example. I've also used it for (my = still > in heavy development) form processing toolkit, in FormEncode, also in > the Sandbox. Perhaps I should get around to looking at this as well. Paul |
From: Geoffrey T. <gta...@na...> - 2003-06-16 14:29:58
|
Chuck Esterbrook wrote: > On Thursday 12 June 2003 06:16 am, Geoffrey Talvola wrote: >> This has bitten some people on this mailing list in the past because >> of bugs in database adapters. And right now I'm trying to track down >> a problem where I have a servlet that makes an HTTPS request to >> another web site (using Python's built-in SSL support), and it looks >> like every once in a while, something happens during that outgoing >> HTTPS request that crashes the app server. It only happens like once >> a week, so I haven't had any luck tracking this down. If Webware >> used some sort of process pool instead of a thread pool, and served >> only one request per process, this wouldn't be as much of a problem. > > Could you factor this out to another WebKit instance which you would > hit with Pickle-RPC or XML-RPC from the main one? Then when your > HTTPS code crashed, your main app server would be intact. > > I realize that solution isn't on a silver platter, but then setting up > and calling RPC services with WebKit *is* fairly straightforward. Even easier, I'll probably just use stunnel to handle the encryption if this continues to happen. - Geoff |
From: Ian B. <ia...@co...> - 2003-06-12 17:53:09
|
On Thu, 2003-06-12 at 04:49, pau...@em... wrote: > Ian Bicking [mailto:ia...@co...] wrote: > > > > Well, I'm not exactly objective, but then while Webware is my > > preference, Zope is my current reality in professional programming. > > You're relatively lucky, then. The closest to job-related Web > applications I get these days involves vanilla J2EE technologies. Yeah, I'm not complaining. I must admit I'm still subtley suggesting changes which may include Webware (knock on wood). > > Also, because Webware doesn't publish everything, you can use Python > > modules and objects that aren't Zope-aware. Zope makes this really hard > > -- like, for some reason a Postgres connection is returning an > > mxDateTime (un-Zope-aware) object periodically, instead of a Zope > > DateTime object. Trying to access the .year attribute, I get a not > > authorized error. That's just stupid. > > I had a small demo application working in Zope 2.5 (I think) and upon > upgrading to Zope 2.6 it stopped working for exactly the reasons > described. My reaction: "WTF?!" Moreover, this all seemed so obvious > to those already familiar with Zope that it took a while before I > found the magic words to unbreak my application in some documentation > or mailing list archive or other. It wasn't as if the offending > objects were doing anything unreasonable - they were just simple data > containers. Yeah, basic OO methodology is *really hard* in Zope. I think that's what drives me crazy, and it comes back to the security stuff. But the result is that it's too easy to create bad applications in Zope, and too painful to create good applications. That problem exists everywhere -- procedural code is easier to bang through -- but Zope goes too far. The heavy app server also makes upgrading and such difficult. It seems common to run several discrete applications on a single Zope server, which seems like a bad idea to me -- development versions living alongside production versions, having to upgrade things en masse, and then testing that big heap of code... bad stuff. > > For deployment, Webware is much lighter than Zope (and not just > > CPU-wise), and I think that makes deployment easier. But you won't find > > things prepackaged, or many hosts that specifically support Webware, so > > you do have to do deployment on your own. But it's not hard, and you > > get to use file-based tools. > > One thing that has reportedly been problematic with Zope and Webware > is the choice of threads for distributing work and the scalability > issues that this brings with it. Having said that, the threaded > paradigm is probably so entrenched in the average Webware application > (or in power-user applications, at least) that I can't see a > process-oriented variant of Webware any time soon. While it wouldn't be that hard to port the basic Webware infrastructure to a process model, I also think that Webware *is* threads, at least at this point -- it's a framework, and threads are implicitly a part of that framework. That said, most use of threads could probably be abstracted fairly easily -- it's mostly just data sharing, and while that's easy with threads it's still not entirely trivial (at least if you handle concurrency). Perhaps abstractions are possible that would make something like POSH a drop-in replacement. Personally I don't buy the scalability arguments for processes -- they are based on theory, not practice -- but I definitely do appreciate the reliability issues. Of course, then there's the problem that processes work very badly on Windows... but again, with the right abstractions. Ian |
From: Tracy S. R. <tr...@re...> - 2003-06-12 18:42:57
|
On Thursday, June 12, 2003, at 12:53 PM, Ian Bicking wrote: >>> Also, because Webware doesn't publish everything, you can use Python >>> modules and objects that aren't Zope-aware. Zope makes this really >>> hard >>> -- like, for some reason a Postgres connection is returning an >>> mxDateTime (un-Zope-aware) object periodically, instead of a Zope >>> DateTime object. Trying to access the .year attribute, I get a not >>> authorized error. That's just stupid. >> >> I had a small demo application working in Zope 2.5 (I think) and upon >> upgrading to Zope 2.6 it stopped working for exactly the reasons >> described. My reaction: "WTF?!" Moreover, this all seemed so obvious >> to those already familiar with Zope that it took a while before I >> found the magic words to unbreak my application in some documentation >> or mailing list archive or other. It wasn't as if the offending >> objects were doing anything unreasonable - they were just simple data >> containers. > > Yeah, basic OO methodology is *really hard* in Zope. I think that's > what drives me crazy, and it comes back to the security stuff. But the > result is that it's too easy to create bad applications in Zope, and > too > painful to create good applications. That problem exists everywhere -- > procedural code is easier to bang through -- but Zope goes too far. All I can say is that Zope hurt my brain when I tried to use it. If application servers were gloves, Zope would be a huge mangling metal monstrosity that latches around your ligaments, compromises the integrity of your bone structure, denudes you of subtle sensations and basically atrophies the muscular system of an otherwise healthy hand. While Webware, on the other hand, is like smooth satin joy. You can still do everything you could do before, but it's much more fun because it feels so good! --T |
From: Chris B. <ch...@ch...> - 2003-06-12 18:58:11
|
I am not to worried about process vs threads right now. My only concern is "rolling my own" security and stuff like that. I like how Zope's security allows you to use different acl_users folder that supports different authorizations--although I want groups. But on the flip-side, one of the reasons I am reluctant about Zope is that anything I do will only work in Zope. It is not very useable outside Zope. This is the one drawback about developing with python for web-apps compared to Java right now. There are no real standards for developing/deploying python web-apps and it almost always depends on what python app server/apache mod that you use. I hate the fact that the Java community has all these crazy "best practices" for developing web apps, however some things are kinda cool about the servlet containers when it comes to standard ways of defining security and uri mapping. The idea is really nice that you can take a java .war file (web archive) and drop it into most any java app server and it is ready to go. Then the admin can just modify some xml files. I am not sure if it is good or bad to have some kind of standard "container"? I wish developing python web-apps could run on most any python app server. But after spending many years developing java apps, I can say for sure that java is really dissappointing for developing web apps. But, I think Webware has some great potential with plug-ins. I just wish there were more of them! But that might be the way to go right now, developing the Zope-like things that make it easy to build web-apps in Zope as plug-ins for Webware. Chris ----- Original Message ----- From: Ian Bicking To: pau...@em... Cc: Webware discuss Sent: Thursday, June 12, 2003 10:53 AM Subject: RE: [Webware-discuss] Zope vs Webware (Not Really) On Thu, 2003-06-12 at 04:49, pau...@em... wrote: > Ian Bicking [mailto:ia...@co...] wrote: > > > > Well, I'm not exactly objective, but then while Webware is my > > preference, Zope is my current reality in professional programming. > > You're relatively lucky, then. The closest to job-related Web > applications I get these days involves vanilla J2EE technologies. Yeah, I'm not complaining. I must admit I'm still subtley suggesting changes which may include Webware (knock on wood). > > Also, because Webware doesn't publish everything, you can use Python > > modules and objects that aren't Zope-aware. Zope makes this really hard > > -- like, for some reason a Postgres connection is returning an > > mxDateTime (un-Zope-aware) object periodically, instead of a Zope > > DateTime object. Trying to access the .year attribute, I get a not > > authorized error. That's just stupid. > > I had a small demo application working in Zope 2.5 (I think) and upon > upgrading to Zope 2.6 it stopped working for exactly the reasons > described. My reaction: "WTF?!" Moreover, this all seemed so obvious > to those already familiar with Zope that it took a while before I > found the magic words to unbreak my application in some documentation > or mailing list archive or other. It wasn't as if the offending > objects were doing anything unreasonable - they were just simple data > containers. Yeah, basic OO methodology is *really hard* in Zope. I think that's what drives me crazy, and it comes back to the security stuff. But the result is that it's too easy to create bad applications in Zope, and too painful to create good applications. That problem exists everywhere -- procedural code is easier to bang through -- but Zope goes too far. The heavy app server also makes upgrading and such difficult. It seems common to run several discrete applications on a single Zope server, which seems like a bad idea to me -- development versions living alongside production versions, having to upgrade things en masse, and then testing that big heap of code... bad stuff. > > For deployment, Webware is much lighter than Zope (and not just > > CPU-wise), and I think that makes deployment easier. But you won't find > > things prepackaged, or many hosts that specifically support Webware, so > > you do have to do deployment on your own. But it's not hard, and you > > get to use file-based tools. > > One thing that has reportedly been problematic with Zope and Webware > is the choice of threads for distributing work and the scalability > issues that this brings with it. Having said that, the threaded > paradigm is probably so entrenched in the average Webware application > (or in power-user applications, at least) that I can't see a > process-oriented variant of Webware any time soon. While it wouldn't be that hard to port the basic Webware infrastructure to a process model, I also think that Webware *is* threads, at least at this point -- it's a framework, and threads are implicitly a part of that framework. That said, most use of threads could probably be abstracted fairly easily -- it's mostly just data sharing, and while that's easy with threads it's still not entirely trivial (at least if you handle concurrency). Perhaps abstractions are possible that would make something like POSH a drop-in replacement. Personally I don't buy the scalability arguments for processes -- they are based on theory, not practice -- but I definitely do appreciate the reliability issues. Of course, then there's the problem that processes work very badly on Windows... but again, with the right abstractions. Ian ------------------------------------------------------- This SF.NET email is sponsored by: eBay Great deals on office technology -- on eBay now! Click here: http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 _______________________________________________ Webware-discuss mailing list Web...@li... https://lists.sourceforge.net/lists/listinfo/webware-discuss |
From: Ian B. <ia...@co...> - 2003-06-12 19:51:21
|
On Thu, 2003-06-12 at 13:57, Chris Bruce wrote: > I am not to worried about process vs threads right now. > > My only concern is "rolling my own" security and stuff like that. I like > how Zope's security allows you to use different acl_users folder that > supports different authorizations--although I want groups. But on the > flip-side, one of the reasons I am reluctant about Zope is that anything I > do will only work in Zope. It is not very useable outside Zope. > > This is the one drawback about developing with python for web-apps compared > to Java right now. There are no real standards for developing/deploying > python web-apps and it almost always depends on what python app > server/apache mod that you use. I hate the fact that the Java community has > all these crazy "best practices" for developing web apps, however some > things are kinda cool about the servlet containers when it comes to standard > ways of defining security and uri mapping. The idea is really nice that you > can take a java .war file (web archive) and drop it into most any java app > server and it is ready to go. Then the admin can just modify some xml > files. Personally I detest XML files -- the beauty of OO is when data is not exposed, just methods, and XML exposes data in an inflexible way. But the interchangability would be great. But you can make general, framework-neutral structures in Python -- they just don't *quite* integrate with the framework. You'll have to write per-framework code to glue it in (and make it feel more native). The exception is Zope, where you need to do lots of extra work, and where Zope objects aren't often useful in isolation -- but this is not true of any of the other Python frameworks. > I am not sure if it is good or bad to have some kind of standard > "container"? I wish developing python web-apps could run on most any python > app server. But after spending many years developing java apps, I can say > for sure that java is really dissappointing for developing web apps. But, I > think Webware has some great potential with plug-ins. I just wish there > were more of them! But that might be the way to go right now, developing > the Zope-like things that make it easy to build web-apps in Zope as plug-ins > for Webware. I would also like to see a standard "container". I don't think it even has to be terribly intrusive or conformist -- it just has to create request and response objects, and map those to some "resource", which would be somewhat more abstract than servlets. That model could support servlets, or procedural server pages (think ASP or PHP, rather than JSP, as in Spyce), or object publishing, like with Quixote, or templates, or whatever. Interface differences would be handled with adapters, something that Twisted and Zope people are working on. I was trying to pursue this kind of unification after PyCon, but I'm afraid I lost momentum, and actually writing code is much more satisfying than trying to organize stuff. I'd still like to pursue it, though. As far as plugins, yes, they offer some opportunities, but a lot of stuff can be created without any Webware integration at all -- Cheetah is an example of something written with Webware in mind, but with no dependencies. Then you might write a plugin to glue it together. I've been working on a component idea, for adding functionality to servlets -- a bit finer grained than plugins. It's in the Webware sandbox (webware-sandbox.sf.net), in ianbicking/Component, with a user authentication component as an example. I've also used it for (my still in heavy development) form processing toolkit, in FormEncode, also in the Sandbox. Ian |
From: Thomas D. <t.d...@wo...> - 2003-06-12 21:55:24
|
Ian writes: > Personally I detest XML files -- the beauty of OO is when data is not > exposed, just methods, and XML exposes data in an inflexible way. But > the interchangeability would be great. At Autodesk, we had an object-oriented approach to XML for the Streamline engineering collaboration service. We had class libraries in both C++ and Java for client code (web apps, server apps, and publishing apps), who used objects rather than XML text. XML was used to persist CAD data in "packages," crack open packages to populate databases, and stream structured metadata from databases to web clients. It is very much like C# uses attributes to serialize objects in XML, but we had a finer degree of control. The wrong XML definition was shown to balloon text size to an unacceptable degree pretty quickly. More recently, I used Webware/Python to prototype an online catalog for a local not-for-profit institute serving the visually-impaired. The catalog was defined in XML. (No formal schema, just me inventing a syntax. The initial catalog has 90-100 entries, enough to give me a warm feeling that the XML has pretty good coverage.) One of the goals for the site design was to be able to maintain the web presentation separately from the catalog content. The website look and feel would not change often, but products would be added or deleted from the catalog on an ongoing basis, prices would change, etc. [It should be noted that the online catalog and site are designed only for presentation, and not to support direct purchase at this time.] I got two things from python: 1) A nice class hierarchy for the web page types (welcome, show items in a given category, show search-by-keyword results, show specific item) along with a parallel class hierarchy for the XML filters needed to support them. 2) Good built-in support for SAX parsing, without validation. Given that, what I got from Webware was a straightforward and repeatable organization for the WriteContent method on my python server pages: # parse values from the HTTP request, if any, ... # Read the catalog and render the page, for example # base = os.path.dirname(self.request().serverSidePath()) pp = GoreySearchPage(self, base, 'Gorey.xml', ...) pp.read() pp.render() The read() method parses the XML file, pulling out the juicy bits. The render() method writes the HTML response. Granted, the python statements to crank out the HTML response were tedious to write, but there is a lot of common content across the page types, which was well-supported by the class hierarchy. I was able to get a feature-rich site running in about a week, with no previous Webware experience and somewhat rusty python skills, and to extend the functionality easily a couple times already. On the XML side, the catalog file worked as I intended it to. Changes were automatically reflected in the website, even if the change added or removed a product category, changed the number of pages occupied by a category, or added/removed an entry from a keyword search result on screen. (An aside: pagination is very important when delivering data to the visually-impaired, some of whom might be using a text-to-speech system to READ webpages to them, others who might be using very large type. As a sighted user, I tend to want many results on a page. But I have also experienced the tedium of the mechanical voice droning on and on. We are experimenting with various strategies for separately formatting content to suit users with various classes of visual impairment.) So Webware seemed to be the right venue for getting a proof-of-concept done in a short amount of time, while still having an understandable and extensible design. It remains to be seen whether we will go live with that architecture. Tom Dennehy Private Citizen Bloomfield Hills MI |