Re: Date time classes for new Wonder frameworks
Re: Date time classes for new Wonder frameworks
- Subject: Re: Date time classes for new Wonder frameworks
- From: Chuck Hill <email@hidden>
- Date: Fri, 19 Oct 2012 18:22:53 -0700
On 2012-10-19, at 5:50 PM, Pascal Robert wrote:
>
> Le 2012-10-19 à 20:04, Paul Hoadley <email@hidden> a écrit :
>
>> On 20/10/2012, at 9:21 AM, Pascal Robert <email@hidden> wrote:
>>
>>> I'm working on ERGroupware, and I was wondering if I should use NSTimestamp. I started using it to make it more "WO friendly" but I have to fu**ing convert everything because the dates for ical4j, Zimbra and MS Exchange expect a java.util.Date or java.util.Calendar, hence the need to create or convert NSTimestamp.
>>>
>>> So the question: for new frameworks that will go in Wonder, should we keep using NSTimestamp or should we use something else?
>>
>> If you're talking about code internal to your new framework, then presumably it doesn't matter. But if it's code that's going to interface with existing frameworks, aren't you creating an interoperability problem given that every existing framework uses NSTimestamp? What am I missing here?
>
> It's mainly « external ». The thing is that I have classes that regroup all attributes of a iCalendar file, an appointment or task in Zimbra (SOAP API) or Exchange Web Services. Of source, those 3 sources use different date time classes… And I end up with things like:
>
> NSTimestamp eventStartDate = event.startTime();
> Calendar startDate = GregorianCalendar.getInstance();
> startDate.setTime(eventStartDate);
> calendarItem.setStart(startDate);
Just also expose the equivalent java.util.Date or java.util.Calendar as well:
Calendar startDate = GregorianCalendar.getInstance().setTimeInMillis(event.time().getMillis());
calendarItem.setStart(startDate);
>
> But the question is mainly about if we should move away from NSTimestamp in new frameworks for Wonder, or should we move to something else, for « exposed » date time attributes (that is, attributes that would be editable in a WOTextField, by REST, etc.).
I'd avoid NSTimestampFormatter, but I don't see that it is practical to get rid of NSTimestamp.
Chuck
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/gvc/practical_webobjects
Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest Growing Companies in B.C!
Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of Canada’s Fastest-Growing Companies by PROFIT Magazine!
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden