#35 Calendar not working outside en_EN

[Mike R. Haller]

In woko-web\src\main\webapp\WEB-INF\tags\woko\dateTextField.tag

sdf.toLocalizedPattern() returns a, well, localized date pattern, but the code using it demands a pattern using "d", "m" and "y" for the fields. Hence, plain toPattern() should be instead:

final SimpleDateFormat sdf = new SimpleDateFormat();
// e.g. tt.MM.uu HH:mm in Germany
javaPattern = sdf.toPattern();

Also, the conversion hardcodes the "/" delimited to be used in the UI date fields.

[Remi Vankeisbelck]

Logged In: YES
user_id=1129612
Originator: NO

Hi Mike,

Yeah the calendar has been integrated long ago, quick and dirty probably, and has a few quirks with localization. I vaguely remember lamely hacking it so it works for en and fr :-/

Have you tried your fix in the trunk ? Could you send a patch ?

PS : There are no tests at all for the calendar, so manual testing is required yet (we should write webtests for the calendar, but I don't know how to test JavaScript with canoo...).

[Mike R. Haller]

Logged In: YES
user_id=362167
Originator: YES

File Added: woko1817465-Calendar-i18n.patch

[Mike R. Haller]

Proposed patch for Calender Format conversion

[Mike R. Haller]

Logged In: YES
user_id=362167
Originator: YES

extracted the conversion of Java-Date-Format to JavaScript-Date-Format into web-core/../ConverterUtil
hardcoded delimiter "/" not fixed by woko1817465-Calendar-i18n.patch

[Remi Vankeisbelck]

Logged In: YES
user_id=1129612
Originator: NO

Hi Mike,

Excellent :-)

The unit test fails on my host, probably because we have different locale settings. There's the stack :

junit.framework.ComparisonFailure:
Expected :%d/%m/%y
Actual :%m/%d/%y
at net.sf.woko.util.ConverterUtilTest.testDatePatternToJavaScript(ConverterUtilTest.java:14)

As you can see it looks like my "english" system doesn't accept the same "defaults" than you do...

In the tag, null is always passed on to the conversion routine, I checked with a Paper object if it was still working, and it does with my en locale.

Thereby I have commited your patch, excepted that I commented out the failing assertion in the unit test.

Do you think this stuff will cause some problems ?

Thanks for the patch !

Cheers

Remi

[Mike R. Haller]

Logged In: YES
user_id=362167
Originator: YES

Hi Remi,
i added the parameter and its null-default, so it can be easily localized correctly later, e.g. based on the users locale.
The current implementation uses null, which means it will use the server's locale as fall-back.

Hm, i just double-checked it and yes, it will cause problems. I'm currently rewriting the thing and will also provide a testcase with a reference implementation from another web project. Who parses the date from the form field and injects it into the java property? Is this the Stripes binding? If so, how does he know how to parse the JavaScript Calendars date format?

Haven't looked at canoo yet.

[Remi Vankeisbelck]

Logged In: YES
user_id=1129612
Originator: NO

Yeah, it's Stripes that performs the binding of form fields on target objects on the server. To do so, it uses the user's browser's locale, not the server's...

We could have Stripes parse any format (it has a pluggable conversion mechanism), nevertheless, the idea is that the calendar should writs its value in the input field according to the user's locale...
The calendar simply allows to fill the input field : when a date is picked by the user, the calendar simply writes its "value", formatted, to the relevant input. So I guess the main issue is to know the browser's locale and use it for JS date conversion.

What do you think ?

PS : for canoo it's not a problem right now... The calendar is a non blocking feature, so it does not really deserve to be highly tested for the moment. But I'd like to add more tests while we do some dev on the project, it's way less painful than writing all tests at once ! And I sleep much better since I started adding some webtests to the project : at least I know when something very important is screwed up ;-)

[Mike R. Haller]

Logged In: YES
user_id=362167
Originator: YES

Well, you're right, i too think that the user wants to see *his* date format in the web browser/input field. Just for my understanding: we define the date format to be used in the calendar, as we (on the server-side) know the locale of the user. But this is just the first phase, e.g. how to display the date in the browser. I don't know where the parsing is done and I assume that Stripes is doing that under the hood and hopefully uses the same locale-pattern for the date for parsing. I just want to make sure that this is not going to be out-of-sync between how we set up the JSCalendar and how Stripes is parsing it. When both use the same format, e.g. the default one of the users locale, it's fine.

So, the ConverterUtil.parseJavaDateFormat() must return the date format for the users locale.
How do I get the current user's locale from within a JSP page?

If this is done, the ConverterUtil takes care of translating the Java format into the JavaScript format.

[Remi Vankeisbelck]

Logged In: YES
user_id=1129612
Originator: NO

I've had a closer look at this localization stuff, and I understand better why I dropped this for more important features at the time I integrated the calendar :-)

Here's the flow, when a Date property has to be rendered :
1/ the EditPropValueDate facet is invoked, so the "/WEB-INF/woko/fragments/edit/simpletypes/prop-date.jsp" gets
included.
2/ prop-date.jsp simply calls the dateTextField tag, passing it :
* the name of the field (not a problem here)
* the id of the field for JS correlation (not a problem here)
* the formatType : date, time or datetime (look at the stripes:text doc for more infos), depending on
the annotation(s) found on the field (not a problem here)
3/ the dateTextField tag displays an input via stripes:text. If the value is not null, it gets
pre-displayed and nicely formatted to the user's locale.
Then, the JS nightmare begins... we need a suitable format for the JSCalendar !

I'm currently looking at the docs:
http://www.dynarch.com/demos/jscalendar/doc/html/reference.html#node_sec_2.3

More to come later...

[Mike R. Haller]

ConverterUtilTest added daFormat-conversion tests

[Mike R. Haller]

Logged In: YES
user_id=362167
Originator: YES

File Added: ConverterUtilTest.java

[Mike R. Haller]

[Mike R. Haller]

Logged In: YES
user_id=362167
Originator: YES

File Added: ConverterUtil.java