Personally I like the last option, which is what Tamcy also seems to
like.
ex: UrlLinkTo(...); ?>
Url()->linkTo(...); ?>
If you are interested in this topic, please read further. This text best
summarizes the prior discussion and the options proposed:
---
At this poi
Hi,
I made some bad examples, let me clarify:
Tamcy schrieb:
> Hi,
>
> Just my view on the implementation :
>
> 1. I don't think the class name "Url" (and sfBaseUrl) descibes its
> nature (as a helper) well.
I just used the helper function name as name, I don't care waht it will
be finally cal
Hi,
Just my view on the implementation :
1. I don't think the class name "Url" (and sfBaseUrl) descibes its
nature (as a helper) well.
2. No you can't use "for" as a function name because it is reserved ;)
3. I really doubt if it is a good idea to call a non-static method
using static binding ":
Ok, I reread the discussion about this issue.
We need:
no BC break
extensibility of existing helper classes
"namespaces"
autoloading
short and easy to use helper method names
It could be done like this (taking the url helper as example)
file UrlHelper.php in symfony/helper
__
I'm still thinking about the best solution for symfony 1.0 (the only
thing is that we must be 100% BC). If you have new ideas, I'm still open
to discuss the different options.
Fabien
Georg Gell wrote:
> Hi,
>
> I saw a discussion about namespaces aka classes for helpers on the ml
> some time
As far as I know, it was tossed around as an idea to make the Helpers
into a plugin and have it class based. I don't believe it went much
further than just an idea.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"s
