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
