Always happy to help open up cans of worms :-)
I ended up with a simplistic utility class with a private no-arg
constructor and a few static methods for the particular conversions I
needed to do. Not sure if there's a "Groovy best practices" approach to
this, but I didn't need anything more sophisticated in my case. Please
share what you end up doing. Cheers,
-H
On 5/9/16 5:20 PM, Gerald Wiltse wrote:
Thanks for the feedback Henrik! You've led me to a new can of worms,
to see if Oracle and the JodaTime guys made any accomodations for
handling JD Edwards time formats in JSR 310. Probably not, but now i
have to find out.
The core strategy I'm asking about is how to approach the inevitable
custom broker/wrapper classes or methods which always need to exist in
the middle. Classes or methods which take the data as it comes into
the app, and prepare it for the API's of libraries, and then do
something useful with the output.
Regards,
Jerry
Gerald R. Wiltse
[email protected] <mailto:[email protected]>
On Mon, May 9, 2016 at 8:02 PM, Henrik Martin <[email protected]
<mailto:[email protected]>> wrote:
What about creating a few utility methods around the standard Java
8 time/date classes already available in the JDK? I've had to do
some date conversions myself recently, and found everything I
needed in java.time.*. It seems to me like your task is mostly a
format conversion. If so, the various DateFormatter classes are
probably sufficient. Also, take a look at the jchronic stuff for
natural language processing of date/time:
https://github.com/samtingleff/jchronic
http://mvnrepository.com/artifact/com.rubiconproject.oss/jchronic
Cheers,
-H
On 5/9/16 4:29 PM, Gerald Wiltse wrote:
Also, something else just occurred to me which might be relevant.
Another option might be to create a JDE Calendar or JDE Date
class which extends or implements date or calendar
classes/interfaces. My first instinct was to convert dates into
Date Objects and strings based on Gregorian calendar on their way
in and out of the database (because that's what I'm somewhat
familiar with). However, might it be more natural to write
classes that let me handle them in their native form without
converting? Maybe thats a more complicated endeavor.
Gerald R. Wiltse
[email protected] <mailto:[email protected]>
On Mon, May 9, 2016 at 7:04 PM, Gerald Wiltse
<[email protected] <mailto:[email protected]>> wrote:
All,
In summary, I would like any advice people can offer on how
to approach the task below, using the Groovy ways of thinking.
The topic at hand is a messy domain-specific problem working
with dates in Oracle's ERP software called JD Edwards. It's
gory detail is documented here:
http://stackoverflow.com/questions/1171208/what-is-the-precise-definition-of-jdes-julian-date-format
I wish to write my own solution in Groovy. A flexible
swiss-army-knife type package which lets me pass JDE and
Gregorian dates and times (as strings) in and out and define
what I get back. I am not looking for code, but help
escaping the procedural mindset. The one senior Java
programmer just see's this as a few Static Methods. I want
to know what Groovy developers see.
I'm guessing some combination of closures. Perhaps factory
pattern, which I've never used? Does this sound like a
"Functional programming" scenario, where functional approach
might be a good fit?
I want to start off on the best foot possible, but don't have
the intuition of high-level groovy thinking yet.
Gerald R. Wiltse
[email protected] <mailto:[email protected]>
