we should write components that work with multiple types.
for example this is what code of a DateLabel might look like:
@Override
public void onComponentTagBody(MarkupStream markupStream, ComponentTag
openTag) {
String body = "";
Object date = getDefaultModelObject();
if (date != null) {
if (date instanceof ReadablePartial) { body = ... }
else if (date instanceof ReadableInstant) { body = ... }
else if (date instanceof Date) { body = ...}
else if (date instanceof Timestamp) { body = ... }
else {
throw new IllegalStateException("Object of type :" +
date.getClass().getName() + " is not supported");
}
}
replaceComponentTagBody(markupStream, openTag, body);
}
we are not using a converter because DateLabel carries a format string
as a property.
such a component is convenient because you dont need to worry if you
are using it with older api that has Date or a newer one that has Joda
we cannot go solely on threeten because version 1.0 is not coming
until jdk8 and only with jdk8.
-igor
On Thu, May 9, 2013 at 12:03 AM, Martin Grigorov <[email protected]> wrote:
> Hi Dan,
>
> I have no much experience with this matter so I cannot help much.
>
> The new Joda-Time is http://threeten.github.io/
>
> Question to other devs: do you think it is OK to migrate wicket-datetime
> module to JDK 1.7 version of ThreeTen for Wicket 7 ?
> I find this task interesting to me so I'll gladly work on it if other devs
> think that the API break is worth it.
>
>
>
> On Thu, May 9, 2013 at 12:46 AM, Dan Retzlaff <[email protected]> wrote:
>
>> Hi all,
>>
>> I'd like to know what conventions you've established for your sites that
>> deal with users in many time zones.
>>
>> Do you simply replace the converters (Date, SqlDate, SqlTime,
>> SqlTimestamp)?
>>
>> Do you avoid MessageFormats in StringResourceModels? (I don't see a way to
>> configure its MessageFormat.)
>>
>> We currently bypass this stuff and do our formatting with application
>> utility methods, and adapting input into users' timezones as manual steps,
>> e.g. with Joda-Time's DateTime#withZoneRetainFields().
>>
>> I'd like to sweep this stuff under the rug with some application-level
>> configuration, e.g. of converters. But before I embark, I was hoping to
>> hear from someone who's already gone on this journey.
>>
>> And related: maybe you have some golden rules time zone handling to share?
>> A couple of mine are:
>> 1. Avoid "date" types in SQL tables because it's hard to correctly compare
>> to "now" across timezones.
>> 2. Anything that shifts millis to adjust for timezones is a red flag
>> (including the aforementioned #withZoneRetainFields() sadly).
>> 3. java.util.Date is evil and you should avoid it whenever possible.
>> Calendar is marginally better, but Joda-Time is the way to go.
>>
>> Thanks,
>> Dan
>>
>
>
>
> --
> Martin Grigorov
> Wicket Training & Consulting
> http://jWeekend.com <http://jweekend.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
