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]
>>> 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
