Thanks Tamcy for proving a Use Case.
I can see the need to modify core behaviour now that is taken by parties
that are not aware of this change (lets say a plugin should also append the
id to the links).
I guess we can find a way that supports this and that is not too frightening
for non-developers in their html
echo $helper['url']->urlFor('@homepage');
doesn't look too bad for me. Currently you also have to import the helper.
With respect to backwards compatibility, I guess we simply delegate the call
to $helper[$currentHelperPHP]->sameMethod();
Or even make it work with introspection?
But where do we want to make $helper visible? Action code might want to read
it as well.
So what about a Service Locator pattern? :-)
echo Helper::use('Url')->urlFor('@homepage');
My complaint was that this might be 'too magic'. I think its still valid, as
this not only introduces more PHP syntax to the templates , on the other
hand you don't know what you get at runtime. But looking back at 1.0 its
similar. You also do not know what will be available after you do the
use_helper call.
But how do we want the Helper::use to work?
Assuming now that we provide this feature, who can use it. What when a
plugin wants to append an id to links and you want to append ids to links.
Do you need to configure it? Could we use the event system for that. Aren't
we ending up with mixin hooks here (at least at a single point).
On this thread we had already the
$urlHelper = $sf_helper->get('url')
Syntax.
What would be the benefits of not using a static call/use/get method?
Do we want to customize the Service Locator itself as well?
Where would $sf_helper be available?
I know that I am repeating stuff. But I want to make sure we have thought
this through, as I would dislike to refactor this again soon :-)
.: Fabian
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED]
On Behalf Of Tamcy
Sent: Montag, 7. Juli 2008 18:34
To: symfony developers
Subject: [symfony-devs] Re: roadmap for helpers in 1.2
Hi Fabian,
Well I should say yes, static methods still works. As I need a
"session id" appended to most of the links, I end up write a
"my_url_for", "my_link_to" which uses "my_url_for", and
"my_link_to_if" and "my_link_to_unless" which use my_link_to. Yes it
still works, but leads me to think of a way which allows me to just
override that url_for() so that link_to() and friends will use the
overriden url_for(). That's why I like the idea of object helpers. I
just not sure if it's convincing enough. Because for the
"sfUrlHelper::linkTo" case, I just need to (re)write
"myUrlHelper::urlFor", "myUrlHelper::linkTo", "myUrlHelper::linkToIf",
"myUrlHelper::linkToUnless" and it still works.
And may I say even not being put in the core doesn't mean the end of
"class helpers of non-static methods" because it should be possible
for a, say, sfAdvancedHelperPlugin with does what we are talking about
- a class which collaborate helpers and enables the "magic" I want.
I love it, but I'm not eager to have it in core (unless there's
something I missed that it's not possible for such a plugin), although
it gives us more convenience.
In this sense the problem may be further narrowed down to:
(1) We love it and want it as a core, or
(2) We love it but not nececssary the default way to do it, or
(3) It's still evil to be implemented as a plugin.
Actually I have concern not only about designers, but also performance
issue, which seems worth spending some time investigating on it.
Tamcy
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
