Hi Román,
2011/2/25 Román González <[email protected]>:
> Now RequestBuilder, is implemented like this
> newtype RequestBuilder a = RequestBuilder (State RequestProduct a) deriving
> Monad
> data RequestProduct = RequestProduct {
> rqpParams :: Params
> , rqpFileParams :: Params
> , rqpHeaders :: Headers
> , rqpIsSecured :: !Bool
> } deriving (Show)
I assume this is the plan (current version doesn't look like this), and that
"rqpFileParams" should be "FileParams". That looks good to me -- it allows you
to specify the file parts declaratively and have a Request built out of that,
which is nice.
> Right now, I'm stuck on building the final multipart request body, specially:
>
> - Reading the contents of the files given by the developer on the Test API
I'm not sure I follow you here: what specifically is the problem?
> - Building Random Boundary values for the multipart request
I would say this is not especially important, I didn't bother in the blackbox
file upload tests for snap-server. If you really want to go with a
randomly-generated boundary, I suggest something like I did for the random
input in snap-server:
https://github.com/snapframework/snap-server/blob/master/test/suite/Test/Blackbox.hs#L213
That is, generate a bunch of random Word8 values and encode them as base-16.
> Probably the code could be better (or faster) by using a Builder on the
> multipart functions? I didn't use it given that I'm not familiar with the
> API and I wanted to have something done to show.
Builders are actually quite easy; just use the Builder Monoid instance. Where
you have:
S.concat [ "--"
, boundary
, "\r\n"
, "Content-Disposition: form-data; name=\""
, name
, "\"; filename=\""
, fName
, "\"\r\n"
, "Content-Type: "
, fileType defaultMimeTypes (S.unpack fName)
, "\r\n\r\n"
, fContent
, "\r\n"
]
Replace that with:
toByteString $
mconcat [ fromByteString "--"
, fromByteString boundary
....
]
If all you have is bytestring values, Builder will not actually be much more
efficient than S.concat (because S.concat is smart), but where you'll win is in
serializing things like Maps, etc; having:
mapToBuilder :: Map Foo Bar -> Builder
is guaranteed to be more efficient than turning the map into a bytestring and
then using "S.concat" to concat that string with other stuff, you'll save a
copy or two.
For testing code I don't think it matters much, performance is not paramount
there.
G
--
Gregory Collins <[email protected]>
_______________________________________________
Snap mailing list
[email protected]
http://mailman-mail5.webfaction.com/listinfo/snap
