Hmm, generating routes back using objects gives this conversation a whole new perspective.
On Mon, Jan 17, 2011 at 6:19 PM, Sergey Linnik <[email protected]> wrote: > I think it is an interesting idea, because this step is to make > ParameterConverter bidirectional, to be able to create a route in this > way: > url ('get_user', {'user': user}) > > My thoughts: > > some_route: > pattern: /{user_id}/albums/{album_id} > defaults: {_controller: users.controller:get} > parameters: > user_id: {type: route.converters.mongo, name: user, document: > MyBundle:User, field: id } > album_id: {type: route.converters.default, name: album, entity: > MyBundle:Album, field: id } > > some_route2: > pattern: /post/{post.key}-{post.titleUrl} > defaults: {_controller: users.controller:get} > parameters(relations?): > post: { type: route.converters.default, entiry: > "MyBundle:User", field: id, param: key } > > in example "POST" variable is transformed using post.id parameter as > the value for the ID field. > route generate automatically inserted post.id and post.titleURL. > as these variables can be set manually as post_id post_titleURL. > > all conversions are only applicable if the controller is explicitly > requests this option: > > public function viewAction ($album) { > // $album instance of MyBundle:Album > // user is not converted > } > > > 2011/1/18 Bulat Shakirzyanov <[email protected]>: > > Thanks for the feedback and questions. > > The main differences of my suggested implementation are: > > > > You can see all parameter conversions by looking at the route definition, > > and there shouldn't be a case where one converter is > taking precedence over > > another implicitly. > > The internal foreach ($parameterConverters ...) is removed as you are > being > > specific as to which converter type you need, so could be better > > performance-wise too. > > Because the parameter is chosen based on the typehint, in Doctrine > document > > case, *I think*, you would have to define your own parameter converter, > > or modify the one you have with introduction of every new class, so that > > your supports statement returns true at all times > > > > Thanks! > > On Mon, Jan 17, 2011 at 3:21 PM, Fabien Potencier > > <[email protected]> wrote: > >> > >> On 1/17/11 8:42 PM, Bulat Shakirzyanov 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. > >> > >> To make things clear, parameter converters are already supported in > >> Symfony2. Henrik ported the implementation I did in > FrameworkExtraBundle. > >> > >>> 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, converted_name } > >>> > >>> At this point you might be asking yourself: "What's this parameters > >>> thing in the route?" > >>> Let me explain. > >> > >> Keep in mind that routing should do one thing and only one thing: > parsing > >> the path info to request attributes. > >> > >> So, I don't like the fact that we overload the configuration with a new > >> "parameters" entry. In the current implementation of the param > converters, > >> you can add things to the "defaults" item if you want to "configure" the > >> conversion. In the FrameworkExtraBundle, it's better as you can pass > them > >> directly via the annotation. > >> > >>> 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); > >>> } > >> > >> This is already what we have (except that the tag is > >> "request.param_converter"). > >> > >>> > >>> 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(); > >>> } > >> > >> There is no need for that. The current implementation relies on type > >> hinting to know which argument to convert. So, in this case, the > argument > >> name is irrelevant. > >> > >> So, to sum up, I fail to see what is really different from the current > >> implementations. > >> > >> Fabien > >> > >>> 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 > >>> } > >>> > >>> 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]> > >>> > >>> -- > >>> 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 > >> > >> -- > >> 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]<symfony-devs%[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
