You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mod_python-dev@quetz.apache.org by "Daniel J. Popowich" <dp...@comcast.net> on 2004/05/25 19:13:57 UTC
Announcing: Mod_python Servlets
A few months ago I asked Grisha what was the best way to make a
contribution of code to mod_python. He said I should post it to
python-dev and then we'd take it from there.
I felt I needed to write comprehensive documentation and put together
a solid tutorial before posting the code. Nearly three months later,
here I am.
It can be downloaded from:
http://home.comcast.net/~d.popowich/mpservlets/
Below is a snippet from the README file included in the package. It
gives an overview of the handler and its key functionality:
Cheers,
Daniel Popowich
----------------------------------------------------------------------
Excerpt from README:
----------------------------------------------------------------------
Mod_python Servlets
============
0. Preamble
============
It is my intention to donate this handler to mod_python and by
extension, the Apache Foundation. To this end, I have put together
the handler, along with API reference documentation and a tutorial in
the hopes that developers will use it and, finding it a simple, yet
powerfully productive tool, use it in their projects, offer feedback
and, eventually, promote its acceptance in the mainstream
distribution.
============
1. Overview
============
If mod_python's publisher handler is a functional view of the web, the
servlet handler is an object oriented view of the web. It is inspired
by WebWare (http://webware.sourceforge.net).
I programmed with Webware for many projects. I loved the object
oriented view of the web it promoted and found it to be a very
productive tool to quickly prototype web applications. However, I
found it lacking in a number of ways: 1) it has its own server process
that needs to be started and managed, this is in addition to apache or
another web server; 2) its class hierarchy is rather deep: there are
five classes, inclusive, in the hierarchy between the base class and
the class that represents an HTML page (there are only two in
Mod_python Servlets); 3) even though a web server like apache manages
processes and/or threads, WebWare has its own extensive thread
management system which adds complexity to an overall web application;
4) WebWare promotes a comprehensive buy-in to their framework that,
personally, I found unwieldy.
In short, I found WebWare too "big" for my needs and started looking
for something more streamlined. I couldn't find it.
Since I never intended on using a web server other than apache, it
made sense to give mod_python a closer look than I had before. It was
immediately clear that process/thread management came "free" by using
an apache handler. The publisher handler is clearly a powerful tool,
but I missed the OO view of WebWare. I looked at mod_python handlers
that are available in the opensource community, but found most
required a buy-in to their framework and/or content management system.
At some point I realized it would be VERY easy to implement the best
features of WebWare as a mod_python handler without the bloat and
management burdens of other systems. Best of all, it would be easy to
reuse many features of mod_python without re-inventing the wheel
(Session, Cookie, FieldStorage, etc.)
==================================================
1.5. Goals (which turns out to be a feature list)
==================================================
1. Using mod_python, write a handler that operates in much the same
way as WebWare: for any given request, create (or reuse) an
instance of a well-defined base class to process the request,
calling, in order, a set of methods on the instance.
2. Offer tools to manage much of the tedium of web programming:
processing query arguments and form variables. Mod_python
Servlets, building on mod_python.utils.FieldStorage, will
automatically create instance variables for query arguments and
form variables, allowing the developer to specify default values
if they don't appear in the request as well as conversion methods
to convert the strings to arbitrary python objects. In addition,
there is built-in support to accept python lists and dicts as
form variables. E.g., you can give HTML FORM elements names,
such as, "foo[a]", "foo[b]", "foo[c]", ... and have returned to
your servlet an instance variable named "foo", a dict, with keys
"a", "b", "c", ... and their values being whatever was specified
in the FORM. Likewise, naming FORM elements with the same name
(as with a CHECKBOX or SELECT with multiple set) Mod_python
Servlets can return a python list.
3. Allow for arbitrary methods of servlets to be called when forms
are submitted. With Mod_python Servlets you can name FORM BUTTON
and/or INPUT SUBMIT/BUTTON elements with a special syntax such
that when the form is submitted, a method the developer specifies
will be called. Security features are built-in to prevent *any*
method to be called, just those the developer specifies.
4. Remove the tedium of generating HTML documents. I HATE writing
HTML. Mod_python Servlets generates well-defined HTML documents
and through the setting of instance variables and/or overriding
base methods, offer the developer much flexibility in customizing
their HTML. When used with a tool like HyperText or HTMLgen, you
can write web applications without EVER having to write HTML.
5. Support basic HTTP authentication. Mod_python Servlets has tools
to manage HTTP authentication including a simple method that
accepts any mapping (that supports the standard get() method)
where keys are usernames and values are passwords.
6. Promote no framework that requires buy-in other than the servlets
themselves. Mod_python Servlets does not insist your content be
in a certain format or that you use any other third-party
packages. This is not a religious movement!
7. Make the management footprint small. The handler function and
one supporting class are less than 150 lines of code (after
stripping doc strings). The bulk of the functionality is in the
class hierarchy that represents a servlet.
8. Most importantly, separate processing from content. I loathe
PHP. By extension, mod_python PSP. If you, like me, have an
inbred need to separate code from content AND you thrive in an OO
view of the web, Mod_python Servlets are for you.
Re: Announcing: Mod_python Servlets
Posted by Nick <ni...@dd.revealed.net>.
David Fraser wrote:
>>> One thing that I can tell you right off the bat is that it will be much
>>> better received in the Python/Apache community if it were not released
>>> under the LGPL, but a less restrictive license, like the ASL, for
>>> example
>>
>> Possibly, but I haven't taken the time to consider the new Apache
>> license to know whether or not it's right for me. LGPL I know, and it
>> seemed to fit the PSE model (you can distribute your own compiled PSE
>> apps, but PSE itself must remain free).
>>
> Might be good to consider the wxWindows/wxWidgets license - its LGPL
> with the proviso that you can statically link the library.
> I guess it doesn't make that much difference in the Python case though...
The only thing LGPL restricts you from doing in this case is actually
freezing the PSE modules and distributing an apache binary with mod_python
and PSE built into a static binary. And I'm not even really sure that you'd
be restricted in that case, as long as you provided PSE in source form along
with it. Big deal. This seems like a really corner case, and if there
really was *that* much interest in the project, I would consider changing
the license.
For now, though, while it's still in what I would consider a "developmental"
state, I would like to see the source code remain free and open. I have a
personal interest in this project, and I wouldn't want someone to take it,
close it, and run with it, especially considering how nice GAI has been to
allow a once commercial product be open sourced.
Nick
Re: Announcing: Mod_python Servlets
Posted by David Fraser <da...@sjsoft.com>.
Nick wrote:
> Gregory (Grisha) Trubetskoy wrote:
>
>> One thing that I can tell you right off the bat is that it will be much
>> better received in the Python/Apache community if it were not released
>> under the LGPL, but a less restrictive license, like the ASL, for
>> example
>> ;-)
>
>
> Possibly, but I haven't taken the time to consider the new Apache
> license to know whether or not it's right for me. LGPL I know, and it
> seemed to fit the PSE model (you can distribute your own compiled PSE
> apps, but PSE itself must remain free).
>
> Nick
>
Might be good to consider the wxWindows/wxWidgets license - its LGPL
with the proviso that you can statically link the library.
I guess it doesn't make that much difference in the Python case though...
Re: Announcing: Mod_python Servlets
Posted by Nick <ni...@dd.revealed.net>.
Gregory (Grisha) Trubetskoy wrote:
> One thing that I can tell you right off the bat is that it will be much
> better received in the Python/Apache community if it were not released
> under the LGPL, but a less restrictive license, like the ASL, for example
> ;-)
Possibly, but I haven't taken the time to consider the new Apache license to
know whether or not it's right for me. LGPL I know, and it seemed to fit
the PSE model (you can distribute your own compiled PSE apps, but PSE itself
must remain free).
Nick
Re: Announcing: Mod_python Servlets
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Neat!
I'll try to make some time to look at it later...
One thing that I can tell you right off the bat is that it will be much
better received in the Python/Apache community if it were not released
under the LGPL, but a less restrictive license, like the ASL, for example
;-)
Grisha
On Tue, 25 May 2004, Nick wrote:
> Odd that this should be announced today as well, but I have been working on
> a commercial web product that uses mod_python for some time now, and
> recently I got all rights back to it and have been working toward making it
> available as open source software. I was just about to finish packaging it
> up when I read the announcement here, so here's something else to add to the
> mix. It is a combination template/servlet engine called the Python Servlet
> Engine (PSE).
>
> Instead of outlining the features, just visit the home page at
> http://nick.borko.org/pse where you can find the marketing hype (left over
> from commercial days), the user's manual, and the source. Feedback welcome.
>
> Nick
>
Re: Announcing: Mod_python Servlets
Posted by Nick <ni...@dd.revealed.net>.
Odd that this should be announced today as well, but I have been working on
a commercial web product that uses mod_python for some time now, and
recently I got all rights back to it and have been working toward making it
available as open source software. I was just about to finish packaging it
up when I read the announcement here, so here's something else to add to the
mix. It is a combination template/servlet engine called the Python Servlet
Engine (PSE).
Instead of outlining the features, just visit the home page at
http://nick.borko.org/pse where you can find the marketing hype (left over
from commercial days), the user's manual, and the source. Feedback welcome.
Nick
Re: Announcing: Mod_python Servlets
Posted by "Daniel J. Popowich" <dp...@mtrsd.k12.ma.us>.
Gregory (Grisha) Trubetskoy writes:
> My first suggestion would be add ASL as the license here so that
> it's ASL-licensed from the start.
I have placed it under Apache License, Version 2.0. A new package,
1.1.4, is available (the only difference from 1.1.3 is the license):
http://home.comcast.net/~d.popowich/mpservlets/
I have, however, retained the copyright for now.
Also, I've registered it with PyPI: http://www.python.org/pypi.
-d
Re: Announcing: Mod_python Servlets
Posted by Todd Grimason <to...@slack.net>.
* Daniel J. Popowich <dp...@mtrsd.k12.ma.us> [2004-05-27 10:18]:
>
> Todd Grimason writes:
> > > Other suggestions are most welcome.
> >
> > One thought - you might consider doing a quick/lite version of the
> > 'Hello World' of the Java J2EE world -- the Pet Store. Then sneak into
> > a few Java weblogs or community sites, leave some posts/flyers and
> > lure them in...
> >
> > Unless you consider all those Java-heads a lost cause. But then you're
> > directly/only competing with the other 45 Python web app kits.
>
> Since reading your email I've thought long and hard about "competing"
> with other python web app kits. Or, more accurately, what's my goal
> in wanting to contribute this to the mainstream mod_python
> distribution, for I certainly could have created yet another
> sourceforge project (YASP?) and beat the Servlet Drum elsewhere to
> stir up interest. Why am I taking this route?
Just wanted to clarify I meant no ill-will by the '45 Python web app
kits' comment -- I was just voicing a bit of
frustration/disappointment in that the field is so vast yet does not
seem to have many toolkits with more than a very small userbase.
Indeed, maybe a toolkit such as this could provide a strong foundation
for more-specific 'solutions' to be built on that could further the
whole modpy ball o' wax... Anyway, I'm looking forward to trying it
out...
--
___________________________
toddgrimason*todd@slack.net
Re: OT: web app kits Was: Announcing: Mod_python Servlets
Posted by "Michael C. Neel" <ne...@mediapulse.com>.
> Perhaps an easily accessible tutorial ("Hello, World!") would help,
> too. That's one reason I didn't want to publish without first putting
> together a fairly comprehensive tutorial: without it, Servlets are too
> hard to explain, with it, it looks like common sense (well, to someone
> familiar with OO).
>
Yes, I agree that while albatross has good reference documentation, it
lacks good tutorial documentation. A wiki was created to help this
problem at
http://www.object-craft.com.au/projects/albatross/wiki/ and there is
even a Hello World, but right now most of the examples posted focus on
the templates rather than the system as a whole.
> Interesting. Albatross is probably closer to Servlets than I ever
> expected. I hope you have the opportunity to go through my tutorial
> and I look forward to your informed opinion.
>
I work in the source code of Albatross alot, so I'll be spending time in
yours as well. It might just take me a week or so til I've got some
time to do more than browse though, but I will post my notes.
Mike
Re: OT: web app kits Was: Announcing: Mod_python Servlets
Posted by Daniel Popowich <dp...@mtrsd.k12.ma.us>.
Michael C. Neel writes:
>> On Thu, 2004-05-27 at 15:09, Daniel J. Popowich wrote:
>>
>
>>> > I did look at Albatross, albeit trivially. I was scared off almost
>>> > immediately by the templating and macros. I really, really, REALLY,
>>> > don't like coding web apps in that paradigm.
>
>>
>> If you took it to be like a psp or php system...
This is certainly the impression one gets (I got) when at the
Albatross home page. As I've already said, psp/php/asp/etc are not my
cup of tea, so I didn't go very deep in my exploration of it.
Perhaps an easily accessible tutorial ("Hello, World!") would help,
too. That's one reason I didn't want to publish without first putting
together a fairly comprehensive tutorial: without it, Servlets are too
hard to explain, with it, it looks like common sense (well, to someone
familiar with OO).
>>> > Also, it seemed to have
>>> > its own implementation of many features (sessions, for example) that
>>> > come out of the box with mod_python.
>
>>
>>
>> When albatross was started, mod_python didn't have session support
>> (at all), it's pretty new...Plus, albatross session support is much
>> more robut than mpd_python's...
Point well taken.
>>> > Here's a trivial difference: on
>>> > Albatross' homepage it says their system is under 2600 lines of code
>>> > according to pycount. Mine squeaks in just under 400 (the other
>>> > thousand being doc strings, comments and blank lines). Publisher is
>>> > 158, for comparison.
>
>>
>> I don't think this is relevant, because albatross offers much more
>> options that the other two...
You're right (mostly) that it's not relevant. HOWEVER, I was, in
part, poking fun at their own hubris. I quote the second paragraph on
their home page:
"In slightly less than 2600 lines of Python (according to pycount),
you get the following:"
Live by the sword, die by the sword, as they say. And yes, while
Albatross does offer more, that is, in part, my point. Many of these
web kit packages offer too much, in my opinion. I'm an ol' unix guy
that likes my tools to do one thing, and one thing well. If I need
more functionality I'll pipe it on to the next utility. (And yes, I
hate perl nearly as much as php.)
If I can offer Servlets-and-only-the-Servlets in 400 lines of code and
that's all one wants as the base-line of their toolkit, why use a
system with 6.5 times the code and functionality you never want.
My GOAL was to build something small and simple that can be the basic
building blocks of something larger.
>>> > Mod_python Servlets is small and has NO
>>> > requirements or expectations of the content. No filtering or content
>>> > processing at ALL. It is a framework for coding your apps. If you
>>> > choose to use the framework to filter/process macros in your content,
>>> > fine, but that is something you would build on top of Servlets.
>
>>
>> You can (though I don't know why you would) build an albatross system
>> that didn't ues any of the templating features. To give you an idea of
>> how it all works (something I really don't think you can get from the
>> site and docs sadly), here is the normal way I go about things, for say
>> a form to email submit:
>> ...
Interesting. Albatross is probably closer to Servlets than I ever
expected. I hope you have the opportunity to go through my tutorial
and I look forward to your informed opinion.
Cheers,
Daniel
Re: OT: web app kits Was: Announcing: Mod_python Servlets
Posted by "Michael C. Neel" <ne...@mediapulse.com>.
On Thu, 2004-05-27 at 15:09, Daniel J. Popowich wrote:
> I did look at Albatross, albeit trivially. I was scared off almost
> immediately by the templating and macros. I really, really, REALLY,
> don't like coding web apps in that paradigm.
If you took it to be like a psp or php system, it can be, but it's not
meant to be. I don't think you can avoid the need for matkup in the
templates, and you really will need some basic if login and loop
control. 98% of what I do is pull a set of rows from the database and
put them in an html table =p.
> Also, it seemed to have
> its own implementation of many features (sessions, for example) that
> come out of the box with mod_python.
When albatross was started, mod_python didn't have session support (at
all), it's pretty new. It's also not supported under apache 1.3, so if
like me you need to work in both 2.0 and 1.3 you don't want to have to
switch between methods.
Plus, albatross session support is much more robut than mpd_python's.
Albatross store the session client side in hidden fields, server side in
files, or even in a session server if the app is spread across multiple
servers, much like you would do with a database.
> Here's a trivial difference: on
> Albatross' homepage it says their system is under 2600 lines of code
> according to pycount. Mine squeaks in just under 400 (the other
> thousand being doc strings, comments and blank lines). Publisher is
> 158, for comparison.
I don't think this is relevant, because albatross offers much more
options that the other two. Besides the sessions I mentioned, it also
works for cgi, mod_python, fastcgi, and includes it's own httpd server
if you need to develop somewhere you don't have access a real server.
Also it contains a template engine, which you can extend with custom
tags.
> Mod_python Servlets is small and has NO
> requirements or expectations of the content. No filtering or content
> processing at ALL. It is a framework for coding your apps. If you
> choose to use the framework to filter/process macros in your content,
> fine, but that is something you would build on top of Servlets.
You can (though I don't know why you would) build an albatross system
that didn't ues any of the templating features. To give you an idea of
how it all works (something I really don't think you can get from the
site and docs sadly), here is the normal way I go about things, for say
a form to email submit:
First request hits mod_python. Here I will use mod_python to preform
any authentication and security checks. I know this is done outside of
the application, but I've come to prefer that over the years as the
outside code becomes very portable, and I'm more likely to code an
exploit in the app if I have to write it each time. It also makes it
easier to check/debug.
Next mod python has the job of setting up the Albatross app. This is
where the session preference is set, and also if I'm going to use a page
module scheme or a page object scheme, most the time I prefer page
objects (note that both of these handle more than one html page, usally
for me they handle all pages related to a section, like account
management screens). This is also where the database connection
(because there is always a database connection, lol) is checked/setup.
Last, I have some logic to decide which page ojbect will be used for
this request. Albatross can do this on it's own, but since my scheme is
simple (one object per directory type simple) I find it easier to do it
here and keep that code out of the app itself.
Next the app is run, which loads and executes the page object/module.
This is all python code, no templates. A java applet-like interface is
used, where page_enter, page_process, page_display, and page_exit
methods are called. We know from the http protocol that you reall can't
know all these phases, but Albatross abstracts them from this with it's
session management.
The only two I really use are display, and process. In process I look
at the request, check the fields, save the database or prepare some
data, send an email or two, or whatever action is needed. I update the
session with information about errors or what was done, like saving
"Message sent" or "that's not a real email address". Last, in process I
set the template to use to display the result, which can be a success
page or the same form they just came from if I need more/correct info.
Page display I use to load the template on disk, run it, and send the
results to the client. I also load up a set of macros to be used in the
template, but don't think of them as macros that do processing, they
really are closer to server side includes that contain the header,
footer, nave, etc. Each on of these is a separate file that the
designers can edit without involving me in any way.
Besides the above, I've also created some versions of the app that on an
error gather every scrape of data about the crash (env, traceback, point
in the template we were, session vars, etc) and send me an email which
taking the client to an oops.html page. I can easily switch between an
app the sends these, to one that doesn't, or from one session method to
another - my code lies in the page object after all.
I think the idea is the same between Albatross and Servlets, though the
implementations will differ. I think that's one of the advantages of
"45 web kits"; each one will take a different approach and we
(developers) end up with alot of choice - which I can never see as a bad
thing =P
>
> An uninformed assumption: if Mod_python Servlets pre-existed
> Albatross, they might have well used it as a building block for their
> system.
you'll have to ask the object craft guys that, lol.
Mike
Re: OT: web app kits Was: Announcing: Mod_python Servlets
Posted by "Daniel J. Popowich" <dp...@mtrsd.k12.ma.us>.
Michael C. Neel writes:
> > Fast forward a few years. I looked again at what was out there and
> > found most toolkits were still too "big" or required a "buy-in" to a
> > content form I was unwilling to make. I felt I was looking at someone
> > else's solution to a content management system rather than a toolkit
> > that allowed me to build my own. (Which is fine, of course, if what
> > you want is a solution, but a solution does not necessarily make for a
> > good toolkit.)
> >
>
> I'm curious if your looked at / tried Albatross and if so can you
> compare / contrast your system to it? I came to the same about some of
> the other options you mentioned, and your goals of a toolkit are very
> similar to mine, so would value your remarks about Albatross as it's
> what I've set up on.
I did look at Albatross, albeit trivially. I was scared off almost
immediately by the templating and macros. I really, really, REALLY,
don't like coding web apps in that paradigm. Also, it seemed to have
its own implementation of many features (sessions, for example) that
come out of the box with mod_python. Here's a trivial difference: on
Albatross' homepage it says their system is under 2600 lines of code
according to pycount. Mine squeaks in just under 400 (the other
thousand being doc strings, comments and blank lines). Publisher is
158, for comparison. Mod_python Servlets is small and has NO
requirements or expectations of the content. No filtering or content
processing at ALL. It is a framework for coding your apps. If you
choose to use the framework to filter/process macros in your content,
fine, but that is something you would build on top of Servlets.
An uninformed assumption: if Mod_python Servlets pre-existed
Albatross, they might have well used it as a building block for their
system.
OT: web app kits Was: Announcing: Mod_python Servlets
Posted by "Michael C. Neel" <ne...@mediapulse.com>.
> Fast forward a few years. I looked again at what was out there and
> found most toolkits were still too "big" or required a "buy-in" to a
> content form I was unwilling to make. I felt I was looking at someone
> else's solution to a content management system rather than a toolkit
> that allowed me to build my own. (Which is fine, of course, if what
> you want is a solution, but a solution does not necessarily make for a
> good toolkit.)
>
I'm curious if your looked at / tried Albatross and if so can you
compare / contrast your system to it? I came to the same about some of
the other options you mentioned, and your goals of a toolkit are very
similar to mine, so would value your remarks about Albatross as it's
what I've set up on.
I don't think I'll be switching anytime soon, but I think there is room
to share ideas and maybe help out each toolkit.
Mike
Re: Announcing: Mod_python Servlets
Posted by "Daniel J. Popowich" <dp...@mtrsd.k12.ma.us>.
Todd Grimason writes:
> > Other suggestions are most welcome.
>
> One thought - you might consider doing a quick/lite version of the
> 'Hello World' of the Java J2EE world -- the Pet Store. Then sneak into
> a few Java weblogs or community sites, leave some posts/flyers and
> lure them in...
>
> Unless you consider all those Java-heads a lost cause. But then you're
> directly/only competing with the other 45 Python web app kits.
Since reading your email I've thought long and hard about "competing"
with other python web app kits. Or, more accurately, what's my goal
in wanting to contribute this to the mainstream mod_python
distribution, for I certainly could have created yet another
sourceforge project (YASP?) and beat the Servlet Drum elsewhere to
stir up interest. Why am I taking this route?
My path to writing this handler was quite circuitous. Many years ago
I had a contracting gig to write some web apps. I wanted to use
python and so went looking for tools that offered more than cgi.
Mod_python was the first place I looked, but I found it too low-level
for my needs: it offered the mechanics for high(er)-speed
transactions, compared to cgi, but not much more than that.
Most other toolkits were the other extreme. Zope, for instance. Holy
Cow! What a monolith. Talk about having to buy-in to a framework. I
finally settled on WebWare. I used it and loved it, but eventually
grew frustrated with managing another server process, as per my
explanation in my README file.
Fast forward a few years. I looked again at what was out there and
found most toolkits were still too "big" or required a "buy-in" to a
content form I was unwilling to make. I felt I was looking at someone
else's solution to a content management system rather than a toolkit
that allowed me to build my own. (Which is fine, of course, if what
you want is a solution, but a solution does not necessarily make for a
good toolkit.)
This is when I decided to write my own handler, taking the best
features of WebWare. (I've also added many features that were NOT in
WebWare that I found useful in building web apps: tools for processing
query and form variables, for one example.)
Somewhere along the line it occurred to me that this handler fills a
void (IMHO) in the mod_python distribution. The publisher handler is
a step up from writing your own handler, but is still pretty
low-level. Servlets offer two abstractions, the Servlet class, which
remains pretty low-level it that's what you need and HTMLPage, a
higher level view of request handling with LOTS of goodies for
generating an HTML document. AND, unlike many other YASPs, does this
without promoting/requiring any particular content form or templating
system; there's a strong separation of code from content.
I think it's a good fit and can offer the distribution a higher-level
toolkit than it currently has available WITHOUT requiring a religious
movement, if you know what I mean.
Cheers,
Daniel
Re: Announcing: Mod_python Servlets
Posted by Nick <ni...@dd.revealed.net>.
Todd Grimason wrote:
> Unless you consider all those Java-heads a lost cause. But then you're
> directly/only competing with the other 45 Python web app kits.
I prefer to think of it as, "here's a toolkit that I've used and has worked
well for me. It's availabile if you find it useful, too." If someone uses
it and finds a bug to fix, hooray! If not, well that's less work for me.
Nick
Re: Announcing: Mod_python Servlets
Posted by Todd Grimason <to...@slack.net>.
* Daniel J. Popowich <dp...@mtrsd.k12.ma.us> [2004-05-26 15:58]:
>
> Gregory (Grisha) Trubetskoy writes:
> > This looks potentially interesting. I wonder what would be a good way to
> > get people to use this so you get some feedback...
>
> I've wondered that myself. My first attempt was writing the
> documentation and, more importantly, the tutorial, which can step
> developers through the features in a live demo. I don't know if
> you've seen it yet, but the tutorial has a link to show the source
> code (with color highlighting) for the servlet you are currently
> viewing. If folk take the time to go through the tutorial they will,
> hopefully, be surprised by how little code generates so much.
>
> I also plan on registering wit PyPI; that may catch some attention.
>
> Other suggestions are most welcome.
One thought - you might consider doing a quick/lite version of the
'Hello World' of the Java J2EE world -- the Pet Store. Then sneak into
a few Java weblogs or community sites, leave some posts/flyers and
lure them in...
Unless you consider all those Java-heads a lost cause. But then you're
directly/only competing with the other 45 Python web app kits.
--
___________________________
toddgrimason*todd@slack.net
Re: Announcing: Mod_python Servlets
Posted by "Daniel J. Popowich" <dp...@mtrsd.k12.ma.us>.
Gregory (Grisha) Trubetskoy writes:
> This looks potentially interesting. I wonder what would be a good way to
> get people to use this so you get some feedback...
I've wondered that myself. My first attempt was writing the
documentation and, more importantly, the tutorial, which can step
developers through the features in a live demo. I don't know if
you've seen it yet, but the tutorial has a link to show the source
code (with color highlighting) for the servlet you are currently
viewing. If folk take the time to go through the tutorial they will,
hopefully, be surprised by how little code generates so much.
I also plan on registering wit PyPI; that may catch some attention.
Other suggestions are most welcome.
> My first suggestion would be add ASL as the license here so that it's
> ASL-licensed from the start. Also, consider reworking the docs under the
> Python's documentation framework (it does require some LaTeX experience
> though ... :-( )
I'll do the ASL.
I've used LaTeX, but usually via LyX. The current documentation is
solely in doc strings. All the html and the pdf are generated by
epydoc, which processes the doc strings. Do you know of any tool to
assist with doc string to LaTeX macro translations?
> Other than that, I'll try to carve out some time in the next week
> (or few) to check this out...
Heck, took me three months of my copious free time to write the
documentation and tutorial; what's another week (or few)?
In the meantime, I'll apply the ASL and start looking at documentation
format changes.
Thanks,
Daniel
Re: Announcing: Mod_python Servlets
Posted by "Gregory (Grisha) Trubetskoy" <gr...@apache.org>.
Thanks Daniel.
This looks potentially interesting. I wonder what would be a good way to
get people to use this so you get some feedback...
My first suggestion would be add ASL as the license here so that it's
ASL-licensed from the start. Also, consider reworking the docs under the
Python's documentation framework (it does require some LaTeX experience
though ... :-( )
Other than that, I'll try to carve out some time in the next week (or few)
to check this out...
Grisha
On Tue, 25 May 2004, Daniel J. Popowich wrote:
>
> A few months ago I asked Grisha what was the best way to make a
> contribution of code to mod_python. He said I should post it to
> python-dev and then we'd take it from there.
>
> I felt I needed to write comprehensive documentation and put together
> a solid tutorial before posting the code. Nearly three months later,
> here I am.
>
> It can be downloaded from:
>
> http://home.comcast.net/~d.popowich/mpservlets/
>
> Below is a snippet from the README file included in the package. It
> gives an overview of the handler and its key functionality:
>
> Cheers,
>
> Daniel Popowich
>
> ----------------------------------------------------------------------
> Excerpt from README:
> ----------------------------------------------------------------------
>
> Mod_python Servlets
>
> ============
> 0. Preamble
> ============
>
> It is my intention to donate this handler to mod_python and by
> extension, the Apache Foundation. To this end, I have put together
> the handler, along with API reference documentation and a tutorial in
> the hopes that developers will use it and, finding it a simple, yet
> powerfully productive tool, use it in their projects, offer feedback
> and, eventually, promote its acceptance in the mainstream
> distribution.
>
>
> ============
> 1. Overview
> ============
>
> If mod_python's publisher handler is a functional view of the web, the
> servlet handler is an object oriented view of the web. It is inspired
> by WebWare (http://webware.sourceforge.net).
>
> I programmed with Webware for many projects. I loved the object
> oriented view of the web it promoted and found it to be a very
> productive tool to quickly prototype web applications. However, I
> found it lacking in a number of ways: 1) it has its own server process
> that needs to be started and managed, this is in addition to apache or
> another web server; 2) its class hierarchy is rather deep: there are
> five classes, inclusive, in the hierarchy between the base class and
> the class that represents an HTML page (there are only two in
> Mod_python Servlets); 3) even though a web server like apache manages
> processes and/or threads, WebWare has its own extensive thread
> management system which adds complexity to an overall web application;
> 4) WebWare promotes a comprehensive buy-in to their framework that,
> personally, I found unwieldy.
>
> In short, I found WebWare too "big" for my needs and started looking
> for something more streamlined. I couldn't find it.
>
> Since I never intended on using a web server other than apache, it
> made sense to give mod_python a closer look than I had before. It was
> immediately clear that process/thread management came "free" by using
> an apache handler. The publisher handler is clearly a powerful tool,
> but I missed the OO view of WebWare. I looked at mod_python handlers
> that are available in the opensource community, but found most
> required a buy-in to their framework and/or content management system.
>
> At some point I realized it would be VERY easy to implement the best
> features of WebWare as a mod_python handler without the bloat and
> management burdens of other systems. Best of all, it would be easy to
> reuse many features of mod_python without re-inventing the wheel
> (Session, Cookie, FieldStorage, etc.)
>
>
> ==================================================
> 1.5. Goals (which turns out to be a feature list)
> ==================================================
>
> 1. Using mod_python, write a handler that operates in much the same
> way as WebWare: for any given request, create (or reuse) an
> instance of a well-defined base class to process the request,
> calling, in order, a set of methods on the instance.
>
> 2. Offer tools to manage much of the tedium of web programming:
> processing query arguments and form variables. Mod_python
> Servlets, building on mod_python.utils.FieldStorage, will
> automatically create instance variables for query arguments and
> form variables, allowing the developer to specify default values
> if they don't appear in the request as well as conversion methods
> to convert the strings to arbitrary python objects. In addition,
> there is built-in support to accept python lists and dicts as
> form variables. E.g., you can give HTML FORM elements names,
> such as, "foo[a]", "foo[b]", "foo[c]", ... and have returned to
> your servlet an instance variable named "foo", a dict, with keys
> "a", "b", "c", ... and their values being whatever was specified
> in the FORM. Likewise, naming FORM elements with the same name
> (as with a CHECKBOX or SELECT with multiple set) Mod_python
> Servlets can return a python list.
>
> 3. Allow for arbitrary methods of servlets to be called when forms
> are submitted. With Mod_python Servlets you can name FORM BUTTON
> and/or INPUT SUBMIT/BUTTON elements with a special syntax such
> that when the form is submitted, a method the developer specifies
> will be called. Security features are built-in to prevent *any*
> method to be called, just those the developer specifies.
>
> 4. Remove the tedium of generating HTML documents. I HATE writing
> HTML. Mod_python Servlets generates well-defined HTML documents
> and through the setting of instance variables and/or overriding
> base methods, offer the developer much flexibility in customizing
> their HTML. When used with a tool like HyperText or HTMLgen, you
> can write web applications without EVER having to write HTML.
>
> 5. Support basic HTTP authentication. Mod_python Servlets has tools
> to manage HTTP authentication including a simple method that
> accepts any mapping (that supports the standard get() method)
> where keys are usernames and values are passwords.
>
> 6. Promote no framework that requires buy-in other than the servlets
> themselves. Mod_python Servlets does not insist your content be
> in a certain format or that you use any other third-party
> packages. This is not a religious movement!
>
> 7. Make the management footprint small. The handler function and
> one supporting class are less than 150 lines of code (after
> stripping doc strings). The bulk of the functionality is in the
> class hierarchy that represents a servlet.
>
> 8. Most importantly, separate processing from content. I loathe
> PHP. By extension, mod_python PSP. If you, like me, have an
> inbred need to separate code from content AND you thrive in an OO
> view of the web, Mod_python Servlets are for you.
>
>