- 22 9月, 2015 3 次提交
-
-
由 Aaron Patterson 提交于
We should be asking the mime type method for the mime objects rather than via const lookup
-
由 Aaron Patterson 提交于
We don't want to manage a list of constants on `Mime::`. Managing constants is strange because it will break method caches, not to mention looking up by a constant could cause troubles. For example suppose there is a top level constant `HTML`, but nobody registers the HTML mime type and someone accesses `Mime::HTML`. Instead of getting an error about how the mime type doesn't exist, instead you'll get the top level constant. So, instead of directly accessing the constants, change this: Mime::HTML To this: Mime::Type[:HTML]
-
由 Aaron Patterson 提交于
Now we don't have to look it up with a `const_get`.
-
- 21 9月, 2015 2 次提交
-
-
由 Harry V. Kiselev 提交于
forgotten end of the block
-
由 Akira Matsuda 提交于
-
- 19 9月, 2015 14 次提交
-
-
由 Ronak Jangir 提交于
-
由 Aaron Patterson 提交于
This can still be added to the middleware stack, but is really not necessary. I'll follow up with a commit that deprecates the constant
-
由 Aaron Patterson 提交于
all parameter parsing is done on the request object now, so we don't need to worry about at ParamParser middleware
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
The test request object will handle parsing XML posts now, so we don't need to eagerly parse them in the test harness
-
由 Aaron Patterson 提交于
The request object will automatically parse these in the `parse_formatted_parameters` method, so we don't have to worry about it.
-
由 Aaron Patterson 提交于
This is an instance method on the request object now so we don't need it anymore
-
由 Aaron Patterson 提交于
we don't actually need a param parser middleware instance since the request object will take care of parsing parameters for us. For now, we'll just configure the parameter parsers on the request in this class.
-
由 Aaron Patterson 提交于
The middleware stack is a singleton in the application (one instance is shared for the entire application) which means that there was only one opportunity to set the parameter parsers. Since there is only one set of parameter parsers in an app, lets just configure them on the request class (since that is where they are used).
-
由 Aaron Patterson 提交于
Parameters will not be parsed until they are specifically requested via the `request_parameters` method.
-
由 Aaron Patterson 提交于
we need to be more specific about exception handling when dealing with the parse strategies. The calls to `return yield` can also raise an exception, but we don't want to handle that in *this* code.
-
由 Aaron Patterson 提交于
`normalize_encode_params` is common to all parser code paths, so we can pull that up and always apply it before assigning the request parameters
-
由 Aaron Patterson 提交于
since there is only one "default" strategy now, we can just use the block parameter for that.
-
由 Aaron Patterson 提交于
All parameter parsing should be on the request object because the request object is the object that we ask for parameters.
-
- 18 9月, 2015 1 次提交
-
-
由 Akira Matsuda 提交于
-
- 16 9月, 2015 1 次提交
-
-
由 Juanito Fatas 提交于
-
- 15 9月, 2015 8 次提交
-
-
由 Aaron Patterson 提交于
this commit removes some direct access to `env`.
-
由 Aaron Patterson 提交于
This commit is to abstract the code away from the env hash. It no longer needs to have the routes key hard coded.
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
This changes the renderer class to store the controller and defaults as an instance variable rather than allocating a new class. You can create a new renderer with an new env by calling `Renderer#new` or use new defaults by calling `Renderer#with_defaults` and saving the return value somewhere. Also I want to keep the `env` private since I would like to change the keys in the future. This commit only translates particular keys that the user requested.
-
由 Aaron Patterson 提交于
this means the reader doesn't need to lock, but does have the added cost of a new object created for every controller
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
The controller class is shared among threads, so we need to lock when allocating the Renderer.
-
由 Aaron Patterson 提交于
-
- 14 9月, 2015 1 次提交
-
-
由 Pedro Nascimento 提交于
-
- 11 9月, 2015 1 次提交
-
-
由 claudiob 提交于
AC::Parameters does not inherit from HashWithIndifferentAccess since #20868 by @sikachu
-
- 09 9月, 2015 9 次提交
-
-
由 eileencodes 提交于
`Rack::Session::Abstract::ID` is now deprecated and `Rack::Session::Abstract::Persisted` should be used instead.
-
由 eileencodes 提交于
In c546a2b0 this was changed to mimic how the browser behaves in a real situation but left out types that were registered. When this was changed it didn't take `text/plain` or `text/html` content types into account. This is a problem if you're manipulating the `Content-Type` headers in your controller tests, and expect a certain result. The reason I changed this to use `to_sym` is because if the `Content-Type` is not registered then the symbol will not exist. If it's one of the special types we handle that specifically (:json, :xml, or :url_encoded_form). If it's any registered type we handle it by setting the `path_parameters` and then the `request_parameters`. If the `to_sym` returns nil an error will be thrown. If the controller test sets a `Content-Type` on the request that `Content-Type` should remain in the header and pass along the filename. For example: If a test sets a content type on a post ``` @request.headers['CONTENT_TYPE'] = 'text/plain' post :create, params: { name: 'foo.txt' } ``` Then `foo.txt` should be in the `request_parameters` and params related to the path should be in the `path_parameters` and the `Content-Type` header should match the one set in the `@request`. When c546a2b0 was committed `text/plain` and `text/html` types were throwing a "Unknown Content-Type" error which is misleading and incorrect. Note: this does not affect how this is handled in the browser, just how the controller tests handle setting `Content-Type`.
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
This method is specifically about the content type so lets remove the parameter.
-
由 Aaron Patterson 提交于
create a singleton content type that just has nils, so that we don't have to allocate a content type object all the time.
-
由 Aaron Patterson 提交于
If someone sets just a charset, but depends on the implicit type from rendering, this will store a strange content type header that looks like this: `; charset=blah`. This is so that when the content type header is parsed again, it will return nil for the actual type.
-
由 Aaron Patterson 提交于
It turns out that the response object never really cares what the mime type object is, so just use the string.
-
由 Aaron Patterson 提交于
pull content-type setting to a private method to dry it up.
-