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] > 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] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
