Issue

ZF-1000: Zend_Date::usePhpDateFormat() <=> Zend_Locale_Format::usePhpDateFormat()

Issue Type: Improvement Created: 2007-03-01T18:06:08.000+0000 Last Updated: 2007-07-05T14:43:53.000+0000 Status: Resolved Fix version(s): Reporter: Gavin (gavin) Assignee: Thomas Weidner (thomas) Tags: - Zend_Date

Related issues: Attachments:

Description

I suggest either:

  1. Removing the recently added Zend_Date::usePhpDateFormat(), because it only proxies to Zend_Locale_Format::usePhpDateFormat() without adding any value, and because it has side-effects extending beyond Zend_Date that affect class behavior of other components.

or

  1. Making the Zend_Date::usePhpDateFormat() affect only Zend_Date*, instead of other functions in other classes (i.e. Zend_Locale_Format).

I also recommend using a static setOptions() method to set options that affect an entire component (i.e. all instances or static methods), where the option name would be 'usePhpDateFormat'. See Zend_Session::setOptions() for an example.

Comments

Posted by Thomas Weidner (thomas) on 2007-03-02T00:00:22.000+0000

When we remove the format specifier we have the problem that other functions which use date format specifier within Zend_Date would not interact correct... The functions calling Zend_Locale would use php format, the functions within Zend_Date would use ISO format.

And when I want to use php format for Zend_Date's toString function why should I call a function within Zend_Locale ??? This would be unlogic and inconsistent.

Make Zend_Date only affect for php format... this leads to problems within the functions calling Zend_Locale for getting results... we have to add logic to detect if php or iso format is specified within Zend_Locale and then act the expected way... change to iso, call function, revert to previous format. But this stretches our code by about 50 lines... Zend_Locale is often called for all localizing/normalizing tasks within Zend_Date.

The first can not be accepted... and second... we have already a HUGE class... shall we really do it this way ??

Having setOptions() implemented is no problem for all static avaiable parameters. This will be done the next days.

Posted by Thomas Weidner (thomas) on 2007-03-05T11:00:53.000+0000

I added setOptions with one if the latest SVN to Zend_Date and Zend_Locale. usePhpDateFormat was deleted. Both classes use now setOptions() seperately.

But also to mention, I see some negative sideeffects having one class set to iso and the other to php as it has to be included. I now solve this side effects by more than 100 lines of code... In my opinion there is no usecase in which a user would use iso with the one and php with the other class. And both classes are close related to each other because Zend_Locale gives Zend_Date the possibility to act locale aware.

I think this decission has to be rethought... we are now at the old number of 4400 lines even after my last refactoring. Maybe you can give an usecase where we would need a seperation ??

Posted by Gavin (gavin) on 2007-03-05T20:28:35.000+0000

I see a large number of duplicated lines of code in Date.php from the recent patch. I do not see a reason for the duplicated code.

Use cases for using both ISO and PHP date format strings:

Any development team integrating existing code.

Any development team with members having different preferences and habits (some using PHP way, some using ISO).

Developers using the www.zend.com/code/codex.php" rel="nofollow">Zend PHP Code Gallery (some code might use PHP way, some might use ISO).

Summary: Zend_Locale has methods and state (i.e. whether or not to use ISO or PHP date format). However, it is not a true object, because the state is stored in static class variables. The design of Zend_Locale results in the "extra" code in Zend_Date to modifying the state of Zend_Locale, use Zend_Locale, and then restore the state (i.e. restore the static variable).

As always, alternative ideas and implementations are encouraged. More options and ideas lead to synergistic solutions using the collection of alternatives discussed. Perhaps we should consider alternative implementations that result in less code and less duplication.

For example, if these static methods and state were packaged into a true object, then the appropriate instance object property (i.e. use ISO or PHP format) could be set on the object once. Then other code throughout the framework could use the desired instance object without having to save the state and restore the state, as done now by the recent patch to Zend_Date.

Posted by Thomas Weidner (thomas) on 2007-03-06T01:58:38.000+0000

That's frustrating...

I mentioned the problems having 2 seperated formats within 2 classes for it's own already before. Instead of giving me an usecase for using iso for Zend_Date and php for Zend_Locale which makes me happy you are now proposing what was integrated before my patch... Having only one place for storing the format parameter.

I see no difference to my first integration where the format was held within Zend_Locale_Format and your proposed change where the format is stored within an object. There is only 1 point where the information is stored, and not two as proposed by this issue. We could have let the old implementation integrated. So we have made a step back with this issue ? Great... 3-4 hours work useless :-(

The benefit of Zend_Locale_Format was that it's only static !!! Changing this to be an object would be a step back... and extracting the date functions from Zend_Locale_Format into an own class would also result in one step back.

Posted by Gavin (gavin) on 2007-03-06T13:37:17.000+0000

Creating and committing patches prematurely can lead to some wasted effort, but comparing ideas using code also has some value. We all experience this process, and use our best judgement about when to discuss ideas and when to write code.

I don't see any comments about "2 classes" above (only using instance objects). Ideas and alternatives are always welcomed and a healthy part of the brainstorming process.

{quote}Good summary of how to do a successful brainstorming. http://theopenforce.com/2006/08/… And a bad one: http://theopenforce.com/2006/08/… {quote}

After the recent patch, there is still only one place to store the "state" in Zend_Locale_Format (i.e. "public static $_usePhpDateFormat") which toggles between using ISO and PHP formats. I think my suggestion has been completed misunderstood. The recent patch added some bloat (and lots of duplicated code). Most of this extra code in Zend_Date could be avoided if Zend_Locale_Format was promoted to a full, "normal" object.

If Zend_Locale_Format could be instantiated like a normal object, and had a protected instance property (i.e. "useIsoFormat") defaulting to "true", then Zend_Date would not need to frequently modify the static class variable "public static $_usePhpDateFormat = false;" inside of a try .. catch block to restore the state of this variable on error.

Posted by Thomas Weidner (thomas) on 2007-03-06T14:26:00.000+0000

But one of the big benefits of Zend_Locale_Format and _Data is that the complete class is static and can be used without initiating an object.

And I would not want to break this only because of the format options parameter.

Before this issue was raised by the devteam I had only one parameter for the format which was used by all localizing classes. As Zend_Date also uses localizing and must load Zend_Locale_Format to work properly there was no problem.

Now, as I was told to change this, we have two places where the format is stored and changed. And this leads to problems if Zend_Date is ISO and Zend_Locale is changed to PHP. Because we can not convert from ISO to PHP... this would eliminate several formats... the other way from PHP to ISO is no problem.

Having Zend_Locale_Format being integrated within the Locale object would not solve the problem. You would have to change the format for each of your locale objects. And we have the problem to change the format from php to iso to work properly with Zend_Date.

A much better and easier way would be to have an additional parameter where we could say that the format is in ISO per Hand...

f.e.

<pre class="highlight">
    public static function getDate($date, $format = null, $locale = null, $formattype = null)

So we could override the options-settings by giving a TRUE to $formattype and say that the format is ISO whatever options is set to.

Another way would be to have a fixed string a leading format which defines ISO as input. f.e. '_ISO_YYYY-DDD hh:mm'... xxx would say format xxx whatever options is set to.

Options would only set the standardformat, which could be overridden if a defined format is given. No object would be needed, and the mentioned additional codelines of Zend_Date would also not be needed.

Posted by Gavin (gavin) on 2007-03-06T15:00:09.000+0000

{quote}"But one of the big benefits of Zend_Locale_Format and _Data is that the complete class is static and can be used without initiating an object."{quote}

Avoiding the use of objects allows developers to directly call functions. However, there are some advantages to object-oriented programming using objects that manage and maintain their own state.

{quote}"No object would be needed, and the mentioned additional codelines of Zend_Date would also not be needed."{quote}

Yes, but the API can become more burdensome to the developer and more complex without objects. A large number of optional parameters can be evidence of the need for an object with state (i.e. properties) and normal methods to manipulate the state (e.g. set a locale, set a formattype, set a format) and then methods to operate on that state (e.g. getDate(), getCorrectableDate(), isDate(), convertFormat*(), etc.). By avoiding the use of normal objects, the API becomes more complex and the developer must manage the state themselves, which is why there was a lot of code required in the recent Zend_Date patch to support setOptions().

<pre class="highlight">
$format = new Zend_Locale_Format();
$format->setLocale('en_US');
$format->setFormatType(Zend_Locale_Format::PHP);
$format->setFormat('h:i:s');
$format->setPrecision(3);

// now we can use our "configured" object directly, without having lengthy lists of arguments to each function:
$number = $format->getNumber($input);
echo "Locale formatted number: ", $format->toNumber($value);
echo "Self-defined formatted number: ", $format>toNumberFormat($value);
echo "Is number? ", $format->isNumber($input) ? 'yes' : 'no';
$float = $format->getFloat($input);
echo "Date = ", $format->getDate($date);
etc.

Thus, for developers that use multiple functions in Zend_Locale_Format, the current approach requires far more duplication by repeatedly supplying the same arguments to the Zend_Locale_Format static methods. If the developer could create an object, and set the properties as needed, the object would then remember the state/arguments for use with the many methods in Zend_Locale_Format.

Again, the ideas above are brainstorming to consider alternatives that might offer improvements to existing code. Perhaps a combination of the ideas above might yield a good end solution.

Posted by Thomas Weidner (thomas) on 2007-03-06T16:13:09.000+0000

{quote}Avoiding the use of objects allows developers to directly call functions. {quote}

But this is the benefit not a negative thing.

{quote}Yes, but the API can become more burdensome to the developer and more complex without objects. A large number of optional parameters can be evidence of the need for an object with state (i.e. properties) and normal methods to manipulate the state (e.g. set a locale, set a formattype, set a format) and then methods to operate on that state (e.g. getDate(), getCorrectableDate(), isDate(), convertFormat*(), etc.). By avoiding the use of normal objects, the API becomes more complex and the developer must manage the state themselves, which is why there was a lot of code required in the recent Zend_Date patch to support setOptions().{quote}

No... also with the actual static implementation we can add to have standard parameters set with setOptions(). Having an own function for each parameter as proposed in your last example does not simplify the API... it makes it more complicated because you have then about 10 new functions only for setting the parameters.

The precision or standard formatstring can also be set by setOptions... this would not mean to change all to object. If you give null, the standard from setOptions would be used. But this is a new issue not related to the actual one.

<pre class="highlight">
// actual
Zend_Locale_Format::getNumber('1234', 2, 'en');

// new
Zend_Locale_Format::setOptions(array('precission' => 2, 'locale' => 'en'));
Zend_Locale_Format::getNumber('1234');

This would also lead to a reduced parameter list.

I was originally told to use a static approach for simplicity... now I should use a object approach for simplicity ??? Do we really know what makes a class simple to use ?? Sometimes I have the feeling that even the devteam does not know what they want me to do...

And even now I dont see the benefit from seperating the localizing format and integrate an own within Zend_Date which caused the problems that now occur.

{quote}Thus, for developers that use multiple functions in Zend_Locale_Format, the current approach requires far more duplication by repeatedly supplying the same arguments to the Zend_Locale_Format static methods. If the developer could create an object, and set the properties as needed, the object would then remember the state/arguments for use with the many methods in Zend_Locale_Format.{quote}

The repeatedly supplied parameters are not part of this issue... we should not throw additional functionallity into another issue even if it's the same class.

Posted by Matthew Ratzloff (mratzloff) on 2007-03-06T16:17:41.000+0000

Although I still question the need for PHP date formatting, I agree with Gavin about the API changes. I much prefer having an object which I can manipulate once than pass arguments repeatedly. Generally, the only variable that changes is the input format; therefore, I think that should continue to be allowed (but not required) as an argument.

While you're changing the API, you might rename it to Zend_Locale_Formatter, too.

Posted by Thomas Weidner (thomas) on 2007-03-06T16:48:06.000+0000

{quote}Although I still question the need for PHP date formatting,{quote}

What do you mean here ?

Initially I only implemented ISO format tokens because Zend_Date only accepts ISO... I was told to implement also PHP, which is useless in my eyes because we do not have a strict php format but we extended it with localized outputs... all monthnames for example are localized.

{quote}I much prefer having an object which I can manipulate once than pass arguments repeatedly.{quote}

The mentioned feature here is not part of this issue. I already mentioned this in an earlier comment. We should not throw several issues together into one proposal. These are growing very fast even if we have only one discussed issue, because Gavin and I are normally heavily discussing pro's and con's... :-)

And as I also mentioned before... it's not needed to have an object for setting standard parameters.

{quote}Generally, the only variable that changes is the input format; therefore, I think that should continue to be allowed (but not required) as an argument.{quote}

All parameters except the input string are optional and are not required.

How ever... how often would this internal functions of Zend_Locale be needed by users ? I think almost only one user from 100 is using Zend_Locale_Format... and they are only using the isNumber/getNumber functions because Zend_Validate can not handle localized inputs until now. All other users will only use Zend_Date for date handling.

{quote}While you're changing the API, you might rename it to Zend_Locale_Formatter, too{quote}

Sorry, but I am not allowed to change already cored functions without a decission from the devteam itself. Also having the class named "Formatter" implies a wrong useage of this class... but this is only my private opinion.

Posted by Gavin (gavin) on 2007-03-06T17:30:45.000+0000

Supporting setOptions() to alter a static "class" variable ($_Options['format']) in Zend_Locale_Format solves Case A and B below. Supporting setOptions() also made visible an underlying issue. I think Matthew nicely summarized that issue. I'm not sure we need to start another Jira issue.

After carefully considering all of the options above, I think the simplest and quickest solution available for ZF 0.9 is: 1) keep the setOptions() methods introduced to help address this Jira issue 2) add an optional parameter, "$formatType = null", to appropriate methods in Zend_Locale_Format 3) the methods in 2) could use a default format type as set by 1)

Use Cases (in probability of occurrence) Case A) Thus, if an application uses only ISO format strings, no extra userland code is needed. Case B) If an application uses only PHP format strings, then a single call to "Zend_Locale_Format::setOptions(array('format' => 'php')); is needed. Case C) If an application uses both, then the $formatType parameter may be used.

Thoughts? Ideas? Anyone?

We all greatly appreciate the effort, dedication, and ideas like 2) above that you have contributed to the i18n components, Thomas :) Soon, a very large number of PHP developers will be using these components!

P.S. My personal preference almost always goes to using normal objects that can be instantiated and manipulated using instance methods, but some have shown static methods can be convenient, such as with the ZF registry. Compromises exist throughout any framework because of coding standards, conventions, performance optimizations, and constraints like the format of the CLDR data and past design decisions. Thus, I recognize that theoretical ideal solutions may not apply or be "ideal" for particular situations.

Posted by Thomas Weidner (thomas) on 2007-03-07T02:35:57.000+0000

I also like using objects because they have much advantages... but sometimes it is not practicable to use them, and in my opinion this case is one of these.

  1. was already included into the core several days ago, so this part of the issue works already, is tested and documented. :-)

  2. I know that having a forth parameter is not so nice because of the additional parameter itself, but it is optional and these functions will not be used so much by users, because Zend_Date does all the work :-) The number formatting functions which will be used much more, are not in need of this additional formattype parameter.

  3. As I already wrote earlier, if null is set (which is standard) the default setting is used, but it can be overwritten per hand and Zend_Date.

But there is another way to solve this problem without having an additional parameter...

We could accept an array for the format parameter.

actual way :

<pre class="highlight">
Zend_Locale_Format::setOption('format' => 'php', 'precission' => 2);
Zend_Locale_Format::getDate('2007-03-20', 'Y-m-d');

proposed change :

<pre class="highlight">
// old way works as before
Zend_Locale_Format::setOptions('format' => 'php');
Zend_Locale_Format::getDate('2007-03-20', 'Y-m-d');

// new way for overriding format by Zend_Date
$input = array('type' => 'iso', 'format' => 'YYYY-MM-dd');
Zend_Locale_Format::getDate('2007-03-12', $input);

// this also works
Zend_Locale_Format::setOptions('format' => 'php', 'date' => 'Y-m-d');
Zend_Locale_Format::getDate('2007-03-12');
Zend_Locale_Format::getDate('2006-02-17');

We would not have to add an additional parameter, and the array would allow Zend_Date to override the set settings for the format.

Thoughts, Ideas ??

Posted by Gavin (gavin) on 2007-03-07T13:45:40.000+0000

The array approach above is not tool-friendly. How about we stay with the 1), 2), 3) approach above to solve the A), B), C) use cases?

Posted by Thomas Weidner (thomas) on 2007-03-07T15:02:32.000+0000

{quote}The array approach above is not tool-friendly.{quote}

Then the setOptions() method is also not tool friendly. :-) And I think there are several methods accepting input arrays which are not "tool-friendly".

I didn't want to be "tool-friendly". I only wanted to show a method which does not need an additional parameter which is actualy only needed by Zend_Date because I once heared from the devteam that we have to implement as less parameters as possible.

Personally I would have no problem with adding an parameter. But I would like to hear other opinions pro & con accepting an array as full parameter additionally to accepting several parameters. Because we would not have to add an additional parameter with the new approach. As the old way also works the "tools" should have no problem with it.

WAY 1: Add an additional parameter for allowing override the formattype for Zend_Date

<pre class="highlight">public static function getDate($date, $format = null, $locale = null, $formattype = null);

$date = Zend_Locale_Format::getDate('2007-02-20', 'Y-m-d', 'en', 'php');

WAY 2: Accept additionally an array as first parameter to allow override the formattype for Zend_Date

<pre class="highlight">public static function getDate($date, $format = null, $locale = null);

$options = array('date' => '2007-02-20', 'format' => 'Y-m-d', 'type' => 'php', 'locale' => 'en');
$date = Zend_Locale_Format::getDate($options);
// the actual implementation also works but without overriding the type
$olddate = Zend_Locale_Format::getDate('2007-02-20', 'Y-m-d', 'en');

I prefer WAY 2 because it does not complicate the actual standard useage. You would set the options array within setOptions() and can give it also directly to the method to override the standard settings for this single method call. I would see an benefit by the useage of the same array as for setOptions().

Posted by Gavin (gavin) on 2007-03-07T15:21:34.000+0000

{quote}Then the setOptions() method is also not tool friendly. And I think there are several methods accepting input arrays which are not "tool-friendly" {quote}

True, but I wouldn't try to use that as a reason to justify the use of arrays in this case.

In effect "WAY 2" becomes a peculiar way of collecting the state of an object into an array, and passing the state to a method, instead of the traditional object-oriented approach of invoking methods on objects.

I think all other occurrences of passing option arrays in the ZF currently do not mix both WAY 1 and WAY 2 (e.g. see Zend_Db, Zend_Session, etc.), since they have no additional optional arguments after the $options parameter. In "WAY 2" above, $date may be either a string or an array, but additional optional parameters overlap in meaning and use with $date (when $date is an array). I find this usage likely to confuse developers and result in problems (e.g. same option specified in two places).

Posted by Thomas Weidner (thomas) on 2007-03-08T13:29:50.000+0000

Well, if mixing of the parameters is a problem...

How about only accepting an array for the options as it is done by Zend_Cache, Zend_Config, Zend_Session and so on.

Because in my opionion it's not so good to have that much parameters. Setting the options once with an array and changing or overriding them also only with an array seems to me the best way.

If we have to add another option in future additionally to the existing 5 it would be no problem.

<pre class="highlight">public static function getDate($date, $options = null);
public static function getTime($time, $options = null);
public static function toNumberFormat($value, $options = null);
public static function getNumber($input, $options = null);

In this state it would be no problem to make this change...

We would have no problem with array/non array as mentioned above. We have no problem if we have to add additional parameters in the future. We can make this change only until code freeze of 0.9. We would not confuse developers because all options are given the same way... for setOptions and for the detail functions as array. The input itself has to be given as string. All options, which of course are optional :-) , could be set with setOptions or by giving an options array.

In my opinion this would fit perfectly in the API of Zend_Locale_Format.

Posted by Gavin (gavin) on 2007-03-08T14:20:55.000+0000

I think using only $options, instead of having many optional parameters, is more object-oriented. The state of the object consists of everything in $options (i.e. $options is almost equivalent to $this). Object instantiation becomes creation of the array. Object persistence is accomplished by saving the array somewhere for later use.

The non-optional argument corresponds to the input data for the "method" (i.e. static function).

Yes, I agree, there are fewer complications using arrays as shown in your comment above :)

Posted by Thomas Weidner (thomas) on 2007-03-08T14:35:00.000+0000

Great that we have found together once again ;-)

Issue-Production is now progress :-)

Posted by Gavin (gavin) on 2007-03-08T14:47:10.000+0000

Looking at the recent changes to Zend_Registry, there is one concern I have resulting.

If we ever decide to add support for instantiating Zend_Locale_Format objects, the names of the instance methods can not be the same as the static methods. After ZF 0.9, the API is "frozen" and will be difficult to change before ZF 1.1. Perhaps we can now think ahead about naming these static functions and instance functions.

Posted by Thomas Weidner (thomas) on 2007-03-08T15:13:22.000+0000

I thought that we have already cleared not to make Zend_Locale_Format an object.

The actual functions are doing what their names are saying. If we decide to discuss another possible future API change we will not get ready for 0.9.

getDate / isDate - date normalizing getTime / isTime - time normalizing getNumber / toNumber / isNumber - generic number localization/normalization getInteger / toInteger / isInteger - same as above but without any precision getFloat / toFloat / isFloat - same as number

Time / integer and Float are only added for simplicity.

To what simpler name would you want to change these ???

Btw: We could eliminate the getCorrectableDate() functions and just use an option 'fixit' or 'correct' instead.

Posted by Gavin (gavin) on 2007-03-08T15:48:20.000+0000

Yes, no objects for now. I was talking about the future, "if we ever decide to add ...". If ZF 1.1 adds the ability to instantiate Zend_Locale_Format, what names would we use for the non-static methods?

Btw, yes I also like your "Btw" :) .. since we are moving to using an $options array, I think it makes sense to make getDate/getCorrectableDate functionality selectable via the $options array. What about "enableDateCorrection"? It is a long name, but has a clearer meaning.

Posted by Thomas Weidner (thomas) on 2007-03-11T08:05:55.000+0000

Fixed with SVN 3867.

Posted by Gavin (gavin) on 2007-03-19T17:52:30.000+0000

I'm committing a unit test to help track progress with some of the changes discussed below. {quote} -------- Original Message -------- Subject: Re: [fw-i18n] setOptions() - format option, opinions wanted Date: Tue, 13 Mar 2007 21:15:58 +0100 From: Thomas Weidner thomas.weidner@gmx.at To: Gavin Vess gavin@zend.com CC: ZF I18n fw-i18n@lists.zend.com, matt@builtfromsource.com

Option 1)

Attempting to set a default, class-wide date format or number format results in an exception. For example, Zend_Locale_Format::setOptions(array('format' => 'y-M-d H:m:s')); causes an exception.

Looks good. Would of course only throw an exception for "dateformat" not for "numberformat".

Option 2)

$locale = new Zend_Locale('de_AT'); Zend_Locale_Format::setOptions(array('format' => 'y-M-d H:m:s')); $date = Zend_Locale_Format::getDate('13.04.2006', array('format' => Zend_Locale_Format::useDefault, 'locale' => $locale));

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Thus, in getDate(), if the 'locale' option is given, the class-wide default 'format' (i.e. date format string) is ignored, unless the developer specifically requests it using: 'format' => Zend_Locale_Format::useDefault

Also looks good. But this way I would say if a format is given within setOptions and only a locale is given within getDate an exception should be thrown. Because the function would not automatically know what the user wants.

So: Zend_Locale_Format::setOptions(array('format' => 'YmD')); Zend_Locale_Format::getDate('2007-04-05', array('locale' => 'de'));

throws an exception

Zend_Locale_Format::setOptions(array('format' => 'YmD')); Zend_Locale_Format::getDate('2007-04-05', array('format' => Zend_Locale_Format::DEFAULT, 'locale' => 'de'));

works and uses locale standard definitions ignoring 'YmD'

Zend_Locale_Format::setOptions(array('locale' => 'de')); Zend_Locale_Format::getDate('2007-04-05', array('format' => Zend_Locale_Format::DEFAULT)); Zend_Locale_Format::getDate('2007-04-05', array('format' => 'YmD'));

These 2 lines also work.

If 'locale' is not present in the options, then the following works, and seems to have some usefulness: $locale = new Zend_Locale('de_AT'); Zend_Locale_Format::setOptions(array('date_format' => 'y-M-d H:m:s', 'format_type' => 'php')); [fixed from email] // use the class-wide default date format of 'y-M-d H:m:s' $date = Zend_Locale_Format::getDate('13.04.2006');

I could live with both as both are API conform. The first is easier. But I think the Options 2 with the exception included should do perfect.

-------- Original Message -------- Subject: Re: [fw-i18n] setOptions() - format option, opinions wanted Date: Tue, 13 Mar 2007 23:25:05 +0100 From: Thomas Weidner thomas.weidner@gmx.at To: Gavin Vess gavin@zend.com, ZF I18n fw-i18n@lists.zend.com

Yup, I purposely committed the code allowing the existing class-wide default 'format' to be set, and promptly posted an example of the related issue to the list. This gives others a chance to participate in design and API changes and easily test. Usually we post these discussions directly to Jira issues for the i18n components.

From the feedback so far, it sounds like splitting 'format' into 'dateFormat' and 'numberFormat' is agreeable to all.

This is already in work by me, additionally with other small tweaks.

Ok, so far I like Thomas' version of Option 2 best :) .. with one minor tweak to the naming of the constants:

Use Case A

Zend_Locale_Format::setOptions(array('dateFormat' => 'YmD'));

// use default date format specifier for locale "de" Zend_Locale_Format::getDate('2007-04-05', array('dateFormat' => Zend_Locale_Format::LOCALE, 'locale' => 'de'));

// use the class-wide default date format "YmD", but use "en" for recognizing any day or month names in the input string: Zend_Locale_Format::getDate('2007-April-05', array('dateFormat' => Zend_Locale_Format::DEFAULT, 'locale' => 'en'));

// throws an error, since class-wide default 'dateFormat' of "YmD" makes the following ambiguous: Zend_Locale_Format::getDate('2007-April-05', array('locale' => 'en');

Use Case B

Zend_Locale_Format::setOptions(array('locale' => 'de'));

// use the default date format specifier for locale "de" Zend_Locale_Format::getDate('2007-04-05', array('dateFormat' => Zend_Locale_Format::DEFAULT));

// use the user-supplied date format specifier "YmD" with the locale "de" to recognize any day or month names in the input string: Zend_Locale_Format::getDate('2007-Mai-05', array('dateFormat' => 'YmD'));

This is what I have in mind and what I am actually working on :-) {quote}

Posted by Till Klampaeckel (till) on 2007-03-27T12:10:23.000+0000

If a method or function is removed, the documentation should be updated accordingly.

http://framework.zend.com/manual/en/… (Example 8.11)

Posted by Bill Karwin (bkarwin) on 2007-03-27T12:29:11.000+0000

Thomas, can you please review the appropriate documentation to make sure it covers the changes?

Posted by Thomas Weidner (thomas) on 2007-03-27T13:16:39.000+0000

The related chapter is actualy being rewritten and will be avaiable with the next release. All new and changed functions are also always documented.

Sometimes when releases are made they cross with work which is actually done... the latest what we do is always the documentation. So please dont be angry just because we are not completly ready with what we do in our sparetime.

Have you found an issue?

See the Overview section for more details.

Copyright

© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.

Contacts