|
Replies:
16
-
Last Post:
Oct 16, 2007 9:16 PM
by: rturnbull
|
|
|
|
|
|
|
JXDatePicker alternate approach
Posted:
Sep 27, 2007 7:09 PM
|
|
|
I have checked in my first version of the JXDatePicker, using a DatePickerEditor, into my incubator space. I have cribbed somewhat heavily from JComboBox (some comments still refer to the combo box). It is still a work in progress, but the test will display the JXDatePicker, as expected. There are a few focus issues and some actions to hook up, but I am pretty pleased with the rewrite. I wanted to post an early, yet workable version to get feedback on what's being done. I am particularly interested in hearing from the L&F implementors and those who have used custom editors with the current picker. I hope to have a fully working "Basic" picker done by the end of next week and additional core L&Fs done shortly thereafter.
Karl
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Sep 28, 2007 2:59 AM
in response to: kschaefe
|
|
|
Beat me to it - although I was going to create a couple of new components rather than try to adhere to the old one.
Had a few problems getting it running my end. You seem to have used @Overrides annotations when you're actually implementing an interface, not overriding. These wouldn't compile for me, I've probably got a stricter active compilation setting. There's a whole bunch of these I've corrected locally (and thats all) I could check-in for you if you were cool with that.
In BasicDatePickerPopup you've also used a couple of 6.0 only methods, namely getXOnScreen(), getYOnScreen() which stop me from compiling running with 5.0.
..not pointing any fingers (but your ide sucks - spot the IDEA fanboy) 
- Richard
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Sep 28, 2007 4:52 AM
in response to: osbald
|
|
|
> Had a few problems getting it running my end. You
> seem to have used @Overrides annotations when you're
> actually implementing an interface, not overriding.
> These wouldn't compile for me, I've probably got a
> stricter active compilation setting. There's a whole
> bunch of these I've corrected locally (and thats all)
> I could check-in for you if you were cool with that.
Hmm. Eclipse seems to have no way to turn off the @Override for implementations. Yeah, please check those back in as I won't see the issues.
> In BasicDatePickerPopup you've also used a couple of
> 6.0 only methods, namely getXOnScreen(),
> getYOnScreen() which stop me from compiling running
> with 5.0.
I'll solve with 5.0 methods ASAP.
Karl
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Sep 28, 2007 5:46 AM
in response to: kschaefe
|
|
|
> Hmm. Eclipse seems to have no way to turn off the
> @Override for implementations. Yeah, please check
> those back in as I won't see the issues.
Change your compiler settings to 5.0 and they will go away  .
With 6.0 Eclipse introduced @Override for interface method implementations.
Daniel
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Sep 28, 2007 5:53 AM
in response to: kschaefe
|
|
|
> Hmm. Eclipse seems to have no way to turn off the @Override for implementations.
Done that. In the process I noted if I compiled the code under 6.0 it didn't throw compilation errors on these. So I guess the error became a warning under 6.0?
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Sep 28, 2007 5:55 AM
in response to: osbald
|
|
|
Daniel beat me to that observation..
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Sep 28, 2007 8:57 AM
in response to: kschaefe
|
|
|
>> In BasicDatePickerPopup you've also used a couple of
>> 6.0 only methods, namely getXOnScreen(),
>> getYOnScreen() which stop me from compiling running
>> with 5.0.
> 'll solve with 5.0 methods ASAP.
Fixed.
Should now be compilable under 5.0(?).
Karl
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Oct 1, 2007 7:18 AM
in response to: kschaefe
|
|
|
Did you commit this change Karl? I'm still seeing getXOnScreen() on Monday 1st Oct.
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Oct 1, 2007 8:15 AM
in response to: osbald
|
|
|
Oops. I thought I had. I just committed them. Please verify.
Karl
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Oct 1, 2007 8:58 AM
in response to: kschaefe
|
|
|
Yeah I see that - works in 5.0 now.
- Richard
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Sep 28, 2007 7:57 AM
in response to: kschaefe
|
|
|
I found a couple of date/time editors which I had a play with in my TimeEntryDemo in my incubator. That said what bits I did find in the incubator were pretty dated or incomplete. Will be interesting to see how you tackle text entry and the (action/focus) issues with JFormattedTextfield. Will you allow for extension of the formatters and formatterfactory and the mode/state thing? Find some of that behaviour somewhat dated too. Not committing on <enter>, sudden reverts or blocking of focus navigation etc..
The validation is another bugbear, partly because of the general oddness exhibited by Date and Calander which are only too willing to over or underflow values.. find it frightening that something like these will be treated as a valid dates (but not the dates you might think!):
new SimpleDateFormat("yyyy/MM/dd HH:mm:ss")
.parse("72364/-6473/0009999 3483:131:1010101010101");
new SimpleDateFormat("MM/dd/yyyy").parse("02/30/2005");
new SimpleDateFormat("dd/MM/yyyy").parse("02/30/2005");
About the best date entry widget I wrote was quite by accident. It was part of an Oracle PLSQL frontend and I happened to parse dates strings via a PLSQL routine - only to ensure the string returned was in the servers format and timezone at the time. But it turned out to be a remarkably flexible parsing routine that accepted a wide range of unexpected input formats that simply worked 90% of the time.
The other question on validation harks back to validation being part of the beansbinding property object (I think). If we create a new component it should play nice with binding.
Message was edited by: osbald
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Sep 28, 2007 8:44 AM
in response to: osbald
|
|
|
> I found a couple of date/time editors which I had a
> play with in my TimeEntryDemo in my incubator. That
> said what bits I did find in the incubator were
> pretty dated or incomplete. Will be interesting to
> see how you tackle text entry and the (action/focus)
> issues with JFormattedTextfield. Will you allow for
> extension of the formatters and formatterfactory and
> the mode/state thing? Find some of that behaviour
> somewhat dated too. Not committing on <enter>, sudden
> reverts or blocking of focus navigation etc..
I moved JXDatePickerFormatter to BasicDatePickerFormatter. It will most likely become an inner class in BasicDatePickerEditor, since it is dependent on that implementation of the editor to be useful. I don't see a real need to have custom formatter factories, but it would be possible by extending BasicDatePickerEditor. It is still possible to set formats, such as those used by SimpleDateFormat, and passed them into the picker (and then editor). Of course since it's possible that some editors will not use text input directly (envision a series of JComboBoxes) the editor would just ignore the formats.
My goal is to make the lines of action clear. JXDatePicker is a full-fledged and completed component. It will contain an editor and a popup. Typically, both are set by the L&F. The editor can be set by the user, but I did not currently have the same intention for the popup. Exposing the popup seems a bit riskier. In reality, I just want to get it to work without a bug, then I can better delineate what the activities are.
There are also the focus issues that Jeanette uncovered and I haven't even begun to think about them.
The short answer is: I think I have started on the road to improvement, but it's a long road.
> The validation is another bugbear, partly because of
> the general oddness exhibited by Date and Calander
> which are only too willing to over or underflow
> values.. find it frightening that something like
> these will be treated as a valid dates (but not the
> dates you might think!):
I wonder what the new Date/Time API is going to do?
> new SimpleDateFormat("yyyy/MM/dd HH:mm:ss").parse("72364/-6473/0009999 3483:131:1010101010101");
>
> new SimpleDateFormat("MM/dd/yyyy").parse("02/30/2005");
>
> new SimpleDateFormat("dd/MM/yyyy").parse("02/30/2005");
The documentation says that it will clip the text to produce the date. I haven't tried, but you should be able to add random characters at the end and still get a valid date.
> The other question on validation harks back to
> validation being part of the beansbinding property
> object (I think). If we create a new component it
> should play nice with binding.
I agree that binding is important. So is serialization and accessibility, etc. We're a long ways away from "fully-functional" Swing components in most cases. That being said, what are the bugaboos with binding? I haven't used it.
Karl
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Sep 28, 2007 6:21 PM
in response to: kschaefe
|
|
|
> > the general oddness exhibited by Date and Calander
> > which are only too willing to over or underflow
> > values.. find it frightening that something like
> > these will be treated as a valid dates (but not
> the
> > dates you might think!):
> I wonder what the new Date/Time API is going to do?
>
> new SimpleDateFormat("yyyy/MM/ddHH:mm:ss").parse("72364/-6473/00099993483:131:1010101010101");
> >
> > new SimpleDateFormat("MM/dd/yyyy").parse("02/30/2005");
> >
> > new SimpleDateFormat("dd/MM/yyyy").parse("02/30/2005");[/
If you call dateFormat.setLenient(false) these should show as invalid.
The default is true.
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Oct 16, 2007 5:58 AM
in response to: kschaefe
|
|
|
Hi Karl,
slowly reaching the bottom of my inbox <g>. Just had a quick first look
at your picker and am a bit puzzled:
> I have checked in my first version of the JXDatePicker, using a DatePickerEditor, into my incubator space. I have cribbed somewhat heavily from JComboBox (some comments still refer to the combo box). It is still a work in progress, but the test will display the JXDatePicker, as expected.
it's not picking anything?
What I definitely don't like is that you ... well ... started from
scratch (more or less - scratch being the comboBox There are many
lessons learned during the dev of the - SwingX - JXDatePicker which
don't seem to included, maybe not even possible with the revised
approach. The expected behaviour is captured (incompletely in the
picker related tests and many older and newer forum discussions.
As to the editor - one usage I've seen (by Ray and somewhere in the
incubator) is to have a spinner-like behaviour to the date blocks, that
is basically use a DefaultFormatterFactory. Simple DateFormats are not
good enough for that.
So what I'm probably saying: much thrown away with not overly much
gained (if anything). My preference is always to go a gentler change
route, preserving behaviour - which you are free not to take (in the
incubator) <g>
Cheers
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Oct 16, 2007 6:28 AM
in response to: Kleopatra
|
|
|
> slowly reaching the bottom of my inbox <g>. Just had
> a quick first look
> at your picker and am a bit puzzled:
> > I have checked in my first version of the
> JXDatePicker, using a DatePickerEditor, into my
> incubator space. I have cribbed somewhat heavily
> from JComboBox (some comments still refer to the
> combo box). It is still a work in progress, but the
> test will display the JXDatePicker, as expected.
> it's not picking anything?
It was a long night of (re)coding. I haven't even looked at it since. Needed to clear my mind. You seemed to have missed the boat on what I was trying to do here. So far this was a look at the design, does it solve all the problems we have with the current JXDatePicker. Since you and I disagree on those API problems, it probably won't matter much. Can this approach allow users to add custom implementations? Can it obfuscate the internals correctly?
> What I definitely don't like is that you ... well ...
> started from
> scratch (more or less - scratch being the comboBox
> There are many
> lessons learned during the dev of the - SwingX -
> JXDatePicker which
> don't seem to included, maybe not even possible with
> the revised
> approach. The expected behaviour is captured
> (incompletely in the
> picker related tests and many older and newer forum
> discussions.
No one seemed to balk at the implementation. So now I need to fix it and review these lessons. I never said this was complete; this is a first cut.
> As to the editor - one usage I've seen (by Ray and
> somewhere in the
> incubator) is to have a spinner-like behaviour to the
> date blocks, that
> is basically use a DefaultFormatterFactory. Simple
> DateFormats are not
> good enough for that.
I'd like to see Ray's code, but I'm confident that it can be done. I toyed with a spinner-based editor.
> So what I'm probably saying: much thrown away with
> not overly much
> gained (if anything). My preference is always to go a
> gentler change
> route, preserving behaviour - which you are free not
> to take (in the
> incubator) <g>
I don't have a problem with that approach, which is why I added this to my incubator space.
Karl
|
|
|
|
|
|
|
|
|
Re: JXDatePicker alternate approach
Posted:
Oct 16, 2007 6:52 AM
in response to: kschaefe
|
|
|
Karl,
> You
> seemed to have missed the boat on what I was trying
> to do here.
I took the plane
CU
Jeanette
|
|
|
|
|
java.net RSS
