Webware for Python

On 3/24/07, Christoph Zwerschke <cito@...> wrote:
> One thing I always disliked about Webware is the static 404 error page.
...

Your proposal sounds good to me.

I just hope Webware is uber stable when we call it 1.0.

G'night,
-Chuck

Christoph Zwerschke wrote:
[snip]
> 
> Let me know whether you think this all makes sense before I will check 
> it in ;-)
> 

Very good idea, allowing declaration of a default error page will be
very useful.
May be it would be also interesting to allow the declaration of
HPPTErrorPage for application raised exceptions. For example:

     HTTPErrorPage = {
         'NotFound': '/Error404'
         'SessionExpired': '/Expired',
         'OneAppException': '/OneAppError',
         'OnotherAppException': '/AnotherAppError',
         'default': '/Error'
     }


Cheers,

JF

Jean-François Piéronne wrote:
> Very good idea, allowing declaration of a default error page will be
> very useful.
> May be it would be also interesting to allow the declaration of
> HPPTErrorPage for application raised exceptions. For example:
> 
>      HTTPErrorPage = {
>          'NotFound': '/Error404'
>          'SessionExpired': '/Expired',
>          'OneAppException': '/OneAppError',
>          'OnotherAppException': '/AnotherAppError',
>          'default': '/Error'
>      }

Makes sense to me. But in this case, we sould use another notation:

ErrorPage = {
     'HTTPNotFound': '/Error404'
     'HTTPSessionExpired': '/Expired',
     'OneAppException': '/OneAppError',
     'OnotherAppException': '/AnotherAppError',
     'HTTPException': '/HttpError',
     'Exception': '/Error'
}

'HTTPException' would be a catch-all for HTTP errors, 'Exception' for 
all other exceptions. The exception instance is stored in an "_error" 
attribute of the transaction so the servlet can examine it. There is 
already a Boolean attribute "_errorOccurred" which is actually only used 
for the activity log. We could replace that by def errorOccured(self): 
self._error is not None.

One question is whether we want to set errorOccurred also for HTTP 
exceptions. So far it is only set for other exceptions. Should we change 
that? If not, we need to def errorOccured(self): self._error is not None 
and not self._error.isinstance(HTTPException).

-- Chris

Chuck Esterbrook wrote:
> I just hope Webware is uber stable when we call it 1.0.

Right, actually I did not want to make larger changes before 1.0. But in 
this case, I had to make bigger changes in the mechanisms for forwarding 
and catching errors anyway, in order to fix the problems reported by 
Andrew Butash last month. I think I understand the details now very 
clearly and  implemented it in a much cleaner way that does not leave 
any servlet in limbo state, so it should have be more stable already.

Of course we still need to test 0.9.3 very thoroughly and fix any 
remaining or new bugs before 1.0.

-- Chris

I have now implemented and documented it that way in the trunk.

If ErrorPage is set to None or does not contain the raised exception, or 
if the response has already been commited, then it behaves as before.

-- Chris

Hi - It would be really nice to have the session store class and session 
classes fully configurable from the Application.config file. Currently 
Webware is limited to the included Memory/File/Dynamic setting which is 
translated into ("Session%sStore" % setting) and used to import the 
store. Then the session class is hard-coded as Session in the Application.

What do you think of having config settings for importing custom session 
stores and session classes for use by the app? I built a custom store 
for one application that happens to use MySQL as the back-end, coupled 
with a custom Session object, and I have to jump through some hoops to 
get the app to use them.

It could be as simple as four new config settings:

SessionStoreModule
SessionStoreClass
SessionModule
SessionClass

The Application object could do the same process it does now to import 
SessionXxxStore. Something like this (rough, untested):

CURRENT:
    # For session store:
    sessionStore = 'Session%sStore' % self.setting('SessionStore')
    exec 'from %s import %s' % (sessionStore, sessionStore)
    klass = locals()[sessionStore]
    assert isinstance(klass, ClassType) or issubclass(klass, Object)
    self._sessions = klass(self)

NEW:
    # For session store:
    exec 'from %s import %s' % (self.setting('SessionStoreModule'), 
self.setting('SessionStoreClass'))
    klass = locals()[self.setting('SessionStoreClass')]
    assert isinstance(klass, ClassType) or issubclass(klass, Object)
    self._sessions = klass(self)
    # For session class:
    exec 'from %s import %s' % (self.setting('SessionModule'), 
self.setting('SessionClass'))
    klass = locals()[self.setting('SessionClass')]
    self._session = klass

If there is interest in this, I can whip up a patch. I can include 
support for the current "SessionStore" param as well, rather than force 
a change to config files.

Thanks - Ben

Hi Ben,

I'm going to implement your patch, but I'd like to cut down the number 
of additional config settings. The number of parameters is already 
scaring enough ;-) What do you think about:

1) Assuming that the class name is always the same as the module name 
(this is also backward compatible and reduces confusion).

2) If the setting contains no dot, then try "Session%sStore" % setting,
if this fails or the name contains a dot, then use the name as is.

This way we can get on only with the old 'SessionStore' setting in a 
backward compatible way, plus one additional setting for the session 
module (and class).

Would this be ok for you?

-- Chris

Ben Parker wrote:
> Hi - It would be really nice to have the session store class and session 
> classes fully configurable from the Application.config file. Currently 
> Webware is limited to the included Memory/File/Dynamic setting which is 
> translated into ("Session%sStore" % setting) and used to import the 
> store. Then the session class is hard-coded as Session in the Application.
> 
> What do you think of having config settings for importing custom session 
> stores and session classes for use by the app? I built a custom store 
> for one application that happens to use MySQL as the back-end, coupled 
> with a custom Session object, and I have to jump through some hoops to 
> get the app to use them.
> 
> It could be as simple as four new config settings:
> 
> SessionStoreModule
> SessionStoreClass
> SessionModule
> SessionClass
> 
> The Application object could do the same process it does now to import 
> SessionXxxStore. Something like this (rough, untested):
> 
> CURRENT:
>     # For session store:
>     sessionStore = 'Session%sStore' % self.setting('SessionStore')
>     exec 'from %s import %s' % (sessionStore, sessionStore)
>     klass = locals()[sessionStore]
>     assert isinstance(klass, ClassType) or issubclass(klass, Object)
>     self._sessions = klass(self)
> 
> NEW:
>     # For session store:
>     exec 'from %s import %s' % (self.setting('SessionStoreModule'), 
> self.setting('SessionStoreClass'))
>     klass = locals()[self.setting('SessionStoreClass')]
>     assert isinstance(klass, ClassType) or issubclass(klass, Object)
>     self._sessions = klass(self)
>     # For session class:
>     exec 'from %s import %s' % (self.setting('SessionModule'), 
> self.setting('SessionClass'))
>     klass = locals()[self.setting('SessionClass')]
>     self._session = klass
> 
> If there is interest in this, I can whip up a patch. I can include 
> support for the current "SessionStore" param as well, rather than force 
> a change to config files.
> 
> Thanks - Ben

Yes that would work fine for our app.

Agreed about too many config settings - I thought about having the 
Session / SessionStore set through some kind of runtime configuration. 
Allow each context to set its own session/store combo perhaps? but that 
is a larger effort, and I didn't need that full solution. :)

Thanks for considering the patch, and thank you very much for your work 
on the Webware releases!

Regards - Ben

Christoph Zwerschke wrote on 4/5/07 8:50 AM:
> Hi Ben,
>
> I'm going to implement your patch, but I'd like to cut down the number 
> of additional config settings. The number of parameters is already 
> scaring enough ;-) What do you think about:
>
> 1) Assuming that the class name is always the same as the module name 
> (this is also backward compatible and reduces confusion).
>
> 2) If the setting contains no dot, then try "Session%sStore" % setting,
> if this fails or the name contains a dot, then use the name as is.
>
> This way we can get on only with the old 'SessionStore' setting in a 
> backward compatible way, plus one additional setting for the session 
> module (and class).
>
> Would this be ok for you?
>
> -- Chris
>
> Ben Parker wrote:
>   
>> Hi - It would be really nice to have the session store class and session 
>> classes fully configurable from the Application.config file. Currently 
>> Webware is limited to the included Memory/File/Dynamic setting which is 
>> translated into ("Session%sStore" % setting) and used to import the 
>> store. Then the session class is hard-coded as Session in the Application.
>>
>> What do you think of having config settings for importing custom session 
>> stores and session classes for use by the app? I built a custom store 
>> for one application that happens to use MySQL as the back-end, coupled 
>> with a custom Session object, and I have to jump through some hoops to 
>> get the app to use them.
>>
>> It could be as simple as four new config settings:
>>
>> SessionStoreModule
>> SessionStoreClass
>> SessionModule
>> SessionClass
>>
>> The Application object could do the same process it does now to import 
>> SessionXxxStore. Something like this (rough, untested):
>>
>> CURRENT:
>>     # For session store:
>>     sessionStore = 'Session%sStore' % self.setting('SessionStore')
>>     exec 'from %s import %s' % (sessionStore, sessionStore)
>>     klass = locals()[sessionStore]
>>     assert isinstance(klass, ClassType) or issubclass(klass, Object)
>>     self._sessions = klass(self)
>>
>> NEW:
>>     # For session store:
>>     exec 'from %s import %s' % (self.setting('SessionStoreModule'), 
>> self.setting('SessionStoreClass'))
>>     klass = locals()[self.setting('SessionStoreClass')]
>>     assert isinstance(klass, ClassType) or issubclass(klass, Object)
>>     self._sessions = klass(self)
>>     # For session class:
>>     exec 'from %s import %s' % (self.setting('SessionModule'), 
>> self.setting('SessionClass'))
>>     klass = locals()[self.setting('SessionClass')]
>>     self._session = klass
>>
>> If there is interest in this, I can whip up a patch. I can include 
>> support for the current "SessionStore" param as well, rather than force 
>> a change to config files.
>>
>> Thanks - Ben
>>     
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Webware-devel mailing list
> Webware-devel@...
> https://lists.sourceforge.net/lists/listinfo/webware-devel
>
>
>

Ok, this is now in the trunk if you want to check it out.

Ben Parker wrote:
> Agreed about too many config settings - I thought about having the 
> Session / SessionStore set through some kind of runtime configuration. 
> Allow each context to set its own session/store combo perhaps? but that 
> is a larger effort, and I didn't need that full solution. :)

Thanks, Chris. For purposes of these comments, I'm browsing svn rev 
6414. http://svn.w4py.org/Webware/trunk/WebKit/Application.py

The SessionStore initialization seems a bit more complicated than it 
needs to be. Rather than the for loop, and the prefix/suffix check, you 
can check if the setting is 'Memory', 'File', or 'Dynamic'. Otherwise 
everyone with a custom SessionStore needs to follow the SessionXxxxStore 
naming convention needlessly.

Here's the snippet from rev 6414 Application.py's initSessions(), 
updated to remove the for loop:

        sessionStore = self.setting('SessionStore')
        if sessionStore in ('Memory', 'File', 'Dynamic'):
                moduleName = className = 'Session' + sessionStore + 'Store'
        else:
                moduleName = sessionStore
                className = sessionStore.split('.')[-1]
        try:
                exec 'from %s%s import %s' % (moduleName, className)
        except ImportError:
                self._sessions = None
        else:
                try:
                        klass = locals()[className]
                        if not isinstance(klass, ClassType) \
                                        and not issubclass(klass, Object):
                                raise KeyError
                        self._sessions = klass(self)
                except KeyError:
                        print "ERROR: ", moduleName, " module" \
                                " does not contain class", className
                        self._sessions = None
        if self._sessions is None:
                print "ERROR: Session store not found!"


Regards - Ben

Christoph Zwerschke wrote on 4/5/07 3:41 PM:
> Ok, this is now in the trunk if you want to check it out.
>
> Ben Parker wrote:
>   
>> Agreed about too many config settings - I thought about having the 
>> Session / SessionStore set through some kind of runtime configuration. 
>> Allow each context to set its own session/store combo perhaps? but that 
>> is a larger effort, and I didn't need that full solution. :)
>>     
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Webware-devel mailing list
> Webware-devel@...
> https://lists.sourceforge.net/lists/listinfo/webware-devel
>
>
>

Ben Parker wrote:
> The SessionStore initialization seems a bit more complicated than it 
> needs to be. Rather than the for loop, and the prefix/suffix check, you 
> can check if the setting is 'Memory', 'File', or 'Dynamic'. Otherwise 
> everyone with a custom SessionStore needs to follow the SessionXxxxStore 
> naming convention needlessly.

That's why I had the loop, it checked first for SessionNameStore and 
then for Name only, so you could either follow the convention or use 
your own name. But you're right - I have reimplemented it as suggested 
for better compliance with the KISS principle. Looks much better now.

-- Chris