I need to create a PDF with a date field that displays dates in the format dd.mm.yyyy. This field must be validated and should also accept inputs in other formats.
For example, users should be able to input dates in the form dd.mm.yy, which will then be expanded to dd.mm.20yy (MS Office apps like Excel do this).
Alternatively, selecting multiple valid formats would be an acceptable solution.
What currently happens:
If the date format of the field is set to dd.mm.yyyy, dd.mm.yy is rejected.
If the date format of the field is set to dd.mm.yy, dd.mm.yyyy is accepted (but formatted to dd.mm.yy).
The last behaviour is almost what i need, just with the wrong format.
Is there a way to do this without custom Javascript? If not, is there a way to still use the built-in formatting or do i have to rewrite everything in JS?
Unfortunately this is not achievable with Acrobat's built-in formatting.
One thing to add to your second bullet point: it trims the date down to .yy when you exit the field, but it still retains all four digits. When you click into the field, it will revert back to being .yyyy. That may or may not matter depending on how you're using it.
Regarding a custom validation, a quick Google search will yield an abundance of Javascript date validation scripts. Something like this could probably be quickly repurposed for your application.
Related
I'm not talking about using the parameter in the data template - I'm all set there. I need to know how to change the format of a parameter once it hits my RTF template.
I have
<?param#begin: p_Date?>
<? $p_Date?>
This gets my parameter from the report request page onto my report. However, I can't seem to alter the format. I'm sure I just need to understand how to access it, but I'm not that familiar with BI Publisher. I know I can alter the format on the request screen, and that flows through, but I need to alter it on the end result. Can anyone help?
Ok, I finally found it. You can use the format_date function; the documentation is a little sparse. My syntax looks like this:
<?xdoxslt:format_date($p_Date, 'MMM yyyy','MM-dd-yyyy', $_XDOLOCALE, $_XDOTIMEZONE)?>
The first parameter is the target format, the second is the input mask. The second can be overridden to use a specific l18n style.
I am trying to create a Fetch Request, not in code, but by using the Core Data Model Editor, to get all Book objects that have no value for the date attribute.
I tried various ways to specify this. One example as...
...however, when I leave and return back to the data model editor, Xcode has changed it to this, where the date is today's date...
If this is just a limitation of the model editor, and doing it in code is the only way, then so be it. I'm just trying to be consistent since all of my other fetch requests have been done in the model editor, and have not been a problem to define.
Aaah, this is almost a philosophical issue. nil is simply not a valid date, so it should not be in the predicate. There is a simple workaround, though:
Initialize your date to some extreme value, and check for that value (or if the date is beyond that value).
I also noticed that perhaps in the editor it is just a display thing. If you toggle the switch in the upper right corner (Editor/Expression view I guess) you will see that the query has not changed, even if in one view today's date is displayed.
Therefore it might just work anyway. In this case it is just a display bug.
Recently,I am handling a solution for WebPart internationalization,but I am not familiar with the culture or habits in different regions.So I am asking for some information if you are glad to help.
Suppose I am a different person in another region,for example,a German.I am using the SharePoint,which is a German edition.So,
1) What's the input habit of me?
For example,if I need to input "10000",will I input "10.000,00" or just "10000"?Which is frequent to the user?
2) How to handle the "Date" and "Time" format?
I think it's better if I can select the date or time instead of inputing the date or time string.
3) Any information that you think will be helpful to me?
That is very kind of you,thanks for your help!
To be honest, I am not sure how you want to handle i18n, but I am assuming that you want to do this on the client side.
In this case, I can recommend using Globalize for formatting (both numerical values and date/time could be handled this way).
As for parsing dates (that is handling dates provided by user), there is actually even easier way - just use jQuery UI Datepicker with valid regional script. Obtaining Date object is as easy as calling Datepicker's getDate method.
I am having a problem with an MVC3 application using a jQuery UI DatePicker object.
Within the MVC application, I ask the user to pick their required culture, i.e en-GB, which then formats all dates and currencies in the application in the british format.
I can then access the formatter code for this via Thread.CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern
However, the format returned for UK dates is: dd/MM/yyyy
To format the resulting data from the jQuery UI datepicker, I need to specify a date format. But for UK format dates, I need to specify the format as dd/mm/yy
The simple solution would be to just use Thread.CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern in my jQuery calls to format the date, but obviously this gives a formatting inconsistency as this is interpreted differently by jQuery UI (01/December/20112011 instead of 01/12/2011)
Is there any easy way around this?
The only way I can think of doing it is asking the user twice what format to display dates in?
I could think of another solution, but that's pretty low-tech, I'm not sure if that is the right way to do it:
var dateTime = Thread.CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern;
var lowerCaseMonths = Regex.Replace(dateTime, "MM","mm");
var yearOnlyOnce = Regex.Replace(lowerCaseMonths, "yyyy", "yy");
Without "explaining variables" just
Regex.Replace(Regex.Replace(Thread.CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern, "MM","mm"), "yyyy", "yy")
Then I guess no matter in what format it is, dd/MM/yyyy MM/DD/yyyy dd-MM-yyyy etc, it should work out in jQuery.
Maybe someone has a better solution, but at least this seems better than asking for user input twice.
#System.Threading.Thread.CurrentThread.CurrentCulture.DateTimeFormat.ShortDatePattern.ToLower().Replace("yyyy", "yy")
When using JSON to populate a section of a page I often encounter that data needs special formatting - formatting that need to match that already on the page, which is done serverside.
A number might need to be formatted as a currency, a special date format or wrapped in for negative values.
But where should this formatting take place - doing it clientside will mean that I need to replicate all the formatting that takes place on the serverside. Doing it serverside and placing the formatted values in the JSON object means a less generic and reusable data set.
What is the recommended approach here?
The generic answer is to format data as late/as close to the user as is possible (or perhaps "practical" is a better term).
Irritatingly this means that its an "it depends" answer - and you've more or less already identified the compromise you're going to have to make i.e. do you remove flexibility/portability by formatting server side or do you potentially introduct duplication by doing it client side.
Personally I would tend towards client side unless there's a very good reason not to do so - simply because we're back to trying to format stuff as close to the user as possible, though I would be a bit concerned about making sure that I'm applying the right formatting rules in the browser.
JSON supports the following basic types:
Numbers,
Strings,
Boolean,
Arrays,
Objects
and Null (empty).
A currency is usually nothing else than a number, but formatted according to country-specific rules. And dates are not (yet) included in JSON at all.
Whatever is recommendable depends on what you do in your application and what kind of JScript libraries you are already using. If you are already formatting alot of data in your server side code, then add it there. If not, and you already have some classes included, which can cope with formatting (JQuery and MooTools have some capabilities), do it in the browser.
So either format them in the client or format them before sending them over - both solutions work.
If you want to delve deeper into this, i recommend this wikipedia article about JSON.