How to set custom date parser on a DateTimeItem via property

[bbaker]

I'd like to try setting the custom date parser at the component level (instead of using DateUtil). In general, I don't know how to accomplish this, is there a particular example on the showcase or some documentation you could point me to on how to accomplish that?

Thanks

[Isomorphic]

You can install an EditValueParser on a DateItem - using the API inherited from FormItem. This is usually for a much rarer situation and we'd recommend the DateUtil APIs instead, but if you are, for example, always generating the code where you use DateItems, it may be similar effort for you.

[bbaker]

SmartGWT Version: v11.1p_2017-10-20/LGPL Development Only

We're currently using a DateTimeItem to do inline editing of dates in a grid. After using the date picker to select a date or manually enter a date string into the text box, an IllegalArgumentException exception is thrown. The exception contains the date string in a format does not match the format of what we've set in the DateUtil API. I thought maybe trying to set the date parser at the component level might yield different results.

I've attempted to reproduce this into a sample the best I could, but (of course) I can't seem to get the sample to exhibit the same behavior. I've attached the sample and the stack trace, could you perhaps take a look, and provide some insight into what the problem could be?

Thanks

[Isomorphic]

When you install a parser you are expected to handle end user input, so just calling DateTimeFormat.parse() definitely won't cut it (even in lenient mode). Your stack trace would result from the user typing just about anything into the editor, in this case, a comma.

Things like missing years just blow up a DateTimeFormat instance, whereas end users would expect reasonable defaulting. Also, if the date is not parsable, you are expected to return null rather than just throw an exception.

[bbaker]

Thanks, we'll harden the code as you suggested. There is still an anomaly though. The exception is being generated for valid date strings. After debugging, I found that the comma is being introduced during form submission. I've attached an image of the stack trace during the form submission phase of my debugging session. The initial date string did not contain a comma, and was already successfully parsed after the date was selected from the picker item. We don't have any formats defined that contain that comma. I believe it's coming from the SmartGWT framework.

Let me know if you need anything from my end to narrow this down. I'll attempt to replicate the submission logic into our sample to see if I can reproduce this.

Thanks again

[Isomorphic]

Your code is setting all the formatters to yyyy/mm/dd, but also setting the inputFormat to "DMY" - the order of the elements should match the input format, so inputFormat should be "YMD".

[bbaker]

That is an issue in our sample code, which was unintentional, but the sample isn't throwing the exception. Our product is, which ensures that the formats match based on configuration. I've debugged through to ensure that the formatters matched the input. The issue still remains, where a comma is getting inserted into the date string when the form is being submitted.

[Isomorphic]

We don't have a reproducible case, and we honestly can't imagine any part of the framework codepath that would introduce a comma - parseInput() is the first time the user-entered date value is processed, and if there were any preprocessing that could add a comma, that would obviously break every user and all of our autotests.

So, the best we can do for now is suggest where in your large application code you could be having this problem:

1. you might have change handlers or other grid-level or formItem-level event handlers or overrides that are manipulating editValues. In particular, maybe you have some code that is intended to act on multi-valued fields that is erroneously firing for date fields too

2. you might have introduced validators, possibly via SimpleType definitions, that transform the input value (eg the transformTo property)

3. you might have tried to "patch" low-level framework code in JavaScript - sounds insane, but we have had multiple customers do this

[bbaker]

Thanks for the information. It helped guide our troubleshooting efforts. Though we were not able to identify the source of the mysterious 'comma' issue, we instead were able to install EditValueParsers on specific DateItems where custom parsing was needed, as you initially suggested.