> Hey Sean,
>
>> Because of the call to begin()/commit(), it is very important that I
>> preserve the exact same SQL session as I descend from the controller
>> to the model. ?Because of the state-hiding nature of Wt, I don't know
>> how to ensure that my database connection gets handed back to the
>> connection pool at the end of the HTTP request. ?Thoughts on how best
>> to achieve this? ?-sc
>
> You are right. I think the appropriate solution would be to add a
> virtual method to WApplication (I am still thinking of a good name)
> that marks the end of a request (after event propagation _and_
> rendering) ?
Coming from an Apache background, let me push on this in a slightly
different direction and suggest Wt implement much of its existing
functionality in the form of request phases. In fact, I know that
having some of the below would help me out tremendously and it would
solve this resource acquisition/release question.
This is a variation of the way that Apache deals with request
handling, and while I never 100% liked the way that Apache handled
this, I think there's tremendous value in exposing parts of the HTTP
request cycle to the application. With Wt applications being compiled
and much of this work being resolved at compile time, I find the
following reasonably appealing. In an ideal world, I can see the
following virtual methods, some in WApplication, some in WServer:
1) a static WServer::preRead() - called before Boost::asio attempts a
read(2) call. Valid return values: READ. NO_READ, CLOSE.
2) a static WServer::postRead() - after Boost::asio completed a
read(2) call (regardless of partial read). Valid return values:
READ_MORE, NEXT, CLOSE.
3) a static WServer::headerPreParse() - Called before Wt parses HTTP
headers (i.e. has a buffer). Valid return values: READ_MORE, NEXT,
CLOSE.
4) a static WServer::headerPostParse() - Called after Wt parses HTTP
headers (i.e. has request structure w/ headers). This phase would
allow an application to rewrite its URI. Valid return values:
READ_MORE, NEXT, CLOSE.
5) a static WServer::lookupSession() - Lookup/set the sessionId for
the request. Valid return values: FOUND, NOT_FOUND, CLOSE.
6) a static WServer::lookupApp() - Looks up the appropriate
WApplication instance based on the above request handling (or creates
a new instance). Valid return values: FOUND, NOT_FOUND, CLOSE.
7) WApplication::checkAccess() - Checks request access via environment
of request (e.g. SSL vs plain text, IP address, time of day). Valid
return values: GRANTED, DENIED, CLOSE.
8) WApplication::checkAuthen() - Check the authentication credentials
(HTTP basic auth, cookie/token auth, etc). Valid return values:
GRANTED, DENIED, CLOSE.
9) WApplication::checkAuthz() - Checks whether or not the
authenticated user is permitted to access handler. Valid return
values: GRANTED, DENIED, CLOSE.
10) WApplication::findMimeType() - Find the right mime-type for the
response. Valid return values: FOUND, NOT_FOUND, CLOSE.
11) WApplication::fixupHandler() - A handler that exists for the
purpose of "fixing up" a request before the request handler is
called. Valid return values: NEXT, CLOSE.
12) WApplication::handler() - Generates the content. Valid return
values: OK, ERROR, CLOSE.
13) WApplication::log() - Generates the relevant logging information
(access logs, stats, etc). Like cleanup(), this function is always
called. Valid return values: OK, ERROR, CLOSE.
14) WApplication::cleanup() - Cleanup any misc resources - this
handler is called regardless of whether or not a response was short
circuited (e.g. if the user failed to authenticate and handler() was
never called, cleanup() would still be called). Valid return values:
OK, CLOSE.
Because much of this can be determined at compile time, I like the
idea of having hooks for each of these phases with predictable and
nominal runtime overhead. For example, in the case of:
class WApplication {
enum { NEXT = 0, CLOSE = 1 } fixup_type_t;
virtual fixup_type_t fixupHandler(...) { return NEXT; }
};
I know Wt already does most of this, but it's tucked away such that
it's programatically tedious to find the right place to modify a
request or to determine whether or not a given http request is
secured, already has a validated session, etc. Another example of how
this would be hugely beneficial, with a headerPostParse() method, I
could map a browser URL of "/signup" to "/#/signup" or "/ru/login" to
"/#/login" and set an HTTP header that sets the localization to use
(btw, is there a way to do the URI translation that I'm missing?).
Food for thought. -sc
PS I'm subscribed as a digest member and would benefit from being
directly included in the CC or To line.
--
Sean Chittenden
[email protected]
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
