Overview
Features
Download
Documentation
Community
Add-Ons & Services

HTTPRequestHandler Interface

General discussion regarding the development of POCO for contributors.
alex
Posts: 1204
Joined: 11 Jul 2006, 16:27
Location: United_States

HTTPRequestHandler Interface

Postby alex » 10 Feb 2007, 00:49

While working with classes derived from HTTPRequestHandler, I constantly find myself having to pass around request/response references. To avoid having many functions taking same arguments, I cache them in member variables (pointers) in handleRequest :

Code: Select all


void MyHandler::handleRequest(request, response)
{
  _pRequest = &request;
  _pResponse = &response;
  ...
}

and later retrieve references using

Code: Select all


HTTPServerRequest& MyRequestHandler::request()
{
  return *_pRequest;
}

and

Code: Select all


MyRequestHandler::response()
{
  return *_pResponse;
}

in similar fashion. I also do something like that with MyRequestHandler::form() - the only difference is that form() uses lazy creation like this:

Code: Select all


HTMLForm& MyRequestHandler::form()
{
  if (!_pForm)
  _pForm = new HTMLForm(request(), request().stream());

  return *_pForm;
}

My proposal is to push this functionality up the hierarchy into HTTPRequestHandler by adding:

- three private members:

Code: Select all


HTTPServerRequest* _pRequest;
HTTPServerResponse* _pResponse;
HTMLForm* _pForm;

- two public functions (called from

Code: Select all


HTTPServerConnection::run() prior to invoking
HTTPRequestHandler::handleRequest())

Code: Select all


void HTTPrequestHandler::setRequest(HTTPServerRequest&);
void HTTPrequestHandler::setResponse(HTTPServerResponse&);

- and following three protected member functions for descendant's convenience:

Code: Select all


HTTPServerRequest& HTTPrequestHandler::getRequest();
HTTPServerResponse& HTTPrequestHandler::getResponse();
HTMLForm& form();

From my own experience, this simplifies developer's life when writing handlers. If this is implemented, handleRequest() does not need arguments any more, but it does not hurt to keep it as is in oder not to break the existing code.

Alex

Return to “Contributors”

Who is online

Users browsing this forum: No registered users and 1 guest