Webware for Python

* There is a new 'Host' setting to complement the 'Port' setting in 
WebKit/Configs/AppServer.config. It defaults to 127.0.0.1. Originally we 
were using a blank host name, but some platforms (Windows and older 
FreeBSD) didn't like that.

* Fixed AdminPage's HTML. It was illegal and Navigator 4.7 wouldn't show 
the page at all.

* Renamed WebKit/cache/ to WebKit/Cache/ to match the case of other dirs. A 
subdir in Cache/ is created for each plug-in as they are loaded. PSP now 
puts its cached files in Cache/PSP/, for example.

* Jay tweaked sessions so that they are created only when asked for. This 
implies that in subclasses of Page, you should use self.session() and not 
self._session. For purposes of encapsulation and consistency, you should 
probably do the same for all attributes (e.g., use the methods).


-Chuck

Here is a summary of updates I have made last Friday and today.

* Moved KeyValueAccess from MiddleKit to MiscUtils and renamed it to 
NamedValueAccess. The move was due to the fact that KeyValueAccess turned 
out to be more generally useful than originally anticipated. The rename was 
appropriate given that valueForName() was the most popular method.

* There is a new sidebar/navigation bar for the examples. The previous top 
links and bottom links have been subsumed by this. The nav bar includes all 
the goodies like examples, contexts, exits, versions, etc. This was 
accomplished via the new SidebarPage class which both AdminPage and 
ExamplePage inherit. The new look is cleaner, more professional and, I 
think, easier to navigate.

* Created Adapter, a subclass of Configuration. Made OneShotAdapter a 
subclass thereof, with the others to follow. This is part of an adapter reorg.

* OneShotAdapter has a config file in Configs/. When capturing output, 
provided option to word wrap it so the table doesn't get so wide.

<boring>
* A 'transaction' global variable is passed into servlet scripts as a hook 
for the script to get information about the request that caused it to load. 
This should be rarely needed, especially with Jay's recent addition of 
__init__.py support of contexts, where you can do special initialization. 
But in general, hooks are a good thing if they don't clutter the code or 
mangle the architecture. So it's there.

* Added Testing/ to MiscUtils. Added TestDataTable.py.

* Changed Application's SessionTimeout to be expressed in minutes instead 
of seconds.

* Revamped Application's session sweeper method to be cleaner/tighter.
</boring>


For your review/understanding:

* The OneShot adapter loads everything (WebKit, plug-ins, contexts, the 
target servlet) once, serves the request and then exits. It is useful when:
	* developing web sites
	* developing WebKit and plug-ins
	* running in a CGI-like mode rather than an app server mode if you so desire

* NamedValueAccess is a useful mix-in class that allows you to query 
objects like: obj.valueForName("account.address.city"). Each field could be 
a method such as obj.account() or attribute such as obj.account or 
obj._account. The valueForName() method will follow the hierarchical dot 
notation through objects and dictionaries.

This kind of querying can be useful when setting up templates. It's also 
the basis for setting up the columns that get stored in the access log. The 
config file for Application stores these names and then runs through them 
with valueForName().

And there's even decent documentation embedded in the source file and a 
test suite to boot. I've also exercised this class in a few sites, so it's 
advertised feature set are stable.


On my short term radar:

[ ] FormKit/
[ ] Page: Add features for style sheets.
[ ] Handle unknown session ids with a specific page.
[ ] Fix ExamplePage to handle Plug-ins generically.
[ ] Add Last-modified: to generic files that get served up.
[ ] When I do a CVS co on FreeBSD, I get 'cache', but not 'Cache'
[ ] Disk based session storage.



Having lots of fun,

-Chuck

Nothing big:

* Fixed a bug in MiscUtils/DataTable.py regarding blank values. (Did that a 
couple days ago)

* Fixed bugs in OneShot.cgi & WebKit.cgi regarding HTML-encoding for 
exception reporting.


-Chuck

1. WebKit/Documentation/InstallGuide.html is finished. It's 31K and about 
12 pages when printed. Thanks to Geoff for IIS notes and Jay for app server 
notes.

2. WebKit/Future.html is pretty much updated.

3. Configurable.setting() now has an optional 'default' parameter, so you 
can do something like this:

	name = app.setting('Name', None)

If you don't specify a default, an exception is thrown when the named 
setting is not found. Configurable is a base class for Application, 
AppServer and OneShotAdapter.

4. NamedValueAccess.valueForKey() has always allowed a default value to be 
specified. However, it has now been tweaked so that it throws an exception 
(rather than returning None) when no default is specified. This matches all 
the other methods in Webware. NamedValueAccess is a base class for 
Application and is used in writing the activity log.

5. DocSupport/PySummary.py, which is used by install.py to generate HTML 
summaries of the Python files, no longer includes classes, methods and 
functions that start with a single underscore. This makes the summaries 
cleaner in some cases.


For releasing, the only outstanding items that I know of are:
   * cut a release candidate 2
   * PSP release notes


-Chuck

Added a new Application.config option "IgnoreInvalidSession" which, if
true, treats an expired or invalid session id the same as no session id,
instead of displaying an error message.

(Setting this option to 1 makes the SecurePage stuff I sent out
yesterday work more nicely, because if your session expires, you just
get asked to login again, and once you've logged in, you can pick up at
the same place in the web site where you left off, minus whatever values
you've saved in session variables.  Before making this change, the user
was confronted with an error page, then a login page, which seemed a bit
annoying.)

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

- I've fixed a problem in ThreadedAppServer that would cause it to
sometimes degenerate into a mode where it stops handling requests in a
timely manner.  This behavior could be provoked by hitting it with more
simultaneous requests than it could handle at once.
AsyncThreadedAppServer didn't need the fix.

(The gory details are that rhQueue was too small, causing the
RequestHandlers to block while attempting to insert themselves into
rhQueue in the RequestHandler.close() function.  I changed rhQueue to be
unlimited size, which is safe because it cannot grow beyond a fixed
bound anyway -- the number of threads plus the size of requestQueue plus
one, according to my analysis).

- I've fixed Application so that all servlet instances are properly
destroyed when the application exits.

- I've fixed a couple of bugs in ThreadedAppServerService for those of
us running WebKit as a service on WinNT.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

I checked in the COMKit plug-in.  If you want to use COM objects on
Windows in your servlets, you'll just need to set "EnableCOM" to 1 in
your AppServer.config file.  There is also a simple example of using ADO
for database access in servlets.

I also checked in the SecurePage example as a standard WebKit example.
This includes a fix for the "repeated login" problem that Dawn Stowers
reported yesterday.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

I made a bunch of improvements to the adapters and ThreadedAppServer:

- All adapters now inherit from Adapter base class, and the code to do
the marshaling and socket communications with the app server now lives
in Adapter.
- The adapters will now retry if they can't get to the app server
initially.  This is configurable.
- ThreadedAppServer is now smarter about how it handles the requestQueue
during shutdown, eliminating a source of hanging problems when the
request queue was full and the app server was stopped.
- On NT, ThreadedAppServerService now uses ThreadedAppServer instead of
a separate but mostly identical copy of the code.
- On NT, ThreadedAppServer now shuts down correctly when you use
Ctrl-C.  It appears that this fix won't work on Linux.

Note: I made the corresponding changes to FCGIAdapter but I can't test
it with my setup.  Someone who's using it, please give it a whirl.

Also, I haven't checked if AsyncThreadedAppServer would benefit from
these changes.

This stuff now looks rock solid on NT -- I can have 100 simultaneous
requests for non-trivial servlets going on, and I can stop and restart
the app server in the middle of handling the requests, and all the end
user notices is a bit of a delay while it restarts.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

I checked in XMLRPCServlet.py, a base class for servlets that act as
XML-RPC servers.

I also checked in XMLRPCExample.py, an example XML-RPC servlet.

If you need programmatic access to your WebKit server, this is a great
and easy way to do it.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

Geoff Talvola wrote:
> 
> I checked in XMLRPCServlet.py, a base class for servlets that act as
> XML-RPC servers.
> 
> I also checked in XMLRPCExample.py, an example XML-RPC servlet.

It's amazing to see how simple this is with WebKit.
B.t.W. This was on my personal wishlist :-)

> If you need programmatic access to your WebKit server, this is a great
> and easy way to do it.


class XMLRPCExample(ExamplePage, XMLRPCServlet):

if you do that you will get XMLRPC errors. Do you have
a simple example where this framework works as ExamplePage and
as XMLRPC server? The question is then, how a method
is either callable trough a browser (/add?var1=12&var2=23)
and trough a XMLRPC method call (server.add(var=12, var2=23)
and server.add(12,23))? Any hints?


-- 
Tom Schwaller
http://www.linux-community.de

Tom Schwaller wrote:

> Geoff Talvola wrote:
> >
> > I checked in XMLRPCServlet.py, a base class for servlets that act as
> > XML-RPC servers.
> >
> > I also checked in XMLRPCExample.py, an example XML-RPC servlet.
>
> It's amazing to see how simple this is with WebKit.
> B.t.W. This was on my personal wishlist :-)
>
> > If you need programmatic access to your WebKit server, this is a great
> > and easy way to do it.
>
> class XMLRPCExample(ExamplePage, XMLRPCServlet):
>
> if you do that you will get XMLRPC errors. Do you have
> a simple example where this framework works as ExamplePage and
> as XMLRPC server? The question is then, how a method
> is either callable trough a browser (/add?var1=12&var2=23)
> and trough a XMLRPC method call (server.add(var=12, var2=23)
> and server.add(12,23))? Any hints?

The XMLRPCServlet I checked in will only work for XML-RPC, not for browser
requests.  If you're willing to do a small amount of extra work, you can get
the effect you want, by implementing the function in a mixin class, then
creating two servlets that utilize the mixin class.  For example (untested):

class AdderMixin:
    def add(self, x, y):
        return x + y

class XMLRPCAdder(XMLRPCServlet, AdderMixin):
    def exposedMethods(self):
        return ['add']

class HTMLAdder(Page, AdderMixin):
    def writeBody(self):
        req = self.request()
        try:
            x = int(req.field('x'))
            y = int(req.field('y'))
        except:
            self.writeln('Your input was bad')
        else:
            self.writeln('The answer is <B>%d</B>' % (self.add(x, y)))

Or there may be some clever way to get one class to be able to respond to
either XMLRPC or regular browser requests.  I'll think about it.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

Geoff Talvola wrote:
> 
> Tom Schwaller wrote:
> 
> > Geoff Talvola wrote:
> > >
> > > I checked in XMLRPCServlet.py, a base class for servlets that act as
> > > XML-RPC servers.
> > >
> > > I also checked in XMLRPCExample.py, an example XML-RPC servlet.
> >
> > It's amazing to see how simple this is with WebKit.
> > B.t.W. This was on my personal wishlist :-)
> >
> > > If you need programmatic access to your WebKit server, this is a great
> > > and easy way to do it.
> >
> > class XMLRPCExample(ExamplePage, XMLRPCServlet):
> >
> > if you do that you will get XMLRPC errors. Do you have
> > a simple example where this framework works as ExamplePage and
> > as XMLRPC server? The question is then, how a method
> > is either callable trough a browser (/add?var1=12&var2=23)
> > and trough a XMLRPC method call (server.add(var=12, var2=23)
> > and server.add(12,23))? Any hints?
> 
> The XMLRPCServlet I checked in will only work for XML-RPC, not for browser
> requests.  If you're willing to do a small amount of extra work, you can get
> the effect you want, by implementing the function in a mixin class, then
> creating two servlets that utilize the mixin class.  For example (untested):
> 
> class AdderMixin:
>     def add(self, x, y):
>         return x + y
> 
> class XMLRPCAdder(XMLRPCServlet, AdderMixin):
>     def exposedMethods(self):
>         return ['add']
> 
> class HTMLAdder(Page, AdderMixin):
>     def writeBody(self):
>         req = self.request()
>         try:
>             x = int(req.field('x'))
>             y = int(req.field('y'))
>         except:
>             self.writeln('Your input was bad')
>         else:
>             self.writeln('The answer is <B>%d</B>' % (self.add(x, y)))

For a reduced API this is certainly the way to go, when you
have more methods it gets cumbersome..

> Or there may be some clever way to get one class to be able to respond to
> either XMLRPC or regular browser requests.  I'll think about it.

yeah, that's what I was thinking about too. Propably you
have code for something like

class XMLRPCPage(HTTPServlet):  

before I start my night session today :-) 
The class should have the funtionality of Page and XMLRPCServlet,
which unfortunately have both HTTPServlet as base class

class XMLRPCServlet(HTTPServlet): 
class Page(HTTPServlet):  

so one needs to factor out some of the XMLRPCServlet Code
into another Mixin class.

I have the feeling that you need extraURLPath
for a class beeing able to respond to either XMLRPC 
or regular browser requests. The circle is closing here :-)


B.T.W: How many methods should one expose in such a XMLRPCPage then? 
To many of them is not good memorywise I think. comments?



-- 
Tom Schwaller
http://www.linux-community.de

Tom Schwaller wrote:

> Geoff Talvola wrote:
> >
> > The XMLRPCServlet I checked in will only work for XML-RPC, not for browser
> > requests.  If you're willing to do a small amount of extra work, you can get
> > the effect you want, by implementing the function in a mixin class, then
> > creating two servlets that utilize the mixin class.  For example (untested):
> >
> > class AdderMixin:
> >     def add(self, x, y):
> >         return x + y
> >
> > class XMLRPCAdder(XMLRPCServlet, AdderMixin):
> >     def exposedMethods(self):
> >         return ['add']
> >
> > class HTMLAdder(Page, AdderMixin):
> >     def writeBody(self):
> >         req = self.request()
> >         try:
> >             x = int(req.field('x'))
> >             y = int(req.field('y'))
> >         except:
> >             self.writeln('Your input was bad')
> >         else:
> >             self.writeln('The answer is <B>%d</B>' % (self.add(x, y)))
>
> For a reduced API this is certainly the way to go, when you
> have more methods it gets cumbersome..

But the XML-RPC request needs to return data, while the browser request needs to
return the data formatted meaningfully for a user to view.  You'll have to write
some extra code anyway to format the output for the browser, so I don't see why
it's much more cumbersome to use separate servlets.

> > Or there may be some clever way to get one class to be able to respond to
> > either XMLRPC or regular browser requests.  I'll think about it.
>
> yeah, that's what I was thinking about too. Propably you
> have code for something like
>
> class XMLRPCPage(HTTPServlet):
>
> before I start my night session today :-)
> The class should have the funtionality of Page and XMLRPCServlet,
> which unfortunately have both HTTPServlet as base class
>
> class XMLRPCServlet(HTTPServlet):
> class Page(HTTPServlet):
>
> so one needs to factor out some of the XMLRPCServlet Code
> into another Mixin class.

Exactly.  You could put the stuff that's in XMLRPCServlet now into XMLRPCMixin,
then write

class XMLRPCServlet(HTTPServlet, XMLRPCMixin):

for use when you only want XMLRPC, and

class XMLRPCPage(Page, XMLRPCMixin):

for use when you want both.

> I have the feeling that you need extraURLPath
> for a class beeing able to respond to either XMLRPC
> or regular browser requests. The circle is closing here :-)

Yes, you could use the extraURLPath to determine which method to call in the web
browsing case.  But see my objections below.

> B.T.W: How many methods should one expose in such a XMLRPCPage then?
> To many of them is not good memorywise I think. comments?

I'm still not convinced it's a good idea to just go ahead and serve up the same
methods via XML-RPC and via web browsing.  First of all, in the web browsing case
you have to do extra work to format the data for the user, as I mentioned above
(or you could just format the data in some arbitrary way, I suppose, but what use
is that?).  Second, I think XML-RPC is stateless -- there are no cookies or other
state information that can be used to preserve sessions, unless you explicitly add
them as parameters in your XML-RPC methods.  So there's some incompatibility
there.  Finally, I see XML-RPC as a way of exposing a lower-level API for your
application to be controlled programmatically.  You don't _want_ to be exposing
that level for the user to see through their browser -- the browsing experience
should be prettier and higher-level.  So separating the XML-RPC and the web
browsing into separate servlets that make use of shared mixin for common
functionality seems like the right way to me.

Anyone else have any thoughts?

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

At 04:04 PM 12/15/2000 -0500, Geoff Talvola wrote:
>So separating the XML-RPC and the web
>browsing into separate servlets that make use of shared mixin for common
>functionality seems like the right way to me.
>
>Anyone else have any thoughts?

I think the exact same thing.


-Chuck

Geoff Talvola wrote:
> 
> Tom Schwaller wrote:
> 
> > Geoff Talvola wrote:
> > >
> > > The XMLRPCServlet I checked in will only work for XML-RPC, not for browser
> > > requests.  If you're willing to do a small amount of extra work, you can get
> > > the effect you want, by implementing the function in a mixin class, then
> > > creating two servlets that utilize the mixin class.  For example (untested):
> > >
> > > class AdderMixin:
> > >     def add(self, x, y):
> > >         return x + y
> > >
> > > class XMLRPCAdder(XMLRPCServlet, AdderMixin):
> > >     def exposedMethods(self):
> > >         return ['add']
> > >
> > > class HTMLAdder(Page, AdderMixin):
> > >     def writeBody(self):
> > >         req = self.request()
> > >         try:
> > >             x = int(req.field('x'))
> > >             y = int(req.field('y'))
> > >         except:
> > >             self.writeln('Your input was bad')
> > >         else:
> > >             self.writeln('The answer is <B>%d</B>' % (self.add(x, y)))
> >
> > For a reduced API this is certainly the way to go, when you
> > have more methods it gets cumbersome..
> 
> But the XML-RPC request needs to return data, while the browser request needs to
> return the data formatted meaningfully for a user to view.  You'll have to write
> some extra code anyway to format the output for the browser, so I don't see why
> it's much more cumbersome to use separate servlets.
> 
> > > Or there may be some clever way to get one class to be able to respond to
> > > either XMLRPC or regular browser requests.  I'll think about it.
> >
> > yeah, that's what I was thinking about too. Propably you
> > have code for something like
> >
> > class XMLRPCPage(HTTPServlet):
> >
> > before I start my night session today :-)
> > The class should have the funtionality of Page and XMLRPCServlet,
> > which unfortunately have both HTTPServlet as base class
> >
> > class XMLRPCServlet(HTTPServlet):
> > class Page(HTTPServlet):
> >
> > so one needs to factor out some of the XMLRPCServlet Code
> > into another Mixin class.
> 
> Exactly.  You could put the stuff that's in XMLRPCServlet now into XMLRPCMixin,
> then write
> 
> class XMLRPCServlet(HTTPServlet, XMLRPCMixin):
> 
> for use when you only want XMLRPC, and
> 
> class XMLRPCPage(Page, XMLRPCMixin):
> 
> for use when you want both.
> 
> > I have the feeling that you need extraURLPath
> > for a class beeing able to respond to either XMLRPC
> > or regular browser requests. The circle is closing here :-)
> 
> Yes, you could use the extraURLPath to determine which method to call in the web
> browsing case.  But see my objections below.
> 
> > B.T.W: How many methods should one expose in such a XMLRPCPage then?
> > To many of them is not good memorywise I think. comments?
> 
> I'm still not convinced it's a good idea to just go ahead and serve up the same
> methods via XML-RPC and via web browsing.  First of all, in the web browsing case
> you have to do extra work to format the data for the user, as I mentioned above
> (or you could just format the data in some arbitrary way, I suppose, but what use
> is that?).  Second, I think XML-RPC is stateless -- there are no cookies or other
> state information that can be used to preserve sessions, unless you explicitly add
> them as parameters in your XML-RPC methods.  So there's some incompatibility
> there.  Finally, I see XML-RPC as a way of exposing a lower-level API for your
> application to be controlled programmatically.  You don't _want_ to be exposing
> that level for the user to see through their browser -- the browsing experience
> should be prettier and higher-level.  So separating the XML-RPC and the web
> browsing into separate servlets that make use of shared mixin for common
> functionality seems like the right way to me.

Somehow I viewed Zope as a model here, 
but I completely agree with the above statement.
      
With Zope you get everything (in this case XML-RPC) 
for free, but you pay performancewise for the overhead,
which in most cases you just don't need (I always wrote
spezial Zope-Methods to be used by XML-RPC, but you can 
call all other methods by XML-RPC too, which gives no sense
in most of the cases, because you get plain (useless) HTML..).


> Anyone else have any thoughts?


-- 
Tom Schwaller
http://www.linux-community.de

Fixed a bug in COMKit that was caused by the new Properties.py stuff.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

Fixed a bug in ModPythonAdapter.py -- it was prepending two newlines to the content, which is OK for HTML, but was causing binary files such as images to break.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

Fixed the bug in OneShotAdapter that Chuck reported earlier, and also fixed a circular reference problem in OneShotAdapter that was preventing __del__ from being called on Servlets.  (Although it might not be such a great idea to rely on __del__ in a Servlet.)

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

This is absolutely, positively, the last CVS update message you'll get from me today.

I fixed the truncated response problem using ThreadedAppServer.  As far as I can tell, the tip of CVS now works perfectly.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

Geoff Talvola wrote:

> Fixed the bug in OneShotAdapter that Chuck reported earlier, and also fixed a circular reference problem in OneShotAdapter that was preventing __del__ from being called on Servlets.  (Although it might not be such a great idea to rely on __del__ in a Servlet.)

Now I am really confused.  Which is it supposed to be? Is
transaction.response().rawResponse() supposed to be a string or a dictionary?

Oh well. It seems to be working now.  Sorry, Jay, about the bad bugfix.

Terrel Shumway wrote:

> Geoff Talvola wrote:
>
> > Fixed the bug in OneShotAdapter that Chuck reported earlier, and also fixed a circular reference problem in OneShotAdapter that was preventing __del__ from being called on Servlets.  (Although it might not be such a great idea to rely on __del__ in a Servlet.)
>
> Now I am really confused.  Which is it supposed to be? Is
> transaction.response().rawResponse() supposed to be a string or a dictionary?
>
> Oh well. It seems to be working now.  Sorry, Jay, about the bad bugfix.

It looks like OneShotAdapter was modified assuming that rawResponse() returned a string, but rawResponse hasn't been modified yet, so I had to revert OneShotAdapter's response code back to the way it was before, where it expects a dictionary.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

Thanks, that one was hiding.  I added one more fix in ModPythonAdapter.  
Also, FCGIAdapter should work now, while it might not have before.

Jay


Geoff Talvola wrote:

> This is absolutely, positively, the last CVS update message you'll get from me today.
> 
> I fixed the truncated response problem using ThreadedAppServer.  As far as I can tell, the tip of CVS now works perfectly.
> 
> --
> 
> 
> - Geoff Talvola
>   Parlance Corporation
>   gtalvola@...
> 
> 
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> http://lists.sourceforge.net/lists/listinfo/webware-discuss

Your fix was fine.  It returns a string. 

For now. ;)

Jay


Terrel Shumway wrote:

> Geoff Talvola wrote:
> 
>> Fixed the bug in OneShotAdapter that Chuck reported earlier, and also fixed a circular reference problem in OneShotAdapter that was preventing __del__ from being called on Servlets.  (Although it might not be such a great idea to rely on __del__ in a Servlet.)
> 
> 
> Now I am really confused.  Which is it supposed to be? Is
> transaction.response().rawResponse() supposed to be a string or a dictionary?
> 
> Oh well. It seems to be working now.  Sorry, Jay, about the bad bugfix.
> 
> 
> 
> 
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> http://lists.sourceforge.net/lists/listinfo/webware-discuss

Sorry, I misspoke.  The confusion is that OneShot is doing thimngs 
differently than normal adapters.  In the ModPythonAdapter,  you are 
getting back a string, but one shot is conected directly to the 
appserver, and isn'tr calling Adapter.TransactWithAppServer, it's 
calling response.rawResponse(), which returns a dictionary.  I broke 
OneShot by forgetting this.

Jay


Terrel Shumway wrote:

> Geoff Talvola wrote:
> 
>> Fixed the bug in OneShotAdapter that Chuck reported earlier, and also fixed a circular reference problem in OneShotAdapter that was preventing __del__ from being called on Servlets.  (Although it might not be such a great idea to rely on __del__ in a Servlet.)
> 
> 
> Now I am really confused.  Which is it supposed to be? Is
> transaction.response().rawResponse() supposed to be a string or a dictionary?
> 
> Oh well. It seems to be working now.  Sorry, Jay, about the bad bugfix.
> 
> 
> 
> 
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> http://lists.sourceforge.net/lists/listinfo/webware-discuss

Fixed PSP class name generation -- now all non-alphanumeric characters are converted to underscores; before, if the path of your PSP included something like a "~" it would break.

Also, fixed ThreadedAppServer and AsyncThreadedAppServer so that if a header is set to something other than a string (for example, setting "Status" to an integer) it works properly.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

At 06:10 PM 2/6/2001 -0500, Geoff Talvola wrote:
>Fixed PSP class name generation -- now all non-alphanumeric characters are 
>converted to underscores; before, if the path of your PSP included 
>something like a "~" it would break.

I think it would be safer to replace non-alphanumeric characters with their 
hex code equivalent so that if two different PSP pages had non-alphanumeric 
characters in the same position, they wouldn't clobber each other.

If the character is in a variable c, then hex(ord(c))[2:] does the trick. 
At least on Python 2.0; I don't know how old hex() is.

Even that isn't guaranteed, but it's probably in the realm of "will never 
really happen".

Perhaps an ultimate solution would be to create truly unique names and a 
dictionary mapping path to class name.


Some thoughts for the PSP guys,
-Chuck

Chuck Esterbrook wrote:

> At 06:10 PM 2/6/2001 -0500, Geoff Talvola wrote:
> >Fixed PSP class name generation -- now all non-alphanumeric characters are
> >converted to underscores; before, if the path of your PSP included
> >something like a "~" it would break.
>
> I think it would be safer to replace non-alphanumeric characters with their
> hex code equivalent so that if two different PSP pages had non-alphanumeric
> characters in the same position, they wouldn't clobber each other.
>
> If the character is in a variable c, then hex(ord(c))[2:] does the trick.
> At least on Python 2.0; I don't know how old hex() is.
>
> Even that isn't guaranteed, but it's probably in the realm of "will never
> really happen".
>
> Perhaps an ultimate solution would be to create truly unique names and a
> dictionary mapping path to class name.
>
> Some thoughts for the PSP guys,
> -Chuck

This change sounds like a good idea, but it would make the tracebacks you get from a PSP error even more confusing than they are already.  So I'd recommend switching to a new naming strategy for the PSP classes at the same time we fix the PSP error reporting.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

At 06:31 PM 2/6/2001 -0500, Geoff Talvola wrote:
>This change sounds like a good idea, but it would make the tracebacks you 
>get from a PSP error even more confusing than they are already.  So I'd 
>recommend switching to a new naming strategy for the PSP classes at the 
>same time we fix the PSP error reporting.

Then I would recommend:
   - replacing non-alphanumerics with underscores
   - attaching a unique id to the end of the class name
   - using a dictionary to map PSP paths to their corresponding class names

This could probably be done separate from the error reporting.

BTW do you guys have any idea how we're going to fix the PSP line numbers 
in tracebacks?

-Chuck

I do not think this is possible, and I don't really see the need. 
If you can't figure out from the servlet class where that function is in 
your PSP source, then you've got too much python in your psp.  I think. ;)

Jay


Chuck Esterbrook wrote:

> 
> BTW do you guys have any idea how we're going to fix the PSP line 
> numbers  in tracebacks?
> 
> -Chuck
>

Anything is possible -- this is Python after all :-)

You could embed special comments in your generated Python file that refer to the line number in the PSP file.  For example, you could append "### Line <linenum>" to the end of each line in the generated file.  Then wrap the whole thing in a custom exception handler that looks at the line in the generated servlet that caused the error, parses the line number, and then dumps out the line number and contents of the corresponding line in the PSP file.

You might not think this is needed, but I've found myself making boneheaded errors in my PSP and wishing for this feature...

Jay Love wrote:

> I do not think this is possible, and I don't really see the need.
> If you can't figure out from the servlet class where that function is in
> your PSP source, then you've got too much python in your psp.  I think. ;)
>
> Jay
>
> Chuck Esterbrook wrote:
>
> >
> > BTW do you guys have any idea how we're going to fix the PSP line
> > numbers  in tracebacks?
> >
> > -Chuck
> >

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

There's one other aspect of PSP error reporting that bothers me that should be really easy to fix:

The generated PSP classes look like:

#####
try:
 import BaseClass
except:
 pass

class _My_PSP_Page(BaseClass.BaseClass):
...
#####

This means that if there's some error in importing BaseClass, you get a NameError in the class definition, instead of getting a traceback from "import BaseClass" which would be much more useful.

I think that we should remove the try-except-pass around "import BaseClass", but maybe there's some reason for the try-except-pass that I can't think of.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

I had the same idea.

I'll add it to my todo list.

Jay



On 07 Feb 2001 11:21:24 -0500, Geoff Talvola wrote:
> Anything is possible -- this is Python after all :-)
> 
> You could embed special comments in your generated Python file that refer to the line number in the PSP file.  For example, you could append "### Line <linenum>" to the end of each line in the generated file.  Then wrap the whole thing in a custom exception handler that looks at the line in the generated servlet that caused the error, parses the line number, and then dumps out the line number and contents of the corresponding line in the PSP file.
> 
> You might not think this is needed, but I've found myself making boneheaded errors in my PSP and wishing for this feature...
> 
> Jay Love wrote:
> 
> > I do not think this is possible, and I don't really see the need.
> > If you can't figure out from the servlet class where that function is in
> > your PSP source, then you've got too much python in your psp.  I think. ;)
> >
> > Jay
> >
> > Chuck Esterbrook wrote:
> >
> > >
> > > BTW do you guys have any idea how we're going to fix the PSP line
> > > numbers  in tracebacks?
> > >
> > > -Chuck
> > >
> 
> --
> 
> 
> - Geoff Talvola
>   Parlance Corporation
>   gtalvola@...
> 
> 
> _______________________________________________
> Webware-discuss mailing list
> Webware-discuss@...
> http://lists.sourceforge.net/lists/listinfo/webware-discuss

I fixed a somewhat obscure bug in HTTPRequest.py that caused an exception when POSTing data that didn't come from an HTML form (one example is an XML-RPC request which contains XML-encoded parameters instead of URL-encoded parameters like a regular form POST).  This error only happens in Python 2.0, not in Python 1.5.2, due to a change in the way that the FieldStorage class in the cgi module works between 1.5.2 and 2.0.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

I checked in a fix to the PSP multiple inheritance.  The Hello.psp example page uses a construct like the following:

<%@ page imports = "Examples:ExamplePage"%>
<%@ page extends="ExamplePage"%>

where Examples is a package name, and ExamplePage is the name of a module as well as the name of the class within the module.  But it could easily be the case that Examples.py is a module, and ExamplePage is the class within that module.  PSP can't tell which is the case at the time it generates the servlet, so I've fixed it so that the generated code actually checks the type of ExamplePage at runtime when the servlet is first imported, and if it's a module, it uses ExamplePage.ExamplePage as the base class, otherwise it uses ExamplePage as the base class.  This works correctly for all cases that I could think of.

--


- Geoff Talvola
  Parlance Corporation
  gtalvola@...

New setting 'ReportRPCExceptionsInWebKit': 1 means report exceptions in RPC
servlets in the same way as exceptions in other servlets, i.e. in the
logfiles, the error log, and/or by email. 0 means don't report the
exceptions on the server side at all; this is useful if your RPC servlets
are raising exceptions by design and you don't want to be notified. Note
that in release 0.7, there was no exception reporting on the server side in
RPC servlets; if you want to get the same behavior in this release you'll
have to set this setting to 0.

- Geoff