[
https://issues.apache.org/jira/browse/TAPESTRY-2198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572467#action_12572467
]
Davor Hrg commented on TAPESTRY-2198:
-------------------------------------
I agree with these ideas, as I've also implemented less strict date parsing in
some apps it felt more productive to enter adtes that way.....
my proposal is not restricting the formats to catalog, the parameter should
stay,
but setting default format in catalog so it is different for different locale,
and not having date format hardcoded into datefield.
Because, currently to have consistent date behavior I need to override too many
things.
to summarize:
default date behavior should depend on locale,
date format should be overridable (so user specific setting can apply)
datefield shold still have format parameter
to smmarize: dates are used in following:
server output
server-datefield encodes for client
client-datefield decodes to display calendar
client-datefield encodes selected date
cleint-form validates date (onchange event could be used to enable less strict
date input, or a tapestry function overriden)
server-form validates input
server-datefield decodes value
maybe date formating should be made a service, so user settings overrides can
be implemented.
> Date formating global support
> -----------------------------
>
> Key: TAPESTRY-2198
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2198
> Project: Tapestry
> Issue Type: Improvement
> Affects Versions: 5.0.11
> Reporter: Davor Hrg
>
> there is a javascript implementation of
> SimpleDateFormat and is apache 2.0 licensed
> http://www.timdown.co.uk/code/simpledateformat.php
> it implements most of:
> http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html
> It is 8.7 Kb with stripped comments.
> I'm looking at making a trimmed down version that can parse/format only
> numeric date parts : day, month, year, dour, min sec.
> This covers most likely usages on the client side (forms and datefield) and
> would make shorter code.
> (I feel that prototype is bloated already so another 10K does not look
> apealing)
> Not to complicate things and optimize too soon, full lib can be used now,
> and later along with "multiple js lib support" the short version should be
> made available and pushed as default.
> while talking about dates... date format should be in message catalog so it
> is locale specific.
> for example in my language date format is: dd.MM.yyyy
> there should be different keys for server side format and client side format
> (the formats should be compatible of course)
> tapestry-date-format-server=MM/dd/yyyy
> tapestry-date-format-js=MM/dd/yyyy
> (which are sam in case we use forementioned lib)
> or, if one would choose to use the former date picker i would be:
> tapestry-date-format-server=MM/dd/yyyy
> tapestry-date-format-js=%m.%d.%Y
> I feel strongly about this being global key instead parameter for
> datefield, but even if it is only for date-field there should be two formats
> (server and js)
> in the end... the formater should be used to test validity for the field on
> the client side
> or regexp added to message catalog
> tapestry-date-format-js-regex=...complex or simple regex......
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
