At 11:41 AM 11/15/00 +1100, Richard Jones wrote:
> I hacked something together a while ago for my own project: you're
>welcome to hack at it if you want. I've attached it. It's not pretty and
>it's basic, but it worked for me. It handles packages and extracts
>docstrings and class/method signatures.
Cool. We'll give it a try.
> > Also, remember to run install.py in order to generate:
> > * class hierarchies
> > * alphabetical class lists
> > * class summaries
> > * highlighted source
> > All of which are HTML and linked to from the documentation pages of the
> > various components.
> Yep, that's helped somewhat. A big requirement is a simple explanation
>of how the classes are used to service a request.
The quick version goes like this:
The URL gets mapped to a servlet simply by name. If the URL names a
directory, then the directory is expected to have some kind of index.* or
Main.* file. Note that extensions could include .py for servlets, .psp for
Python Server Pages, .html, etc.
Your servlet is typically a subclass of Page and overrides methods like
writeHTML(), writeBody(), etc. You have access to:
which will be instances of HTTPRequest, HTTPResponse, Session, Application
and Transaction. The first three are the most commonly used. Check out
their class summaries and peruse the source for the doc strings.
Ultimately, your servlet will at some point invoke self.write() or
self.writeln() to generate content. print statements go to the console for
your debugging pleasure.
Unlike Zope, URL paths don't map to methods. They map to servlets which are
defined by Python classes.
Instantiation and caching are handled by the app server.
Hope that all helps.
> Acquisition is neat, but it's also very confusing sometimes and should
>definitely be made optional.
Just about everything is optional except for WebKit. This allows people to
embrace as much or as little as they like. It also allows you to provide
alternative implementations to components if you don't like the way they
were designed. An it encourages better modularity.
WebKit just serves servlets and provides hooks for extensions.
> What can respond() do? From reading the source, I'm still a little hazy
>on it :)
See above and let me know if that covers it.
> I like the idea of FolderKit (_especially_ over the ZODB :) - the mixing
>of source and resource in the one directory. And even having straight raw
>HTML or template HTML files in there would be an option. Nice :)
> What exactly did you envisage the properties being?
Properties are smaller things like strings, ints, etc. Perhaps your folder
keeps a list of FTP sites via properties.
It's not entirely clear to me that properties and objects should be
separate name spaces. They could be the same.
> This wouldn't necessarily solve my problem as I gather that any source
>in the folder would not result in any persistent objects - unless some
>specific mechanism was provided to do so. That is, given a directory of:
> class Wiki
> class WikiItem
> ... a PATH_INFO of .../Wiki/Wiki/Wiki would get you a handle to the wiki
>class, but what you'd really want is a handle to an instance so that there
>can be an in-memory database of the wiki. Or am I off track? :)
Not sure. Let me speak in WebKit terms again and you tell me if that covers
what you want.
Given your situation above, Wiki would be a subclass of Page. Upon seeing:
The WebKit app server would find your Wiki.py, load it, instantiate your
Wiki class and tell it to respond to a transaction. Mostly likely, you
would do this via writeHTML() or writeBody() as described above.
There is no access to WikiItem from a URL, unless you break it out into a
separate file, WikiItem.py. Certainly, your Wiki instance could make
WikiItems if it wanted to.
The app server handles threading, creating new instances, etc. But there is
no notion of persistance such that if you change an attribute of a Wiki
object, it will be shared by the others (which are serving other
simultaneous requests) or that it will be saved to disk. Frankly, I don't
think that's appropriate.
> > As far as PATH_INFO goes, if you want form fields and cookies you can do
> > like this from within a subclass of Page:
> > def writeBody(self):
> > req = self.request()
> > foo = req.field('foo')
> > bar = req.cookie('bar')
> The handling of PATH_INFO and the request arguments are two seperate
>problems. The PATH_INFO handling was nice because you don't have to encode
>actions in the request arguments and then manually deal with them. Given a
>definition of a WikiItem as:
> def edit(self):
> def editSubmit(self, text):
> def default(self):
> ... in Webware, this code would be needed:
> def writeBody(self):
> req = self.request()
> action = req.field('action')
> action = 'show'
> if action in ('edit', 'editSubmit', 'index'):
> name = req.field('name')
> item = self.wiki_items[name]
> if action == 'edit':
> return item.edit(foo)
> elif action == 'editSubmit':
> text = req.field(text)
> return item.editSubmit(text)
> elif action == 'show':
> return item.default()
> ... versus the following in an object publisher like Bobo. The 'default'
>method is called when the PATH_INFO is exhausted.
If you did it manually. Otherwise it would be:
return ['edit', 'editSubmit', 'index']
Assuming these came from form buttons, you would use the names in the HTML
tags that define the buttons. If from another source, then you would have
to put ?_action_=whatever on the URL. But in that case, I often have a
servlet for each one.
e.g., having one servlet that provides an editing page, a submission page
and an index is probably overload.