On 1/17/11 9:07 PM, Bulat Shakirzyanov wrote:
I guess you could read up on it on his blog - http://blog.bearwoods.dk/symfony2-paramconverters
And here is the doc for the original implementation in FrameworkExtraBundle: http://bundles.symfony-reloaded.org/frameworkextrabundle/annotations/converters.html
On Mon, Jan 17, 2011 at 3:04 PM, Daniel Lohse <[email protected] <mailto:[email protected]>> wrote: Ah, now I do understand – thanks! :) I like the approach very much and I guess, the DoctrineBundle could ship with a few base converters that encapsulate the boilerplate code or would you rather have us develop those for each individual project? But to really say "+1" or "-1, because..." it'd be nice to know how exactly your POV/implementation differed from Henrik's? Cheers, Daniel On 17.01.2011, at 20:55, Bulat Shakirzyanov wrote:Extract most common url parameter use-case in dedicated converters, removing duplicate code from controllers: Lookup user by id, instead of doing this in controller, you could tell Symfony2 to "convert" user id into User object, then in controller action instead of expecting id of a user as string, you could expect a looked up User object. On Mon, Jan 17, 2011 at 2:50 PM, Daniel Lohse <[email protected] <mailto:[email protected]>> wrote: Hey Bulat, sorry for being such a dumbass but it's already late here – could you summarize what this will let us accomplish in one or two sentences, please? ;-) Cheers, Daniel On 17.01.2011, at 20:44, Bulat Shakirzyanov wrote:sorry, had a typo in the route example On Mon, Jan 17, 2011 at 2:42 PM, Bulat Shakirzyanov <[email protected] <mailto:[email protected]>> wrote: Hi dear Symfony2 devs, I have proposed this a while ago and had some positive feedback from few people, today I brought this up in #symfony-dev IRC chatroom and found some strong opinions against it, so I wanted to make a more formal proposal so that everyone can weigh in and I can get feedback all around. I know that Henrik has been working on a parameter converters implementation and while he's got a very clear idea of what he needs and which use cases he wants to satisfy, I have a slightly different point of view. Here is how I see it: We define a route: get_user: pattern: /users/{id}.{_format} defaults: { _controller: users.controller:get, _format: html } requirements: { _method: GET, _format: (html|xml|json), id: } parameters: id: { type: doctrine.mongodb.document, class: ApplicationBundle\Document\User } At this point you might be asking yourself: "What's this parameters thing in the route?" Let me explain. We define a service in DIC, that looks like this: <service id="some_service_id" class="DoctrineDocumentParameterConverterClass"> <tag name="parameter.converter" type="doctrine.mongodb.document" /> <!-- some other dependencies if any --> </service> the DoctrineDocumentParameterConverterClass implements parameter converter interface, that might look like: interface ParameterConverter(Interface?) { /** * @param string $parameter * @return Document */ function convert($parameter); function setOptions(array $options); } Then in our controller service class: class UsersController { // some php code here... public function get(\ApplicationBundle\Document\User $user) { // some more php code... } } Now one catch is that the original parameter name 'id' is now replaced with 'user', but we could make that piece part of the ParameterConverter interface too, like so: interface ParameterConverter(Interface?) { // previous functions function getParameterName(); } And our DoctrineDocumentParameterConverterClass implementation would work like this: class DoctrineDocumentParameterConverterClass implements ParameterConverter { private $class; private $parameterName = 'document'; public function setOptions(array $options = array()) { if (!isset($options['class'])) { throw new InvalidArgumentException("'class' is a required option"); } $this->class = $options['class']; if (isset($options['parameter'])) { $this->parameterName = $options['parameter']; } } public function getParameterName() { return $this->parameterName; } // the actual class implementation } And the route then changes to: get_user: # route definition parameters: id: { type: doctrine.mongodb.document, class: ApplicationBundle\Document\User, parameter: user } This is a request for comment, so any feedback is appreciated. Best, -- *Bulat Shakirzyanov* | Software Alchemist *a: *about.me/avalanche123 <http://about.me/avalanche123> *e:* [email protected] <mailto:[email protected]> -- *Bulat Shakirzyanov* | Software Alchemist *a: *about.me/avalanche123 <http://about.me/avalanche123> *e:* [email protected] <mailto:[email protected]> -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com <http://symfony-project.com/> You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] <mailto:[email protected]> To unsubscribe from this group, send email to [email protected] <mailto:[email protected]> For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en-- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com <http://symfony-project.com/> You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] <mailto:[email protected]> To unsubscribe from this group, send email to [email protected] <mailto:symfony-devs%[email protected]> For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -- *Bulat Shakirzyanov* | Software Alchemist *a: *about.me/avalanche123 <http://about.me/avalanche123> *e:* [email protected] <mailto:[email protected]> -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com <http://symfony-project.com> You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] <mailto:[email protected]> To unsubscribe from this group, send email to [email protected] <mailto:[email protected]> For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en-- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com <http://symfony-project.com> You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] <mailto:[email protected]> To unsubscribe from this group, send email to [email protected] <mailto:symfony-devs%[email protected]> For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -- *Bulat Shakirzyanov* | Software Alchemist *a: *about.me/avalanche123 <http://about.me/avalanche123> *e:* [email protected] <mailto:[email protected]> -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
-- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
