I guess you could read up on it on his blog - http://blog.bearwoods.dk/symfony2-paramconverters
On Mon, Jan 17, 2011 at 3:04 PM, Daniel Lohse <[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]> 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] >> > 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 >>> *e:* [email protected] >>> >>> >> >> >> -- >> *Bulat Shakirzyanov* | Software Alchemist >> >> *a: *about.me/avalanche123 >> *e:* [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]<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 > *e:* [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]<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 *e:* [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
