Hello,
It will be nice to not add extra syntax into template file. url_for is
quite readable and quik to read and write.
Now, Jacob's idea is good, why not adding a small wrapper inside each
helper functions to handle specific overwriting.
-1 for this "echo $helper['url']->urlFor('@homepage');"
Thomas
On Mon, Jul 7, 2008 at 10:12 PM, Kris Wallsmith
<[EMAIL PROTECTED]> wrote:
>
> On Jul 7, 11:28 am, Ian <[EMAIL PROTECTED]> wrote:
>> I definitely think that it should be included in the core. It makes
>> sense.
>>
>> If you really object to using methods like this, you could easily have
>> a compatibility plugin if you really want to say soemthing like:
>>
>> function url_for()
>> {
>> sfUrlHelper::urlFor();
>>
>> }
>>
>> That's no different on the frontend than it is now
>
> +1 for this layer of functions. But is it BC (to be removed in 1.3) or
> is it an alternate syntax (to be maintained). Based on responses to
> this thread, I think these functions should be maintained for 1.x.
>
> Can we expect devs to create these function wrappers for every OOP
> helper method?
>
> - Kris
>
>> On Jul 7, 10:34 am, Tamcy <[EMAIL PROTECTED]> wrote:
>>
>> > 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
>>
>> > On Jul 7, 4:00 pm, "Fabian Lange" <[EMAIL PROTECTED]>
>> > wrote:
>>
>> > > Hi,
>> > > so you say the template has to prevent the developer to access classes
>> > > they
>> > > should not access in the template?
>> > > That approach failed with JSP taglibs, and led to the templates we today
>> > > know.
>>
>> > > I also cannot see why we say "do what you want".
>> > > I would say: Use the static helper methods.
>>
>> > > If we end up with the sfHelpers->get('url'); thingy, fine then we
>> > > recommend
>> > > that.
>>
>> > > But I asked the question what benefits this brings and what use case
>> > > supports that.
>> > > .: Fabian
>>
>> > > On Mon, Jul 7, 2008 at 9:47 AM, Dennis Benkert <[EMAIL PROTECTED]>
>> > > wrote:
>>
>> > > > > I do not like the idea of "go on and use everything you want in your
>> > > > > templates and good luck with finding the right way".
>>
>> > > > I agree with that. The framework has to leas you the right way by it's
>> > > > own code. In my opinion giving the developer to much room for bad
>> > > > things leads to same problems php suffered for years.
>>
>> > > > - Dennis
> >
>
--
Thomas Rabaix
Internet Consultant
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
