How can I validate (a form element in this case) to ensure that the value is a currency?
Have looked at Zend_Validate_Float.
Needs to check that value is between 0 and 2dp.
Ideally locale-aware (as ZVF is) to allow for locale specific formatting (thousands, decimal as comma/dot)
Would also want to extend to allow/disallow negative values
And provide optional upper/lower limits.
Is the key, as I can do 3. and 4. with a chain.
Do I need regex?
AFAIK there is no validator for currency in ZF yet.
You need to write a custom one. See docs for writing custom validators.
Basically, the simplest thing you can do is to normalize input to floating point number (+ currency symbol if you need locale). But correcting user input is not a good solution.
For locale specific formatting you will probably need locale data stored in Zend_Locale_Data. But for comparing input values you will have to write custom currency converter.
Detecting used locale is not so simple, so I'd suggest creating additional select field, for choosing pre-defined format (e.g. locale) and using this value for your custom validator attached to the currency field.
Related
I have a class diagram and have defined an element on this diagram, and created a custom code engineering datatypes type, which allows a fixed width field, for which I want to define a length.
I just can't see where to enter it. The attributes window shows Name, Type, Scope, Stereotype, Alias and Initial Value but doesn't seem to allow anywhere to set the length or precision values.
I want to be able to use this in the report template Att.Length.
I'm sure I've done this before in an earlier version but I can't find where to set this on EA 14.
I'm sure I'm missing something obvious, but I've looked in every properties window I can find.
Thanks for looking! :-)
Length is typically not used with code engineering datatypes, but with database datatypes.
In that case this is intended to be used in database models, and EA will present a different GUI that enables you to edit the length of the datatype.
Technically these field are stored in t_attribute.Length in case of a type such as char, or t_attribute.Precision and t_attribute.Scale in case of a type such as numeric.
There is no (easy) way to fill in these field for regular (non «column») attributes.
I have a problem with 2 lines of code, which don't work as I expect. The point is that the DateTime object is being converted to string and back to DateTime, using default conversion, without explicit format specification.
$timeString = [DateTime]::Now.ToString() # contains 17.01.2017 20:01:30
$time = [DateTime]$timeString # PS blows with error
So, basically, it uses the default date format to format the string, but then it seem to use some other format to parse it back. The following line of code will work, however:
$otherTime = [DateTime]"01/17/2017 20:01:30" # will get the initial date
Could someone point me to proper documentation on the matter of types conversion, and why in this case it would use different formats to convert data back and forth?
Thanks in advance.
Parsing dates is always a nightmare. Especially if you live in the tiny part of the world that is called 'outside US' :)
In general formatting and parsing dates in .NET (and many other things as string comparison) are controlled by culture settings. In some cases then default behavior is to use the current culture settings. Convert.ToDateTime is one of them. If you take a look into the documentation (Convert.ToDateTime Method (String)) it says:
If value is not null, the return value is the result of invoking the
DateTime.Parse method on value using the formatting information in a
DateTimeFormatInfo object that is initialized for the current culture.
The value argument must contain the representation of a date and time
in one of the formats described in the DateTimeFormatInfo topic.
That's why it converts from your localized date string. In other cases the default behavior is to use the 'Invariant Culture' setting which usually means 'US settings'. Most of the methods are overloaded and can take a parameter that specifies the culture that should use, but it requires a little search into the .NET documentation.
As a rule of thumb: Don't use strings that are localized if they are not going to be shown to the end user. Always try to find the 'Invariant Culture' variant of the method, and use it for formatting and parsing of the strings. It will save you from many headaches.
You're implicitly calling Convert.ToDateTime(String), but this method's valid formats are hardcoded (and don't appear to be listed). From your output date format, I see that you're likely not in the US, which is probably what most of the formats are centered towards.
Instead, you can explicitly use Convert.ToDateTime(String, IFormatProvider) to tell it which culture format provider you want.
[Convert]::ToDateTime($timeString, [System.Globalization.DateTimeFormatInfo]::CurrentInfo)
I'm on a US system, so I'm not entirely certain if this will work yet.
You can also use [DateTime]::TryParse() or [DateTime]::TryParseExact() to explicitly specify the format(s) you want.
I have a DateTextField component in my application and I want the input of date using a predefined pattern. The pattern that I need is "yyyy-MM-dd". I created the DateTextField using the following code.
DateTextField dtf_ExpiryDate = DateTextField.forDatePattern("ExpDate", "yyyy-MM-dd");
dtf_ExpiryDate.add(new DatePicker());
It helps to prevent date input in most of other formats. But it accepts input in dd-MM-yyyy format and converts it into some weird format. For example, 12-06-2013 is automatically converted to 0012-06-20.
Is there a way to throw an error when the date is given in dd-MM-yyyy ?
Javadocs of DateTextField says that the conversion is done internally using the Joda time parser. Is there a way to add more constraints ?
I really don't want the data to be captured as String and add a StringValidator to check if it confirms to the pattern using Regex.
Thank you
As far as I know, the answer is NO. DateTextField uses DatePattern or DateStyles internally and it is not possible to enforce stricter rules. If you don't want to use Javascript (custom) or JQuery, you have to use a REGEX to validate the input.
Have a look at here. Use the StrictPatternDateConverter class shown below to enforce a strict validation for the input.
Yep! StringRegExp is a good solution. But another solution could be the use of jqWicket. It provides a MaskedInputBehavior. Take a look at: http://code.google.com/p/jqwicket/wiki/MaskedInputExample
If I'm using this:
DateTime.Now.Date.ToString("yyyy-MM-dd")
FXCop complains that I'm violating CA1305 and says that I should provider an IFormatProvider. Do I need to? I'm asking for the date in a specific format anyway (which is the format I'm expected to put it into the XML as).
Would providing a format provider make any difference? Might it actually produce the wrong results in this case?
Why don't you want to specify the format provider?
If it is just laziness then I can recommend defining two snippets. ic for CultureInfo.InvariantCulture and cc for CultureInfo.CurrentCulture.
Never assume anything about how conversion to string works with the default culture. Not everyone in the world uses the gregorian calendar. Some day you customer might hire a contractor with a computer with another calendar as default and then you are not generating correct XML. Explain then to your customer that you didn't want to follow the FxCop recommendation.
Best thing would be if .Net included a Xml Culture. Then you could just do
DateTime.Today.ToString("d", CultureInfo.Xml)
For some reason Microsoft choose to create a separate class instead XmlConvert. The class has been there since .Net 1.0.
XmlConvert.ToString(DateTime.Today, "yyyy-MM-dd")
will always create a correct Xml date.
Not sure if it is bug or intended behaviour but XmlConvert.ToString(DateTime.Today, "d") will not create a valid Xml date.
so after a bit more research it seems that in my instance it doesn't make any difference, but in the general case months might be displayed in a specific locale.
More details here:
http://msdn.microsoft.com/en-us/library/8kb3ddd4.aspx
In my application I have a setting that can be configured by the user called Date Format. There are a list of formats they can use and when they choose one, all dates in the application and in the reports use that format.
Every time I create a new report I have to create the parameter and link the input control. I just added a new setting, for formatting numbers. I have about 50 reports that I need to apply this to. After going through the monotonous task of adding the parameter and input control to every report I was wondering if there is an easier way.
Is it possible to create a custom global parameter that is automatically available to all reports (Similar to the built in parameters)?
Furthermore, is there a way to tell jasper if a field is of a certain type to automatically do something with it, on a global level. For example if my field type is 'decimal' apply the number format?
Every report has a REPORT_FORMAT_FACTORY parameter that is an instance of net.sf.jasperreports.engine.util.FormatFactory. You should be able to create your class that implements FormatFactory and in the constructor takes what ever you need to determine the correct format. Then add it to the parameters when exporting your report.
You will probably need to play with it, as I am not sure what it passes in for pattern when a value is/isn't set. And if you always ignore the pattern, then when you need to explicitly set it to be the same in all reports it will cause problems.
If I get time tonight, I will try to create an example and see how it works and update my answer, or if you beat me to it, you could post a comment letting us know how it works.