Proposal for a change to the Request interface

32 views
Skip to first unread message

ebr...@pogoapps.com

unread,
Jun 18, 2013, 11:32:27 AM6/18/13
to google-s...@googlegroups.com
I would like to propose a change to the latest version of Sitebricks regarding the Request interface.

A pull request on Github was recently accepted that changed the Request interface into a generic class. The class type that you parametrize Request to will be the type of the *HTTP parameter*. This seemed odd because an HTTP parameter is nothing more than a simple String. If anything, the type parametrization on Request should be for the request body itself, not the parameter type.

For example, Request<Foo> will not represent an HTTP request of the type Foo, but rather that the parameters of the request itself are of the type Foo. If you want to convert the request body to Foo, then you need to use Request<String> instead. This results in Request<String> being used everywhere that Request was formerly used. This seems redundant to me.

I discussed this change with Dhanji, the project owner, and he agrees that the Request interface should be brought back to its original state. The conversion of HTTP parameters should be done by the users of Sitebricks, not by Sitebricks itself.

I will submit a pull request on Github shortly. Please feel free to comment and debate to your heart's content in this thread.

Eric Charles (GMail)

unread,
Jun 18, 2013, 12:07:34 PM6/18/13
to google-s...@googlegroups.com
Hi,

I needed the generic to make the MutliParRequest implementation possible
(I mean easy to implement reusing the FormFile class, without
remplementing is sitebricks the full parsing of a multipart/form-data
HTTP request).

Also, reading the javadoc of the Request class [2], I may have been
confident that it was opened to any other abstraction.

"Sitebricks abstraction of a request. May be a standard HTTP request, a
tunneled Sitebricks RPC-over-HTTP, or another abstraction entirely."

Maybe you will find a way to support the FormFile without generics?
The other option is to simply drop that support, but is going backwards
IMHO.

Thx, Eric


[1]
https://github.com/dhanji/sitebricks/blob/master/sitebricks-extensions/src/main/java/com/google/sitebricks/transport/MultiPartRequest.java

[2]
https://github.com/dhanji/sitebricks/blob/master/sitebricks/src/main/java/com/google/sitebricks/headless/Request.java
Reply all
Reply to author
Forward
0 new messages