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
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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
