On 3/20/10 4:29 PM, Nicolas Perriault wrote:
On Sat, Mar 20, 2010 at 1:19 PM, Fabien Potencier
<[email protected]> wrote:
What's the impact on performances by the reflection? Is it done at
runtime or can the work be efficiently cached?
Almost no impact. This is already what we use... and the performances are
quite good.
So then annotations could opportunely be used, as someone already
mentionned ;) But I know you don't like this approach at all, so... :/
It's not that I don't like the approach. But as there is no PHP built-in
support, it is much slower than straight introspection. I mean,
introspection can only return the raw phpdoc string. You then need to
parse it, validate its format, and convert it to something useful... for
each request. Or, you need to create some kind of cache, which is
definitely something I want to avoid as much as possible.
Agreed, I don't like much the protected variables trick; I'd rather
use a dedicated one:
protected $__requirements__ = array('user', 'doctrineManager');
Testing a controller is much cleaner than before though:
$user = new UserMock();
$controller = new ArticleController($user);
Could then be:
$controller = new ArticleController(array(
'user' => new UserMock(),
));
But you loose a lot here:
* what is you have a typo in the key ('usre')?
What if you have a typo in your variable passed as arguments in your
controller method signature?
You will have an exception as it won't match anything. And you have type
hinting and default values automatically, without additional work. I
think leveraging PHP as much as possible is the way to go most of the time.
* not possible anymore to typehint
If it's really needed, you can always use the /** @var **/ annotation.
Also, I don't know if it's a good idea to shape a framework
architecture regarding actual IDE capabilities... That's another
disputation, I must admit.
I don't really care about IDE integration (as you know I only use
Textmate). Typehinting is also interesting because PHP will throw an
error if you don't pass the right object, which can save your day from
time to time.
* no default value
Could be circumvented by using an array_merge before passing the
services hash, no?
Sure, but that's yet another thing you need to do by yourself. At the
end of day, it seems to me that we will have reinvented the wheel.
Honnestly, having a controller method (or a function) behaving like a
class often proved to be hard to deal with (especially with PHP, which
is very uncomfortable to work with in this regard), and generally
highlights an architecture problem imho. The passed parameters looks
more like properties of (a) dedicated configuration object(s) than
standard method parameters... but that's just my opinion regarding my
very own experience.
"method behaving like a class": What do you mean?
'lot of naming conflitcs expected': I'm not sure it would happen that much.
I had a look at a lot of my own controllers in symfony 1 and the number of
needed arguments is mot of the time (read always) very low.
[...]
hehe, it means that your controller is a real mess ;)
Not that easy I'm affraid; did you recently work on a huge and
somewhat complex project? I'd be more than happy to have more feedback
on this from people working on very complex applications, with complex
routes and many factories to deal with. Maybe it's just my bad but on
a current project I'm working on, I have overriden quite every single
available factory to suit the needs of the aplication, and have often
routes with 4 or 5 different parameters (there sfObjectRoute and
family are a bliss!).
The great news is that for such cases, you can just ask for the request
and the container object for instance and "simulates" your approach:
function showAction(Request $request, Container $container)
{
$slug = $request->getParamter('slug');
$container->user->setAttribute(...);
}
The caveat is that people will probably begin to write their own
services to be able to get references for the Request instance, and
the Response one, and the User one, and so on to avoid using the
method arguments within a controller. That's certainly not wrong at
all, but it's more difficult, and demanding for developers. And the
danger of encouraging people to recode their own sfContext class is
not far from that.
One more time, just my humble opinion.
Very much appreciated, thanks.
Fabien
++
--
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
To unsubscribe from this group, send email to symfony-devs+unsubscribegooglegroups.com or
reply to this email with the words "REMOVE ME" as the subject.
