At 07:27 AM 3/9/2001 -0800, ender wrote:
>technically your right, i can do some of the above in a servlet factory
>interface, but i want more than just a page renderer. i want to build a
>publishing framework with various resources and transformations engines and
>its own custom caching serving up a variety of file types.
I still don't see why you couldn't do this with the current WebKit facilities.
If you have 3 or 4 extensions such as .xhtml, .xml, .xthis and .xthat, you
can provide servlet factories and custom servlet classes for each of them.
If they have things in common, you can provide an abstract servlet class to
Regarding resources, if you need to access related files, such as a
configuration file expected in the same directory, you can use the
serverSidePath() method of the request, which let's you quickly build
relative pathnames by passing in a path name to os.join() with:
filename = request.serverSidePath('config.dict')
Regarding custom caching, I believe Jay proved that this is doable when he
did so with PSP, although I don't think we have any docs on the topic.
Perhaps he can provide a few pointers.
> >>> i took a quick looksy through the webkit and code and noticed some
> >>> support for a paradigm that i think people could use to implement this
> >>> style of development in webware as well supporting general publishing
> >>> frameworks (ala apache cocoon). one key is the servlet chaining option
> >>> already builtin into webware. the other key, which i don't see and which
> >>> i' surmise doesn't exist from reading through the ipc9 paper, is the
> >>> ability to map servlets not to just file extensions but to whole
> >>> directory structures (including the root directory).
> >>Can you elaborate a bit on why you want to have a single servlet map to a
> >> whole directory? I guess I'm just not getting what you're trying to do.
>in a word, i want flexibility. a trivial example would be a servlet that maps
>to a directory of various file types and performs transformations on them,
>such as encoding html, txt, docbook into pdf via reportlab on the fly. more
That particular example can be done by turning ExtraPathInfo on, creating a
directory "foo" with a "Main.py" and putting the files in a subdir called
"resources/". Now when you get a URL like http://host.com/foo/baz, then
your Main.py can grab "baz" out of "resources/" and do what it likes with it.
Hmmm, if you wanted this to happen in your root, such as
http://host.com/baz, I'm not sure how you'd pull that off. I think you
could have a Main.py that forwards the request to a servlet in a subdir.
I'll consider the idea of a servlet handler for a given URL that takes
precedence over files in that directory. There are questions, like how do
we indicate that? Does it go "deep" into further URLs? etc. Kapil, if you
really want this, you should write a WEP.
Basically, WebKit's extension provisions are powerful, flexible and mature
enough that changes to them are going to be weighed carefully before
proceeding. Kind of like modifying Python. It already works great, so
changes have to be scrutinized.
>maybe these things are possible with the current ideology but, to me a
>centralized servlet handler is the most natural design. in the above external
>connection example i could implement a lot of location specific garbage code
>to perform the connections in several different servlets, but i lose out in
>terms of code resuse vs just checking for an existing resource.
As I mentioned above, having a "Main.py" by itself in a subdirectory gives
you a "servlet handler". You just have to put the other files in a subdir.
>very interesting, very cool. i vaguely remembering seeing this being
>discussed on the webware lists a few months ago. although this doesn't
>satisfy my requirements for directory handling of file extents, it does make
>a ZODB servlet a very real possiblity. i'm really beg. to like webware.
Well, it's about time! :-)
>sigh, i hope the above answered this question, if i really wanted my own
>templating language i could just as easily port dtml over to webware
>(ignoring licensing issues, its not nesc a bad idea since dtml is precompiled
>into callable objects which is speed up by being a c extension.). the only
>thing that needs to be done is constructing a variable namespace. but i'm not
>interested in YATL (yet another templating language), i want flexibility in
Actually, a DTML language that used  instead of <> wouldn't be such a bad
idea. My graphic design clients already use a custom templating language
somewhat akin to DTML and love it. Their biggest gripe is that like DTML,
their language uses <> so when they preview in Netscape they can't see
what's going on. Other than that, they are very happy.
I'm not really a fan of YATL either, but I do realize that non-Pythonic
people need _something_. Whether or not that is DTML-like or
XHMTL-attribute-based is something I haven't figured out yet.
Note that with the  delimited syntax there is _no_ issue of "such and
such tool won't view these files" or "such and such tool clobbers these
>"standard" is as "standard" does.
>the question is how easily webware can support my non "standard" desires.
>its not a matter of immeadiate solutions but what architectures can the
Well, we do our best, but every architecture has its pros and cons.
At this point, if you wanna push the directory-handler idea, a WEP is the
way to go. The idea seems powerful and interesting, but it's not on my list
of things to champion in the near future.