this was the reason why I did not create the "_"-Helper.
We as core developer can not violate the ZF coding convention.
I heard people where this works, and others where it does not.
Generally, parsing for translate() instead of _() is a 2 klick option in
poEdit.
And changing existing code from _() to translate() is also a 2 klick option
in and IDE I know.
So I dont really see this as problem, more as benefit for users so they dont
have to learn new things.
Greetings
Thomas Weidner, I18N Team Leader, Zend Framework
http://www.thomasweidner.com
----- Original Message -----
From: "Thomas Gelf" <thomas@gelf.net>
To: <fw-mvc@lists.zend.com>
Sent: Thursday, September 18, 2008 4:00 PM
Subject: [fw-mvc] Re: Correct way to create a _()-ViewHelper for
translations
> Loader is opening My/View/Helper//.php when looking for a _()-
> Helper, and that's why my example is working for me. However
> (as you are correctly stating) _ is "reserved" for marking
> packages - and it's usage as I did is not very catholic.
>
> The motivations for me to ask this to the list have been:
> * I don't like the //-thingy
> * Because of the //-thingy I don't know whether my helper would
> currently also work on Windows
> * I'm somehow violating the _-convention (this point could be
> discussed)
> * I don't like parts of my code to be found in "hidden" files
>
> Could someone tell me whether
> * future ZF versions would probably(!) break my Helper?
> * adding an exception for _ in the loader would make sense?
> -> if ($name === '_') ...
> * all plans for providing a _()-helper have been discarded?
>
> Thanks a lot!
>
> Cheers,
> Thomas
>
> Емил Иванов / Emil Ivanov schrieb:
>> The _ character is used to mark "packages" like Zend_Form. Having a class
>> with something like My_Class__ will make the loader look for this class
>> in path My/Class//.
>> Also, according to the convention You should name your file _.php :)
>>
>> Regards
没有评论:
发表评论