|
Replies:
47
-
Last Post:
Jan 24, 2008 7:29 AM
by: kleopatra
|
|
|
|
|
|
|
JXDatePicker resets time on setDate()
Posted:
Jul 26, 2007 5:45 AM
|
|
|
This question is for the developers from SwingLabs. Why was taken the decision to reset the time when setting the date to a JXDatePicker? Or was a mistake?
In your code when setting the date to JXDatePicker on the associated JXMonthView there are used some temporary dates for the selection interval which are initialized with the given date from JXDatePicker. But by reseting these temporary dates the original dates are also reset. I guess you didn't want this (you even made them final but no use because you are changing the internal state of them) and it is just a bug. Otherwise why would you do this?
Thanks,
Tibi
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Jul 26, 2007 6:32 AM
in response to: tiberiu
|
|
|
jdnc-interest@javadesktop.org schrieb:
> This question is for the developers from SwingLabs. Why was taken the decision to reset the time when setting the date to a JXDatePicker? Or was a mistake?
>
can't say anything about the why, that was the - undocumented - state
when I started to look deeper. Now it's documented. And I think it makes
sense. At all "stable" times the internal invariant is
(picker.date) equals (monthView.selectedDate) equals
(editor.value)
The original date passed into any of the properties should be unchanged.
If not - it's a bug (and a regression, don't recall the number, Richard
O. had fixed it)
> In your code when setting the date to JXDatePicker on the associated JXMonthView there are used some temporary dates for the selection interval which are initialized with the given date from JXDatePicker. But by reseting these temporary dates the original dates are also reset. I guess you didn't want this (you even made them final but no use because you are changing the internal state of them) and it is just a bug. Otherwise why would you do this?
>
honestly, don't quite understand what you mean, sorry. Too many dates
swarming in my head currently <g>. Do you have a small (!) runnable
example to demonstrate?
Thanks
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Jul 26, 2007 6:53 AM
in response to: Kleopatra
|
|
|
Jeanette,
> honestly, don't quite understand what you mean,
> sorry. Too many dates
> swarming in my head currently <g>.
That's ok. My explanation is a little bit too complicated.
> Do you have a
> small (!) runnable
> example to demonstrate?
Just set the current date to a date picker and then get the date from the date picker. You will see that the time part of the date was reset. Which should not happen (my opinion).
Tibi
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Jul 26, 2007 7:24 AM
in response to: tiberiu
|
|
|
jdnc-interest@javadesktop.org schrieb:
> Just set the current date to a date picker and then get the date from the date picker. You will see that the time part of the date was reset. Which should not happen (my opinion).
>
that's the doc'ed behaviour <g>
Judging from the history, unchanged since ages: it always asked the
JXMonthView for the selected date. Don't know when the monthView started
(or maybe did right from the start) to erase the time elements, but
since that time the picker.getDate returned the cleaned date as well.
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Jul 26, 2007 7:27 AM
in response to: tiberiu
|
|
|
Forgot to ask:
> Just set the current date to a date picker and then get the date from the date picker. You will see that the time part of the date was reset. Which should not happen (my opinion).
>
what exactly do you expect to happen, especially with respect to the
editor's value and the monthView's selected? How do you want them be
related?
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Jul 27, 2007 2:55 AM
in response to: Kleopatra
|
|
|
Jeannete,
> what exactly do you expect to happen, especially with
> respect to the
> editor's value and the monthView's selected?
I would expect for both the editor's value and the monthView's selection to keep the time part of the date.
The fact that you are displaying in the monthView just the date part and not the time part is just related to the view and not to the model. You can consider it as a renderer which receives a date but displays only the date part.
I don't see any reason why you should reset the time part. This way the datePicker can not be used to set a date with time. In my application I want to set a date (with time) at which an alarm occurs. Although I have set a special formatter that allows the user to enter hours and minutes it never works because it resets the time part. Strange!!
When you say date picker I understand that you pick a date. A date is represented also by time (even milliseconds).
> How do
> you want them be
> related?
Simple. They are using the same Date object as given by the user. Just that the monthView represents only the date part and not the time. Of course that when the user selects a date from the monthView you can not tell which is the time and it is ok now to reset the time but not when writing in the editor.
I do not know where are kept the selected dates. You should have a model that is unaware of the component that represents them. And each component will represent them as it likes. I shall look a bit at the architecture of the datePicker because I am talking blindly right now.
Will come back,
Tibi
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Jul 27, 2007 4:44 AM
in response to: tiberiu
|
|
|
Tibi,
all very reasonable - only not what the datepicker currently (or in the
past? it entered my sphere only a last week or so  supported.
Need to think a bit about the implications - now that we have the
control stuffed into one place (the BasicPickerUI) it might be
relatively straightforward to enhance. Not sure though.
Could you please file an enhancement issue, to make sure we don't forget?
Thanks
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Jul 27, 2007 6:01 AM
in response to: Kleopatra
|
|
|
> Could you please file an enhancement issue, to make
> sure we don't forget?
Sure. You welcome,
Tibi
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 6, 2007 5:05 AM
in response to: tiberiu
|
|
|
Just want to back up tiberiu's point here. I recently upgraded from 0.8 to weekly, only to find out today that time info is now lost. Honestly I don't understand why the time information had to be removed, now I will have to downgrade to an old version.
Reasoning for keeping time:
- In Java a Date is not really a date, it is a timestamp - always has been and most API's adhere to timestamp semantics.
- It allows a later DateTimePicker derivative
- There's a setFormat method that takes a time format string, for this Date formating not to be respected is just not nice.
- Having the time part could optional and couldn't hurt the component in any way
Or is something off in my reasoning?
/Casper
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 6, 2007 5:30 AM
in response to: mrmorris
|
|
|
Isn't the real problem the Date class here. Perhaps there's a case for using another model that only holds date information and not time. Hopefully the Date/Time JSR has something like this already planned we could roughly mimic.
If I use a DatePicker to select the 3rd of the month I don't mean the 3rd of the month at 13:14:55 precisely. I use JXDatePicker to select ranges for report generation. For me starting at midnight is exactly what I'd expect any other time isn't logical. I'm not sure of the business case to be able to pick any day but at exactly the same time?
Maybe you should file another request for a JXDateTimePicker?
- Richard
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 6, 2007 7:51 AM
in response to: osbald
|
|
|
Tibi's alarm clock example is very much the business case of retaining time. I don't argue that most times you do want the time reset to 00:00, but don't you have the luxury of making both sides happy? I guess I don't understand why the default condition be the way it is (so you don't break existing code) and provide for an overt override. If/when JXDateTimePicker goes live (which may awhile), you deprecate the override in JXDatePicker. What's the downside (other than additional code)?
Steve
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 6, 2007 8:35 AM
in response to: sbusch
|
|
|
Tibi's idea isn't without value, but I suspect trying to archive both within the same component won't prove to be very pleasing. The behaviour being exploited here is mostly down to a side effect of the JFormattedTextField used for the editor bit. I suspect it was exposed to allow for locale formatting of the date, but of course people started to change it to expose time information and format restrictions too. Really shoulh've nailed it down in hindsight.
As .08 is two years out of date I think you'll find as many people (like me) who depend on the current functionality as those who do on the old. I'm not sure how they got it to work, until recently it wasn't handling the text input events very well, nor initial sizing so they must have extended or poked around with internal subcomponents & events in some fashion - which obviously wasn't part of the original intention.
What'd be ideal is another component for time and/or a combined datetime one. Currently I use my own composite component with a JXDatePicker and JSpinner pair when I need a date time. JSpinner isn't bad for time, but it is a tad clunky/fussy (as is having two components). Havn't been able to think up a nice visual picker for times that'd work with a simple gesture. Keep coming back to the hands of a clock which'd be weak (esp as I'd like millis).
- Richard
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 6, 2007 9:58 AM
in response to: osbald
|
|
|
> Tibi's idea isn't without value, but I suspect trying
> to archive both within the same component won't prove
> to be very pleasing. The behaviour being exploited
> here is mostly down to a side effect of the
> JFormattedTextField used for the editor bit. I
> suspect it was exposed to allow for locale formatting
> of the date, but of course people started to change
> it to expose time information and format restrictions
> too. Really shoulh've nailed it down in hindsight.
When you (I think) asked for issues with the JXDatePicker, I pointed out the problems with exposing the JFormattedTextField. Several users posted issues because they were set formats on the editor that were not DateFormats and this caused ClassCastExceptions. The editor is a UI implementation detail. It should NOT be used outside of the plaf subpackages. It should be removed ASAP.
I have filed an Issue (#598) for this problem.
In the short term, I think that we should deprecate the getEditor method.
Karl
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 6, 2007 10:22 AM
in response to: kschaefe
|
|
|
> The editor is a UI implementation detail. It should NOT be used outside of the plaf
> subpackages. It should be removed ASAP.
That was going through my mind as I wrote this. So long as you didn't raise #598 as a P1 and the sizing issue and dateformat is still accessible I don't have a problem with that (it's been a while - Jeanette was the last to have a crack).
Although it might be preferable to deprecate the accessor for a while rather than use the big stick. Our bad, sorry, do as we say not as we do.
That'll learn ya to go complaining <g>
- Richard
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 6, 2007 10:30 AM
in response to: osbald
|
|
|
> Although it might be preferable to deprecate the
> accessor for a while rather than use the big stick.
> Our bad, sorry, do as we say not as we do.
That was enough consensus for me to mark it as Deprecated.
Karl
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 2:29 AM
in response to: kschaefe
|
|
|
Guys,
>> Although it might be preferable to deprecate the
>> accessor for a while rather than use the big stick.
>> Our bad, sorry, do as we say not as we do.
> That was enough consensus for me to mark it as Deprecated.
>
not so quickly, I'm too old for such high jumps
For now, I disagree - we could argue about what/how to expose/hide an
"editor" if we know what/how users are doing with the accessors/setters.
Which we don't yet. The things I've seen so far is to replace the
editor's FormatterFactory to get spinning date portions for free. And I
can imagine to replace the editor itself as well with some super-duper
custom implementation which sings the date/time or whatever.
Reasons to not even deprecate:
a) there's no alternative (and no resources in sight to think about a
reasonable one and implement and test and document) in near to middle
future.
b) with those few strikes on the keyboard the code quality detoriated,
now having deprecation warnings all around datepicker ui-delegate and
testing (jumped by 60 warnings!). With a) there's no way to clean it up.
c) deprecating the getter only is asymetric, smelly in my book
d) as swingx promises to remove all deprecated code before a release,
the deprecation would force us to give the issue a priority it doesn't
deserve.
So my strong suggestion is to revert the change and remove the
deprecation marker.
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 5:49 AM
in response to: Kleopatra
|
|
|
Jeanette,
> For now, I disagree - we could argue about what/how
> to expose/hide an
> "editor" if we know what/how users are doing with the
> accessors/setters.
Well, I think we have enough cases of misuse that we should code the editor defensively. Allowing unfettered access to Picker internals is the exact opposite of defensive; it's offensive and to use your favorite word, smelly.
> Which we don't yet. The things I've seen so far is to
> replace the
> editor's FormatterFactory to get spinning date
> portions for free. And I
> can imagine to replace the editor itself as well with
> some super-duper
> custom implementation which sings the date/time or
> whatever.
All of which can be done with something akin to ComboBoxEditor.
> Reasons to not even deprecate:
>
> a) there's no alternative (and no resources in sight
> to think about a
> reasonable one and implement and test and document)
> in near to middle
> future.
But, we've gone round and round with users that incorrectly modify the picker's internals. Simply documenting the problem isn't enough, since no one reads the documentation.
> b) with those few strikes on the keyboard the code
> quality detoriated,
> now having deprecation warnings all around datepicker
> ui-delegate and
> testing (jumped by 60 warnings!). With a) there's no
> way to clean it up.
Turn off deprecation warnings. Seriously, you'd rather answer bogus bug reports with the same "Don't use non-Date Formatters on the JFormattedTextField" and "modifying the editor returned by getEditor is inherently risky", etc. instead of giving the user the really strong warning not to use the method.
> c) deprecating the getter only is asymetric, smelly
> in my book
I can fix that by adding "@Deprecated" there, too. It was an oversight on my part not to get both pieces of the puzzle.
> d) as swingx promises to remove all deprecated code
> before a release,
> the deprecation would force us to give the issue a
> priority it doesn't
> deserve.
Well, I think that it does deserve the priority. It's a clear design flaw, IMO, and were I to review the API, I would not approve it because of those methods.
> So my strong suggestion is to revert the change and
> remove the
> deprecation marker.
I disagree, obviously, or I wouldn't have mark it in the first place. I'd rather come up with a strategy and plan for solving the issues regarding the editor than simply removing the marker. It seems appropriate that we mark it deprecated as there is no other way to inform the developer that the code is going to be removed.
I really appreciate the feedback and responses. Keep them coming.
Karl
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 8:46 AM
in response to: Kleopatra
|
|
|
> For now, I disagree - we could argue about what/how
> to expose/hide an
> "editor" if we know what/how users are doing with the
> accessors/setters.
> Which we don't yet.
I use JXDatePicker with JGoodies Validation library. Method ValidationComponentUtils.updateComponentTreeSeverityBackground sets specific background color for component for which exist validation error.
If you are going to deprecate/delete getEditor() accessor please add delegators to editor background (and maybe others) properties... or my applications become useless...
--
Patryk
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 10, 2007 3:35 AM
in response to: prychlinski
|
|
|
Patryk,
>> For now, I disagree - we could argue about what/how
>> to expose/hide an
>> "editor" if we know what/how users are doing with the
>> accessors/setters.
>> Which we don't yet.
>
> I use JXDatePicker with JGoodies Validation library. Method ValidationComponentUtils.updateComponentTreeSeverityBackground sets specific background color for component for which exist validation error.
>
> If you are going to deprecate/delete getEditor() accessor please add delegators to editor background (and maybe others) properties... or my applications become useless...
>
good point! For your context, it would be okay to get hold of an
editorComponent (like in ComboBoxEditor)? Or is there anything special
to a formattedTextField you are using?
Thanks
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 10, 2007 4:14 AM
in response to: Kleopatra
|
|
|
> good point! For your context, it would be okay to get
> hold of an
> editorComponent (like in ComboBoxEditor)? Or is there
> anything special
> to a formattedTextField you are using?
EditorComponent is a good idea. It will be quite simple to manipulate/modify apperance of component.
--
Patryk
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 6, 2007 7:02 PM
in response to: kschaefe
|
|
|
> When you (I think) asked for issues with the
> JXDatePicker, I pointed out the problems with
> exposing the JFormattedTextField. Several users
> posted issues because they were set formats on the
> editor that were not DateFormats and this caused
> ClassCastExceptions. The editor is a UI
> implementation detail. It should NOT be used outside
> of the plaf subpackages. It should be removed ASAP.
>
> I have filed an Issue (#598) for this problem.
>
> In the short term, I think that we should deprecate
> the getEditor method.
>
> Karl
-1
Please don't.
At least leave #setEditor()
I use JXDatePicker with my own editor and it works fine for me.
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 6, 2007 7:47 PM
in response to: rturnbull
|
|
|
> > In the short term, I think that we should
> deprecate
> > the getEditor method.
> >
> > Karl
>
> -1
> Please don't.
> At least leave #setEditor()
> I use JXDatePicker with my own editor and it works
> fine for me.
Deprecated means deprecated; not removed. Not yet at least. I envision we'll provide ways to gives editors, possibly akin to how JComboBox editors work, but possibly not. Giving carte blanche access to the implementation object, opens too many holes for user bugs that we can help prevent by providing an appropriate API.
Karl
|
|
|
|
|
|
|
|
|
Time picker
Posted:
Sep 6, 2007 10:55 AM
in response to: osbald
|
|
|
Just thinking aloud what about something like a colourwheel. With hours/minutes around the outside edge and seconds down to the center. 12x60=720 so you'd need to squeeze a couple of pixels out of every degree, gives you a min size tho. (not that I can work it out).
Too odder an concept?
|
|
|
|
|
|
|
|
|
Re: Time picker
Posted:
Sep 6, 2007 2:27 PM
in response to: osbald
|
|
|
You have something like this in mind?
http://www.lavantech.com/datetimepicker/images/DateTimePicker.gif
A more mondane solution would be ok for starters. I once wrote a simple datetimepicker, had two comboboxes manipulating hours and seconds. Much like this one:
http://matrex.sourceforge.net/help/datetimepicker.jpeg
I can't help wondering if the extra JPanel that you can add to JXDatePicker, could be used but I guess a kind of commit-and-close semantics would have to be added to the whole component. In any event, I would be pleased if at least the editor would honor standard Java date formating and not clear the time component - the way it used to work.
/Casper
|
|
|
|
|
|
|
|
|
Re: Time picker
Posted:
Sep 7, 2007 3:59 AM
in response to: mrmorris
|
|
|
> You have something like this in mind?
Both yes and no. I think if a component was for editing both day and time it should show and allow editing for both. But I wouldn't like to use that example - its so clunky its kitsch <g>. You'd need to click or navigate around several controls and the 0-59 drop downs for mins & seconds.. oh boy. Anything that needs that number of clicks would be a PITA for anybody to use with some regularly. What I'm after is a fast & flexible textual input (which I suspect will remain the quickest entry option) and an visual picker that'd work with an minimum of gestures (for when I'm eating a sandwich or drinking my tea with the other hand).
I've tried adding a time entry component to the 'now' panel of the monthpicker - as you say it didnt work very well because you'd have to remember to edit the time first as selecting a date closed the popup. Because the monthview deals in ranges its only suitable for picking a single datetime value. Which'd suggest another component and model. Just wasn't a good fit, currently a separate JSpinner with a time value worked better for me.
Although manual entry remains clunky with either JSpinner or FormattedTextField - would be nice if a component had the smarts to both validate and make best guesses, rather than being anal over the exact format.
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 6, 2007 2:31 PM
in response to: osbald
|
|
|
In my mind (and maybe only there :-)), JXDatePicker should *definitely* preserve the time, and only modify the date portion of Date. In addition to the many reasons already listed, I could see somebody having a DatePicker and TimePicker (maybe the time picker is just a formatted text field). You could then have both these components bound to the same Date property of some object. In this case, you want the time control to update the time, and the date control to update the date, but not have the both wiping out the whole thing.
Does that make sense?
> If I use a DatePicker to select the 3rd of the month
> I don't mean the 3rd of the month at 13:14:55
> precisely. I use JXDatePicker to select ranges for
> report generation. For me starting at midnight is
> exactly what I'd expect any other time isn't logical.
> I'm not sure of the business case to be able to pick
> any day but at exactly the same time?
Isn't this easy enough for your code to do? Simply pass a Date into the JXDatePicker that is set to midnight. Perhaps JXDatePicker should be initialized with such a Date, rather than with new Date().
Richard
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 2:41 AM
in response to: rbair
|
|
|
Richard,
> In my mind (and maybe only there :-)), JXDatePicker should *definitely* preserve the time, and only modify the date portion of Date.
That was exactly my expectation when I first started to touch the code.
And with all the bold warnings in JXMonthView that the time-part is
cleansed, I assumed that there are more developers with a similar
expectation <g>
I see arguments for both sides (and Joshua did argue in the older
threads). Implementation-wise, it should not be so difficult to add a
property to the datepicker which switches it to the one or other: the
ui-delegate has full control over the picker's date property, so in
theory there is exactly one place to change (which in reality always
turn out to be more
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 resets time on setDate()
Posted:
Sep 7, 2007 3:33 AM
in response to: Kleopatra
|
|
|
>> In my mind (and maybe only there :-)), JXDatePicker should *definitely* preserve the time, and only modify the date portion of Date.
>That was exactly my expectation when I first started to touch the code.
>And with all the bold warnings in JXMonthView that the time-part is
>cleansed
I don't get it, what possible use could someone have for picking any day or month, but retain the same time, Doesn't picking a new day automatically invalidate the old one? That's not what tiberiu was suggesting (I dont think). What he seemed to want to do was time would be reset whever he used the moth view to choose a new date. But he then had the changed the editors format to include the time ~ which would be 00:00:00 and he could then overtype that and hit return to set the time manually.
Currently the input event tosses the value back to the model which purges the time. Which he didn't like. I don't have a problem with changing that per se, I just think Its better suited to another component that'd let you pick times and dates via the visual popup.
I'm not sure if you're trying to manipulate a default time here (the picker defaults to now). But I tend to think if you've got unusual rules over the invisible/unchangeable time component it will be better handled in your own model/controller.
As soon as the MonthView is involved time has no value, the model deals in both single dates and ranges. Again I can't see why you'd need a multiple interval of dates all inheriting the same fixed time? It's far easier just to think in day/month terms here. Otherwise you're talking about start & end times for the endpoints of every range. Trying to do everything with one component kinda stinks to me.
On the Editor issue, if the component had exposed the component as an abstract/interface rather than a fixed (overly flexible JFormattedTextField). Those arguments over it's extension might carry more weight. Unless you're advocating extending JFormattedTextField to deliver these alternative super-duper implementations <g>. It seems to me the developer should be interacting with its model not it's internal components.
Message was edited by: osbald
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 4:29 AM
in response to: osbald
|
|
|
jdnc-interest@javadesktop.org schrieb:
>>> In my mind (and maybe only there :-)), JXDatePicker should *definitely* preserve the time, and only modify the date portion of Date.
>
>> That was exactly my expectation when I first started to touch the code.
>> And with all the bold warnings in JXMonthView that the time-part is
>> cleansed
>
> I don't get it, what possible use could you have for picking any day or month, but retain the same time, Doesn't picking a new day automatically invalidate the old one? That's not what tiberiu was suggesting (I dont think). What he seemed to want to do was time would be reset whever he used the moth view to choose a new date.
okay, so we have yet another expectation Which is the point I had
been trying to make: there are different requirements out there and we
need to serve them, one way or another. Simply removing things without
replacement is ... ehem.
There had been thought put into this component (not my glory, Josh did
the excellent job for the first abstraction). We have to go from there.
As long as I'm part of the game, that will happen gently. Yes, exposing
the formattedTextField directly is not the best thing to do. But not so
evil as to warrant ripping it out with high priority.
IMO.
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 5:40 AM
in response to: Kleopatra
|
|
|
So you were thinking more of the default floating time idea? still don't get it. What could it be used for? arranging school visits to 'old faithful' <g>? No seriously *everybody* I'd like to understand how it's being used. I'm possibly being really dense. The default 'now' time includes the current time, which dosnt help the situation. Maybe it shouldnt, esp if it persists (nah! there's at least two components here). But in terms of a per-instance default it sounds awfully like asking the component enforce some business rule.
The model (or rather lack of one is JXMonthView a view or model here?) is also exposed and is the thing doing the truncating isn't it? I've never been quite sure of the validity of these 'thin' composite components. Did you try binding one yet?
> Simply removing things without replacement is ... ehem.
That's you shes talking about Karl throw the book at him I've had enough bruises from that damn rule book.. I had the preconditions and a preference for deprecation in the short term.
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 10, 2007 3:29 AM
in response to: osbald
|
|
|
jdnc-interest@javadesktop.org schrieb:
>> Simply removing things without replacement is ... ehem.
>
> That's you shes talking about Karl throw the book at him I've had enough bruises from that damn rule book.. I had the preconditions and a preference for deprecation in the short term.
LOL
This thread is meandering - trying to summarize a bit:
*Interpretation of Date*
There are parts of it: Date (complete), Day, Time and several
requirements on what to do with the parts on different user/program triggers
- all triggers normalize the Date to Day (with time == 0). That's
current behaviour, not sure since when.
- all (?) triggers change the Day part only, Time is kept as-is. That's
what RichardR and myself expected (not that my expectation is based on
anything else than gut  .
- call setDate (and/or input in editor) keeps the Time part, choosing
the Day from the monthView may (preference?) or may not keep the Time.
- ?? probably more out there
They all have their place, we should stop to argue about whether or not
one is "better" than the other. The thing we should do, is to find a
reasonable starting point which makes it possible for developer's to
adjust the picker to their requirement, even if we don't support it out
of the box.
*Separation of concerns*
You are right, Richard, the DatePicker has no model - yet. It's a slave
of the MonthView's selected date (following the monthView's agenda,
which is not necessarily the same as the Picker's). With separating out
a model around the Date property, the different requirements might be
solvable. Work lying around everywhere <g>
*To getEditor or not-to getEditor*
First: it's unrelated to the above. Second: I don't care so much about
api (though I do care about api changes while I sleep <g>, see below) as
long as it's not ghastly evil. Get/setEditor is - arguably, and here I
disagree with several of you not overly evil. The degree of evilness
is related to the resources needed to establish an alternative with the
same stability as the current state.
Information hiding is one of _the_ corner stones of OO. So the arguments
in favor of removing the exposure of the type of component getting the
input are sound. Again: we need the alternative - how can we abstract
the editor functionality (into something similar to the ComboBoxEditor,
maybe) to make it useful and flexible? Where do we expect the "hook"
points for users, subclasses, ui-delegates?
To protect developers from their own lazyness is a good argument as
well, but .. I do expect them to read api doc, why else must I write it
*Changing API*
.. in the middle of the night Always makes me slightly grumpy when
there are deep changes (and with our rules about removing deprecated
code it's effectively an api change) to code which is "near" to me
without .. ehem ... waiting for my comment (yeah, I'm arrogant enough
the assume it matters And yes I'm guilty of occasionally doing just
that - change without waiting ...
In fact, I think we just discovered that deprecation _is_ an api change.
And we should be careful with it, maybe even adding a new rule (not the
_them_ but to swingx conventions)
"no deprecation without having an established alternative"
And well .. I really want it
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 resets time on setDate()
Posted:
Jan 24, 2008 5:09 AM
in response to: Kleopatra
|
|
|
a follow-up with the latest state of affairs, starting with the second:
> *Separation of concerns*
>
> You are right, Richard, the DatePicker has no model -
> yet. It's a slave
> of the MonthView's selected date (following the
> monthView's agenda,
> which is not necessarily the same as the Picker's).
> With separating out
> a model around the Date property, the different
> requirements might be
> solvable. Work lying around everywhere <g>
>
As outlined in "JXMonthView, dirty family secrets"
http://forums.java.net/jive/thread.jspa?threadID=32939&tstart=0
the problem was not so much that there is no model - we have the monthView's selectionModel - but that the JXMonthView overruled it. So there was no way for the picker to install its own. With moving the date "normalization" (to the start of the day) from the view into the model, now the picker is free to define its behaviour completely.
>
> *Interpretation of Date*
>
> There are parts of it: Date (complete), Day, Time and
> several
> requirements on what to do with the parts on
> different user/program triggers
> - all triggers normalize the Date to Day (with time
> == 0). That's
> current behaviour, not sure since when.
> - all (?) triggers change the Day part only, Time is
> kept as-is. That's
> what RichardR and myself expected (not that my
> expectation is based on
> anything else than gut .
> - call setDate (and/or input in editor) keeps the
> Time part, choosing
> the Day from the monthView may (preference?) or may
> not keep the Time.
>
> They all have their place, we should stop to argue
> about whether or not
> one is "better" than the other. The thing we should
> do, is to find a
> reasonable starting point which makes it possible for
> developer's to
> adjust the picker to their requirement, even if we
> don't support it out
> of the box.
The way to go is to implement a DateSelectionModel which does whatever is needed to the time fields. Currently we have two useful variants:
- DaySelectionModel: resets all dates to the start of the day (just as JXMonthView did earlier), that's the default model used
- SingleDaySelectionModel: does nothing to the dates. Probably not yet fully stable (read: the tests are incomplete), but behaves essentially as Tibi expects. When coming from datePicker/editor the time fields are kept, when selecting in the dropdown, the time fields are cleared - to be honest, I still have to track down where exactly the clearing is done <g> Until I'm confident about it, it will _not_ be used by default. So client code must explicitly install it:
JXDatePicker picker = new JXDatePicker();
SingleDaySelectionModel selectionModel = new SingleDaySelectionModel();
picker.getMonthView().setSelectionModel(selectionModel);
picker.setDate(new Date());
JXDatePickerIssues has a visual test method to play with - please let me know what you think!
Cheers
Jeanette
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Jan 24, 2008 6:03 AM
in response to: kleopatra
|
|
|
Promising, it would seem that I can discontinue my own fork of JXDataPicker 0.6 (which doesn't clear time) and go back to using the official release.
Why the name SingleDaySelectionModel though, wouldn't DayTimeSelectionModel or DateSelectionModel be more self-describing?
/Casper
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Jan 24, 2008 6:44 AM
in response to: mrmorris
|
|
|
Casper,
> Promising, it would seem that I can discontinue my own fork of JXDataPicker 0.6 (which doesn't clear time) and go back to using the official release.
>
let me know how it goes - I'm very open to suggestions right now, so
there's a good probability to get your pet in <g>
> Why the name SingleDaySelectionModel though, wouldn't DayTimeSelectionModel or DateSelectionModel be more self-describing?
>
>
>
as everybody knows, I'm very bad with names. My thinking was something
like -
- DateSelectionModel is the interface, it's very general (maybe too
general for typical use-cases, don't know yet) targeted to selection of
"Instants" (joda speak"
- DaySelectionModel is the default implementation for JXMonthView: it's
targeted at ... well ... days (that is needs a calendar to be useful -
this is the notion which probably will be pulled up into the interface,
shattering the "Instant" scope) and supports several selection modes
- SingleDaySelectionModel is specialized to the needs of a picker: a
single day only.
Don't forget, this is a first draft to strip the models down (or dress
them up) to _exactly_ fit the needs of the calendar widgets. See the
rambling in the other thread:
http://forums.java.net/jive/thread.jspa?threadID=35174&tstart=0
which might be clearer.
CU
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Jan 24, 2008 7:29 AM
in response to: kleopatra
|
|
|
> - SingleDaySelectionModel: does nothing to the dates.
> Probably not yet fully stable (read: the tests are
> incomplete), but behaves essentially as Tibi expects.
> When coming from datePicker/editor the time fields
> are kept, when selecting in the dropdown, the time
> fields are cleared - to be honest, I still have to
> track down where exactly the clearing is done <g>
at least I now know why: the ui creates dates (selected) relative to the monthView's firstDisplayedDate which is still normalized independent of the model to always point to the start of the first day of the first month to display. This model-independence is definitely unwanted ... but need to think a bit about how to get rid off.
CU
Jeanette
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 5:43 AM
in response to: osbald
|
|
|
>> I don't get it, what possible use could someone have for picking any day or month, but retain the same time, Doesn't picking a new day automatically invalidate the old one? That's not what tiberiu was suggesting (I dont think). What he seemed to want to do was time would be reset whever he used the moth view to choose a new date. But he then had the changed the editors format to include the time ~ which would be 00:00:00 and he could then overtype that and hit return to set the time manually.
One thing to keep in mind storing just a date in a java.util.Date by setting the time part to 00:00:00 is that it is very locale-dependant. The actual long value (ms since the epoch GMT) will vary from time zone to time zone. This is only a problem if users in multiple time zones share an instance of your application.
What possible use? one might be to get around this problem -- changing the date in a record while keeping the time allows the record to display correctly in its original time zone.
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 10, 2007 3:31 AM
in response to: david_hall
|
|
|
Dave,
>
> One thing to keep in mind storing just a date in a java.util.Date by setting the time part to 00:00:00 is that it is very locale-dependant. The actual long value (ms since the epoch GMT) will vary from time zone to time zone. This is only a problem if users in multiple time zones share an instance of your application.
>
good point. What's the recommended way to handle this?
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 13, 2007 5:34 AM
in response to: Kleopatra
|
|
|
>> What's the recommended way to handle this?
I don't think there is an answer that will work in every situation. I once spent a couple hours exploring the idea that you could arbitrarily pick a time that would work in every time zone (11:59 am GMT, for example), but it turns out that that won't work for part of the year in a time zone that's used for some islands in the Pacific. If you want a true global date, I think you have to adjust the #clockticks by your timezone offset.
It all comes back to the idea that a timestamp is a bad idea for many applications. It can be made to work by convention (setting the time to the local value of 00:00) to a point, but after that point, it fails terribly. I'm not sure that a single concrete date class can be globally useful unless it has some concept of resolution (much the same way that BigDecimal has a concept of scale). We'd need to be able to tell BigDate that we're not interested in units of time smaller than, or example, a whole day (or a minute, month, or year, etc).
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 13, 2007 9:28 AM
in response to: david_hall
|
|
|
Dave,
>
> I don't think there is an answer that will work in every situation.
Thanks, that's what I suspected ... good to get a educated confirmation
And sounds like the jsr about Date/Time - not that I ever read it,
just know from hearsay by Richard O's - could not really solve it?
Jeanette
---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 5:49 AM
in response to: osbald
|
|
|
> I don't get it, what possible use could someone have for picking any day or month, but > retain the same time, Doesn't picking a new day automatically invalidate the old one?
Au contraire! See http://picasaweb.google.com/steven.buschman/0000/photo?authkey=EkD7p8T_0J0#5107434137652762242
My (very ancient) Palm desktop software lets me create "events" for my (very ancient) PDA. So (I ask rhetorically) I need to be someplace for the next 3 Mondays at 8:30, for 3 hours. I don't want the month view to zero out the time. Next, I'm going on vacation Oct 15, for 7 days, and I don't care what time it is. I do want to zero out the time.
My whole point is not to go tit for tat on the preserve/not-preserve time, because clearly there are instances where preserve/no-preserve are desirable. Why not give the developers the choice and we get to have our cake and eat it?
Let's believe this thread started with "JXDateTimePicker resets time on setDate" rather than JXDatePicker? Would we be having the same converstation? Weather you have a formalized JXDateTimePicker, a JSpinner, or a cludged editor JXDatePicker, the same issue would need to be addressed. I still haven't really heard a case why the choice path is all that difficult to implement.
Steve
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 6:40 AM
in response to: sbusch
|
|
|
> Au contraire!
But in terms of changing a single selectable date. Lets say to reschedule a meeting the odds against it occurring at *exactly* the same time on a different day are outweighed by the odds of you needing to change both the day and the time of the new meeting. Hence my preferred JXDatePicker and JXDateTimePicker split. You could do both in the same component I guess, but why make each component more complex than it needs to be or prompt for information you're not interested in? The other reason is the difficultly in logically separating day and time from Date and DateFormat. The JXMonthView DatePicker uses for its popup isn't (on it own) suitable for working with times with any kind of detail.
For a scheduler, which strikes me as quite a specialised user-case you could just as easily have time as a property of an event object with a list of days on which it occurs. Given the current limitations I'd prefer to keep the two separate in terms of the ui presentation.
The overtyping of the defaulted 00:00:00 time (from a JXMonthView) approach would work. There may well be issues over sizing the editor to accommodate the extra time and keeping its own copy of the selected date while making sure the model gets updated on <enter> and <focusloss> etc.. also doable if it dosnt already - but it feels like another hack.
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 7:15 AM
in response to: sbusch
|
|
|
Thank you Steve,
FINALLY... someone that understands what I meant from the beginning.
I do not know if it is good or bad to expose the internal editor. But I do not understand which is the problem with it. I do not care how the editor looks like... if it is formattedTextField, spinner...
All I have said is that if I want to set a Date using setDate() the given date must be kept like it is and not reset the time part.
If you have a problem to selecting the date using the monthView then OK... reset the time part in that case because you do not know at what value to set it. That is your problem how you handle the dates selected from the monthView and this is the only thing that you should discuss about(my opinion).
BUT if I set it from the editor of datePicker then let it as I have told you.
AGAIN... If I set it by program from code then again let it as I have told you.
Have I made myself understood now?
Tibi
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 7:49 AM
in response to: tiberiu
|
|
|
If you mean using it like this http://forums.java.net/jive/thread.jspa?messageID=234367&tstart=0#234367 then yes I do! but why thank Steve?
The problem is JXDatePicker not being a full blown component in its own right. Think of two different components (the Editor and JXMonthView) each with their own differing agendas held together with some duct tape. JXDatePicker itself dosnt have a model to store the date in, it just delegates to MonthView and MonthView dosnt understand time - only days. With some shimmying it something could be possible - but as keep saying I think if your interested in both day and time it'd be better served by something that understood and offered the opportunity to edit both rather than JXDatePickers schizoid existence where the answers likely to differ depending on whether you ask its Editor (you shouldnt know about) or its Model for the time.
Would renaming JXDatePicker to JXDayPicker make its intention any clearer?
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 8:36 AM
in response to: osbald
|
|
|
Are you raining on all my glory <g>?
Let's just say that this wasn't so schizoid and we were talking about JXDateTimePicker where the editor component showed date *and* time in two separate components. Should going into MonthView and selecting a new date change the time? Probably not. OK, so now I'm going to extend JXDateTimePicker and hide the time when I don't care about the time (why not use JXDatePicker then? Well, because the user gets to decide if time is important, so it's dynamic). This would be the case where time is 00:00.
So, either you'll pay now with JXDatePicker or pay later with JXDateTimePicker that MonthView knows about time (I'm of course assuming that you'd want to use the identical MonthView in both cases).
Steve
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 9:11 AM
in response to: sbusch
|
|
|
I dont have an issue over the editor being one field. In fact I have a preference for smart text entry here (think the jspinner and formattedfield are too dumb for my own taste). The popup JXMonthView is the bugbear for me here.
Personally I think limiting the existing component to days only is the way to go, adding the time bits will take the extra effort. I think you'd have to wrap/extend a MonthView in some fashion to allow for an extra time input for a JXDateTimePicker. Which breaks down in my head to having a DayPicker, TimePicker and DateTimePicker (reusing both).
The DatePicker should have its own model (just a selected date?). May be able to extract a shared one from MonthView but time support in that calender component dosnt really gel for me. Adding time to every start & end point would be more advanced beast - gets in the way of simple one-click (or drag) selections.
- Sorry about my sporadic use of 'day' here I'm trying to avoid 'date' as its already overloaded.
Message was edited by: osbald
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 10:35 AM
in response to: osbald
|
|
|
> Personally I think limiting the existing component to
> days only is the way to go, adding the time bits will
> take the extra effort. I think you'd have to
> wrap/extend a MonthView in some fashion to allow for
> an extra time input for a JXDateTimePicker. Which
> breaks down in my head to having a DayPicker,
> TimePicker and DateTimePicker (reusing both).
Still doesn't make any sense to me.
JXDayPicker day = new JXDayPicker();
JXTimePicker time = new JXTimePicker();
Event evt = new Event(); // some object with a getDate() property
//some made up binding stuff
BindingContext ctx = new BindingContext();
ctx.addBinding(evt, "date", day, "value");
ctx.addBinding(evt, "date", time, "value");
In this case, I want to change the date and time independently of each other. Such as the screenshot earlier of the palm software event page. One control for time, one for date. Would be nice if the JXDatePicker/JXDatePicker/whatever could just update the one part of the Date, instead of the whole thing!
Richard
|
|
|
|
|
|
|
|
|
Re: JXDatePicker resets time on setDate()
Posted:
Sep 7, 2007 8:39 AM
in response to: tiberiu
|
|
|
Ok I guess there's another way you could slice this. If I drop all my pretensions about imperial rules, layers and the like and just think of a developer dumping a bunch of values into a set of components before setVisible() and then retrieving the values again on exit. Old-school poke & peek, then I can see why you might get wound up about the changes.
Especially as the events on JXDatePicker would have been broken in the old .08 version, so the view & model will fall out-of-step. Querying the value on exit was probably the only thing that worked.
|
|
|
|
|
java.net RSS
