| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127 |
- <?xml version="1.0" encoding="UTF-8"?>
- <!-- Reviewed: no -->
- <sect1 id="zend.currency.usage">
- <title>Using Zend_Currency</title>
- <sect2 id="zend.currency.usage.generic">
- <title>Generic usage</title>
- <para>
- The simplest usecase within an application is to use the clients locale. When you create
- a instance of <classname>Zend_Currency</classname> without giving any options, your
- clients locale will be used to set the proper currency.
- </para>
- <example id="zend.currency.usage.generic.example-1">
- <title>Creating a currency with client settings</title>
- <para>
- Let's assume that your client has set "en_US" as wished language within his browser.
- In this case <classname>Zend_Currency</classname> will automatically detect the
- currency which has to be used.
- </para>
- <programlisting language="php"><![CDATA[
- $currency = new Zend_Currency();
- // See the default settings which are depending on the client
- // var_dump($currency);
- ]]></programlisting>
- <para>
- The created object would now contain the currency "US Dollar" as this is the actual
- assigned currency for US (United States). It has also other options set, like
- "$" for the currency sign or "USD" for the abbreviation.
- </para>
- </example>
- <note>
- <title>Automatic locale detection does not always work</title>
- <para>
- You should note that this automatic locale detection does not always work properly.
- The reason for this behaviour is that <classname>Zend_Currency</classname> must have
- a locale which includes a region. When the client would only set "en" as locale
- <classname>Zend_Currency</classname> would not know which of the more than 30
- countries was meant. In this case an exception would be raised.
- </para>
- <para>
- A client could also omit the locale settings within his browser. This would lead to
- the problem that your environment settings will be used as fallback and could also
- lead to an exception.
- </para>
- </note>
- </sect2>
- <sect2 id="zend.currency.usage.locale">
- <title>Currency creation based on a locale</title>
- <para>
- To prevent the problems with your client you could simply set the wished locale
- manually.
- </para>
- <programlisting language="php"><![CDATA[
- $currency = new Zend_Currency('en_US');
- // You can also use the 'locale' option
- // $currency = new Zend_Currency(array('locale' => 'en_US'));
- // See the actual settings which are fixed to 'en_US'
- // var_dump($currency);
- ]]></programlisting>
- <para>
- As within our first example the used currency will be "US Dollar". But now we are no
- longer dependend on the clients settings.
- </para>
- <para>
- <classname>Zend_Currency</classname> also supports the usage of an application-wide
- locale. You can set a <classname>Zend_Locale</classname> instance in the registry as
- shown below. With this notation you can avoid setting the locale manually for each
- instance when you want to use the same locale throughout the application.
- </para>
- <programlisting language="php"><![CDATA[
- // in your bootstrap file
- $locale = new Zend_Locale('de_AT');
- Zend_Registry::set('Zend_Locale', $locale);
- // somewhere in your application
- $currency = new Zend_Currency();
- ]]></programlisting>
- </sect2>
- <sect2 id="zend.currency.usage.territory">
- <title>Currency creation based on a country</title>
- <para>
- <classname>Zend_Currency</classname> is also able to work on a given country by using
- <classname>Zend_Locale</classname> internally.
- </para>
- <programlisting language="php"><![CDATA[
- $currency = new Zend_Currency('US');
- // See the actual settings which are fixed to 'en_US'
- // var_dump($currency);
- ]]></programlisting>
- <note>
- <title>Uppercase territories</title>
- <para>
- When you know that you are using a territory, then you should uppercase it.
- Otherwise you could get an in your eyes false locale in return. For example,
- when you give "om" then you could expect "ar_OM" to be returned. But in fact it
- returns "om", as it's also a language.
- </para>
- <para>
- Therefor always uppercase the input when you know that a territory is meant.
- </para>
- </note>
- </sect2>
- </sect1>
|