Hey Sean,
2009/7/8 Sean Chittenden <[email protected]>:
>> 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.
I doubt the usefulness of such hooks in Wt. We would only like to
integrate those hooks which would be required because of specific
needs in a web application (compared to a simple desktop application),
and then I can only imagine features for:
- scalability reasons: to allow for a single point for clean-up of
temporary resources (like database connections) which you only need
during a request/response cycle. This is why I agree that a virtual
WApplication::endRequest() method is useful, in fact, we have
developed a database-like application where this would have been
useful too. A startRequest() is hardly useful since such resources
could easily initialize themselves when first used.
- support to break free from Wt's request/response cycle, in order to
complement a Wt application with simple servlet-like functionality.
Here, I would consider adding one virtual method handleRequest() to
WServer, which is called for every request/response that targets the
deployed application, whose default behavior is Wt's internal
controller, but which you then can reimplement to add custom
servlet-like handling for specific (non-Wt) requests.
I do not think there is need for URL rewriting since Wt does not
define how it uses URLs and form fields as these are considered
implementation details (except for the startup URL or the pretty-url
internal-path API). Also, authenticating requests to a particular
session is handled by Wt, giving you all the freedom for
application-level authentication logic inside the WApplication +
widgets, at a higher level of abstraction than the underlying
request/response cycle.
> 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?).
Wt will automatically map a browser URL of /signup to /#/signup ?
You only need to handle the URL when the user logs in to your
application (from your application constructor). There you are free to
interpret the URL in any way you want, and immediately call
setLocale("ru") ? Other url changes would correspond to internal path
changes. I could see possible improvements to the internal path API
(which could benefit from 'rewrite' logic), but these internal paths
are already quite distinct from the request/response cycle itself, and
perhaps this would address some of your needs ?
Regards,
koen
------------------------------------------------------------------------------
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
