Query param fetcher #185

lsmith77 · 2012-02-07T20:04:22Z

You can see things in action at:
https://github.com/liip/LiipHelloBundle/blob/query_param-proof-of-concept/Controller/RestController.php#L34

…nstructor

lsmith77 · 2012-02-07T21:40:57Z

maybe instead of a listener we can use a param converter:
http://symfony.com/doc/2.0/bundles/SensioFrameworkExtraBundle/annotations/converters.html

stof · 2012-02-07T21:46:53Z

does the QueryParam stuff depend on FrameworkExtraBundle currently ?

lsmith77 · 2012-02-07T21:49:55Z

no .. currently it does not. but i don't really like having to use a listener to set the request attribute.

vicb · 2012-02-07T22:13:15Z

Request/QueryFetcher.php

+            throw new \InvalidArgumentException('No _controller for request.');
+        }
+
+        if (false !== strpos($_controller, '::')) {


Could you leverage the ControllerResolver ?

yeah maybe ..

looking at the code it seems like it would be inefficient for the case when the controller is not implemented as a service. but it looks like we are lacking support for a:b:c notation atm.

That would be more dry and future proof

ok .. we should now cover all the cases

yeah it would .. but i don't think the overhead makes this legitimate.

could the controller event help with efficiency ?

hmm it could be a possibility. in that case we would move the other listener from a request listener to a controller listener as well. in that case of course the parameters would no longer be available in any listeners run before the controller, but i guess that would be ok.

ok .. i have an implementation using a controller event .. will push that into a new branch

vicb · 2012-02-07T22:52:29Z

EventListener/QueryFetcherListener.php

+    public function onKernelRequest(GetResponseEvent $event)
+    {
+        $request = $event->getRequest();
+        $request->attributes->set('queryFetcher', $this->container->get('fos_rest.request.query_fetcher'));


do we really need a listener, can't it be lazy loaded (just a thought, too late to check for now)

we need a listener to set the request attribute, so that it can be injected via the action signature, which is imperative to controllers that do not inject the DIC ..

…ncept2 Query param proof of concept with a controller listener

vicb · 2012-02-09T07:02:46Z

Some thoughts:

Is the queryFetcher a good idea ? Let's imagine I do some processing in my controller based on the query parameters and then I call doSomeGreatStuff($request). This function would get the query parameters as $request->query->... and then we have a mismatch. Would it be possible to drop the queryFetcher and replace (or update) the query parameter bag instead so that the API does not get changed ?

I can imagine some day we have a router component that is aware of the query parameters. This PR could not work as the parameters are processed in the controller only. So I would prefer if the changes are moved to the router layer.

lsmith77 · 2012-02-09T07:41:04Z

Overriding the Request parameter bag would remove the need to set the request attribute. How would it behave in that case though? I guess it would then only overload get() to set the default from the annotation (what would happen if a default is passed?) and execute the given requirements checks from the annotation?

lsmith77 · 2012-02-09T08:41:54Z

the other question would be where and when do we override the default parameter bag? would this require a custom Request class or a listener again?

vicb · 2012-02-09T08:55:38Z

@lsmith77

What I can imagine is to update the parameters in the bag and then use the bag as before.
I would go for the router layer for the reason explained in my previous message. I had first thought of a custom bag class but I don't even think it is necessary (see my point above).

lsmith77 · 2012-02-09T08:58:23Z

Well I see some major issues here:

it would mean we do a lot of work that may not become necessary
if we do it in the router, then we will have the issue with determining the class/method again

lsmith77 · 2012-05-15T15:21:32Z

ok .. i have implemented the option of forcing the query params to be set as attributes. on conflict it throws an exception. however we also need to improve the route generation to skip any configured query parameter.

lsmith77 · 2012-05-15T19:37:11Z

btw .. just FYI .. you can always fork this branch and submit PRs back to this branch if you have ideas for improvements. for example it would be cool of someone could fix the above noted issue with using query params in the method signature causing them to be put into the route.

lsmith77 · 2012-05-15T19:58:00Z

nevermind .. already took care of it ..
anything else people think should be done?

lsmith77 · 2012-05-15T20:01:14Z

main thing missing now are docs ..

stof · 2012-05-15T21:38:46Z

@lsmith77 As I already said a while ago, I think you should add an interface for the QueryParamReader and use it in the typehints, to allow people to replace the implementation if they want.

lsmith77 · 2012-05-15T21:42:25Z

QueryParamReader or QueryFetcher? Anyway, I will leave that to who ever wants to make the first alternative implementation :)

stof · 2012-05-15T21:56:41Z

probably both :)
But I was talking about the reader first, thus allowing people to write an implementation reading from elsewhere than annotations if they don't like annotations

stof · 2012-05-16T07:48:54Z

DependencyInjection/Configuration.php

@@ -39,6 +39,7 @@ public function getConfigTreeBuilder()

        $rootNode
            ->children()
+                ->scalarNode('query_fetcher_listener')->defaultValue(false)->end()


shouldn't it be a booleanNode ? And you could use defaultFalse()

ok, it is not a boolean. But you should probably limit the possible values

whats the syntax for that?

https://github.com/FriendsOfSymfony/FOSUserBundle/blob/master/DependencyInjection/Configuration.php#L46

stof · 2012-05-16T08:40:34Z

DependencyInjection/Configuration.php

+                ->scalarNode('query_fetcher_listener')->defaultFalse()
+                    ->validate()
+                    ->ifNotInArray($this->forceOptionValues)
+                    ->thenInvalid('The query_fetcher_listener option does not support %s. Please choose one of '.json_encode($this->forceOptionValues))


missing one indentation level

…ncept Query param fetcher

schmittjoh · 2012-05-16T13:34:07Z

About silently setting the default value on validation failure, would it not make more sense to redirect to the URL with the default value? Also in terms of SEO, and duplicate content, this seems more sensible, no?

lsmith77 · 2012-05-16T13:36:21Z

i thought about that too .. we could provide such an option as part of the listener eventually. it should of course only be down for proper GET requests. however i don't think that query parameters are that important for SEO, but it is relevant for caches i guess.

asm89 and others added 7 commits January 31, 2012 23:24

Proof-of-concept for @QueryParam validation

631fe13

Add tests

8c04a84

requires -> requirements to be consistent with sf2

192f3ae

Merge branch 'master' into query_param-proof-of-concept

bfa891e

added support for defaults via annotations

e32e078

added support for controllers as a service, moved logic out of the co…

80d0da4

…nstructor

added support for passing the QueryFetcher as an action parameter

7cfa318

lsmith77 mentioned this pull request Feb 7, 2012

[PoC] @QueryParam validation #178

Closed

lsmith77 added 2 commits February 7, 2012 21:12

fix tests

25517a6

cosmetic tweaks

fd1ae02

vicb reviewed Feb 7, 2012
View reviewed changes

lsmith77 added 2 commits February 7, 2012 23:23

fixed regexp plus a few cosmetics

b03414b

cover all possible controller definition cases

937e273

vicb reviewed Feb 7, 2012
View reviewed changes

lsmith77 mentioned this pull request Feb 7, 2012

Query param proof of concept with a controller listener #186

Merged

lsmith77 added 4 commits February 8, 2012 19:21

use a controller listener

e7fe284

tweaked error handling

df59842

Merge pull request #186 from FriendsOfSymfony/query_param-proof-of-co…

ebbfb5c

…ncept2 Query param proof of concept with a controller listener

tweaked error handling

a52e85d

made it possible to set the query parameters as request attributes

9cbb25d

ignore query params when generating routes

0671c11

lsmith77 added 3 commits May 15, 2012 22:12

cosmetics

199f42e

added documentation

3406ebd

fix tests

87ccc2b

lsmith77 added 2 commits May 16, 2012 08:45

added strict mode

3535e86

some more docs

4137c3e

stof reviewed May 16, 2012
View reviewed changes

lsmith77 added 6 commits May 16, 2012 09:58

validate parameters

07ae8fe

simplified code

f6d019d

added interfaces

af142df

validate configs

37661de

undo previous commit .. no need to make things harder

822af06

cosmetics

3e20eac

stof reviewed May 16, 2012
View reviewed changes

ws tweak

5c88435

lsmith77 added a commit that referenced this pull request May 16, 2012

Merge pull request #185 from FriendsOfSymfony/query_param-proof-of-co…

0aa7534

…ncept Query param fetcher

lsmith77 merged commit 0aa7534 into master May 16, 2012

lsmith77 mentioned this pull request May 16, 2012

add tools to include link, allows etc in the response #52

Closed

lsmith77 mentioned this pull request May 16, 2012

optionally automatically redirect on invalid query params #241

Open

Query param fetcher #185

Query param fetcher #185

Conversation

lsmith77 commented Feb 7, 2012

lsmith77 commented Feb 7, 2012

stof commented Feb 7, 2012

lsmith77 commented Feb 7, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vicb commented Feb 9, 2012

lsmith77 commented Feb 9, 2012

lsmith77 commented Feb 9, 2012

vicb commented Feb 9, 2012

lsmith77 commented Feb 9, 2012

lsmith77 commented May 15, 2012

lsmith77 commented May 15, 2012

lsmith77 commented May 15, 2012

lsmith77 commented May 15, 2012

stof commented May 15, 2012

lsmith77 commented May 15, 2012

stof commented May 15, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

schmittjoh commented May 16, 2012

lsmith77 commented May 16, 2012