On Jul 7, 2008, at 3:11 PM, Fabian Lange wrote:
> echo $helper['url']->urlFor('@homepage');
Please, PLEASE do not do this. There is no practical need to make the
view have that much syntactic noise.
If you want to override the built-in behavior, do it through an API on
the backend. Please do not get rid of the helper functions.
Perhaps even call them behaviors and have them configured through a
well-known API:
behaviors.yml:
url: sfDefaultUrlBehavior
some random helper.php:
function url_for($route)
{
$b = sfBehaviors::getInstance('url');
return $b->genUrl($route);
}
So, if you have a CDN, you can change out sfDefaultUrlBehavior for
sfA3StaticUrlBehavior and get CDN support easily.
>
>
> 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
>
>
> >
--
Jacob Coby
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
