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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"symfony developers" group.
To post to this group, send email to symfony-devs@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
