- DateField emits onDateSelected event when date set #762

Closed
wants to merge 3 commits into
from

Conversation

Projects
None yet
2 participants
@mahomahomaho
Contributor

mahomahomaho commented Jul 28, 2012

as in subject. It's nice when I'm able to receive event when date is set in dateField.

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Jul 29, 2012

Member

ok, this doesn't modify existing API -- should be fine -- but some notes/questions below:

  • what is GWT doing ATM? (this is likely an old version of theirs)
  • is this going to cause double events if the user clicks a date, or clicks the "today" button? (might be [un]expected behavior, depending on who you ask)
  • why should focus events fire this event?
  • whats up with the onTboxChanged and emitSelectedDate separation? tbox is more of an impl detail and doesn't need to be exposed ... why not merge onDateSelected and emitDateSelected? it seems to me that a new handler is not needed at all, and you simply want to be informed directly if the date changes?
Member

anthonyrisinger commented Jul 29, 2012

ok, this doesn't modify existing API -- should be fine -- but some notes/questions below:

  • what is GWT doing ATM? (this is likely an old version of theirs)
  • is this going to cause double events if the user clicks a date, or clicks the "today" button? (might be [un]expected behavior, depending on who you ask)
  • why should focus events fire this event?
  • whats up with the onTboxChanged and emitSelectedDate separation? tbox is more of an impl detail and doesn't need to be exposed ... why not merge onDateSelected and emitDateSelected? it seems to me that a new handler is not needed at all, and you simply want to be informed directly if the date changes?
@mahomahomaho

This comment has been minimized.

Show comment
Hide comment
@mahomahomaho

mahomahomaho Jul 29, 2012

Contributor

W dniu 29.07.2012 06:20, C Anthony Risinger pisze:

ok, this doesn't modify existing API -- should be fine -- but some notes/questions below:

  • what is GWT doing ATM? (this is likely an old version of theirs)

I have no idea. As I'm not java/gwt user, I don't know even where to
search.

I have found
http://www.jarvana.com/jarvana/view/com/extjs/gxt/2.2.0/gxt-2.2.0-javadoc.jar!/com/extjs/gxt/ui/client/widget/form/DateField.html

  • but I don't know how to interpret with different conclusion than "they
    did it different".
  • is this going to cause double events if the user clicks a date, or clicks the "today" button? (might be [un]expected behavior, depending on who you ask)

I just pushed fix to it (forgot to remember last_date).

  • why should focus events fire this event?

My experience with textboxes and javascript says that "on lost
focus"/onblur is valuable source of information that text has changed
(there are scenarios where text is changed and input and changed events
are not fired).

  • whats up with the onTboxChanged and emitSelectedDate separation? tbox is more of an impl detail and doesn't need to be exposed ... why not merge onDateSelected and emitDateSelected? it seems to me that a new handler is not needed at all, and you simply want to be informed directly if the date changes?

Well, we could just add default-null parameter to emitDateSelected and
make it handler of input/changed events, but I think it's worth to keep
separation between "we selected date by click on calendar/today" and "we
wrote something into text, maybe valid maybe not". Maybe we will need to
add some kind of validation in latter?

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

Contributor

mahomahomaho commented Jul 29, 2012

W dniu 29.07.2012 06:20, C Anthony Risinger pisze:

ok, this doesn't modify existing API -- should be fine -- but some notes/questions below:

  • what is GWT doing ATM? (this is likely an old version of theirs)

I have no idea. As I'm not java/gwt user, I don't know even where to
search.

I have found
http://www.jarvana.com/jarvana/view/com/extjs/gxt/2.2.0/gxt-2.2.0-javadoc.jar!/com/extjs/gxt/ui/client/widget/form/DateField.html

  • but I don't know how to interpret with different conclusion than "they
    did it different".
  • is this going to cause double events if the user clicks a date, or clicks the "today" button? (might be [un]expected behavior, depending on who you ask)

I just pushed fix to it (forgot to remember last_date).

  • why should focus events fire this event?

My experience with textboxes and javascript says that "on lost
focus"/onblur is valuable source of information that text has changed
(there are scenarios where text is changed and input and changed events
are not fired).

  • whats up with the onTboxChanged and emitSelectedDate separation? tbox is more of an impl detail and doesn't need to be exposed ... why not merge onDateSelected and emitDateSelected? it seems to me that a new handler is not needed at all, and you simply want to be informed directly if the date changes?

Well, we could just add default-null parameter to emitDateSelected and
make it handler of input/changed events, but I think it's worth to keep
separation between "we selected date by click on calendar/today" and "we
wrote something into text, maybe valid maybe not". Maybe we will need to
add some kind of validation in latter?

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Jul 29, 2012

Member

I have no idea. As I'm not java/gwt user, I don't know even where to
search.

thats fine don't worry about it -- what you found is actually extjs-on-GWT (yuck), but no matter.

I just pushed fix to it (forgot to remember last_date).

ok good good.

My experience with textboxes and javascript says that "on lost
focus"/onblur is valuable source of information that text has changed
(there are scenarios where text is changed and input and changed events
are not fired).

fair enough, as long as you are recording the last date it should be fine.

Well, we could just add default-null parameter to emitDateSelected and
make it handler of input/changed events, but I think it's worth to keep
separation between "we selected date by click on calendar/today" and "we
wrote something into text, maybe valid maybe not". Maybe we will need to
add some kind of validation in latter?

well, this is javascript so you have to validate everything in the end anyway -- i don't think there is much gain by making the two separate (not that we shouldn't try to make it safe, code could def be added to abort the update/event if it's not a real date, see below).

my main holdup is that the interface is so much different than Calendar, and should be changed to match Calendar as much as possible:

  • rename listeners to changedDateListeners (mirror Calendar)
  • rename emitSelectedDate to onDate (mirror Calendar), update
    _last_date here, but DONT getText here ... signature should match
    onDate from calendar: event, yy, mm, dd
  • rename onTboxChanged to onFieldChanged, split the date and call
    onDate with the event (mirror Calendar). if date can't be split into
    yy/mm/dd, abort, and update tbox with _last_date (not awesome
    validation, but should be splittable at least)

does that make sense? for the most part it's just renames.

Member

anthonyrisinger commented Jul 29, 2012

I have no idea. As I'm not java/gwt user, I don't know even where to
search.

thats fine don't worry about it -- what you found is actually extjs-on-GWT (yuck), but no matter.

I just pushed fix to it (forgot to remember last_date).

ok good good.

My experience with textboxes and javascript says that "on lost
focus"/onblur is valuable source of information that text has changed
(there are scenarios where text is changed and input and changed events
are not fired).

fair enough, as long as you are recording the last date it should be fine.

Well, we could just add default-null parameter to emitDateSelected and
make it handler of input/changed events, but I think it's worth to keep
separation between "we selected date by click on calendar/today" and "we
wrote something into text, maybe valid maybe not". Maybe we will need to
add some kind of validation in latter?

well, this is javascript so you have to validate everything in the end anyway -- i don't think there is much gain by making the two separate (not that we shouldn't try to make it safe, code could def be added to abort the update/event if it's not a real date, see below).

my main holdup is that the interface is so much different than Calendar, and should be changed to match Calendar as much as possible:

  • rename listeners to changedDateListeners (mirror Calendar)
  • rename emitSelectedDate to onDate (mirror Calendar), update
    _last_date here, but DONT getText here ... signature should match
    onDate from calendar: event, yy, mm, dd
  • rename onTboxChanged to onFieldChanged, split the date and call
    onDate with the event (mirror Calendar). if date can't be split into
    yy/mm/dd, abort, and update tbox with _last_date (not awesome
    validation, but should be splittable at least)

does that make sense? for the most part it's just renames.

@mahomahomaho

This comment has been minimized.

Show comment
Hide comment
@mahomahomaho

mahomahomaho Jul 29, 2012

Contributor

W dniu 29.07.2012 09:24, C Anthony Risinger pisze:

On Sun, Jul 29, 2012 at 1:33 AM, mahomahomaho
reply@reply.github.com
wrote:

W dniu 29.07.2012 06:20, C Anthony Risinger pisze:

ok, this doesn't modify existing API -- should be fine -- but some notes/questions below:

  • what is GWT doing ATM? (this is likely an old version of theirs)
    I have no idea. As I'm not java/gwt user, I don't know even where to
    search.
    thats fine don't worry about it -- what you found is actually
    extjs-onGWT (yuck), but no matter.
  • is this going to cause double events if the user clicks a date, or clicks the "today" button? (might be [un]expected behavior, depending on who you ask)
    I just pushed fix to it (forgot to remember last_date).
    ok good good.
  • why should focus events fire this event?
    My experience with textboxes and javascript says that "on lost
    focus"/onblur is valuable source of information that text has changed
    (there are scenarios where text is changed and input and changed events
    are not fired).
    fair enough, as long as you are recording the last date it should be fine.
  • whats up with the onTboxChanged and emitSelectedDate separation? tbox is more of an impl detail and doesn't need to be exposed ... why not merge onDateSelected and emitDateSelected? it seems to me that a new handler is not needed at all, and you simply want to be informed directly if the date changes?
    Well, we could just add default-null parameter to emitDateSelected and
    make it handler of input/changed events, but I think it's worth to keep
    separation between "we selected date by click on calendar/today" and "we
    wrote something into text, maybe valid maybe not". Maybe we will need to
    add some kind of validation in latter?
    well, this is javascript so you have to validate everything in the end
    anyway -- i don't think there is much gain by making the two separate
    (not that we shouldn't try to make it safe, code could def be added to
    abort the update/event if it's not a real date).

my main holdup is that the interface is so much different than the
Calendar, and should be changed to match Calendar as much as possible:

  • rename listeners to changedDateListeners (mirror Calendar)

Done. By delegating it to separate class (DateSelectedHandler)

  • rename emitSelectedDate to onDate (mirror Calendar),
 I have doubts about it. onSomething suggests "this is handler, 

method will be done when Something occur". But here we don't wait until
something occur, we want to something happend. We don't wait for event,
we want to emit event.

But I did it a bit different, please look.

update
_last_date here, but DONT getText here ... signature should match
onDate from calendar: event, yy, mm, dd

I think it's no point to call method with date in arguments, I think
that it's better to call getDate() in common used method, which is
called from few places.

In other words, if emitSelectedDate is called from few places, then it's
better to do self.getDate() in emitSelectedDate, rather than copy&paste
it into few places.

  • rename onTboxChanged to onFieldChanged,

renamed.

split the date and call
onDate with the event (mirror Calendar). if date can't be split into
yy/mm/dd, abort, and update tbox with _last_date (not awesome
validation, but must be splittable at least)

splitting - I would rather like to avoid it, because I would like to use
it at most pythonic way as possible, which I think means that date
should be stored in datetime.date, not in y,m,d fields like in some php
:). Well, we cannot get rid of y,m,d triple for compatibility reasons (I
think), but at least datefield should support using datetime.date

Also, aborting and replacing when date is not parseable is not good,
because in there is no way to write date from keyboard in such case. So
I left as is so far.

What do you think about it?

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

Contributor

mahomahomaho commented Jul 29, 2012

W dniu 29.07.2012 09:24, C Anthony Risinger pisze:

On Sun, Jul 29, 2012 at 1:33 AM, mahomahomaho
reply@reply.github.com
wrote:

W dniu 29.07.2012 06:20, C Anthony Risinger pisze:

ok, this doesn't modify existing API -- should be fine -- but some notes/questions below:

  • what is GWT doing ATM? (this is likely an old version of theirs)
    I have no idea. As I'm not java/gwt user, I don't know even where to
    search.
    thats fine don't worry about it -- what you found is actually
    extjs-onGWT (yuck), but no matter.
  • is this going to cause double events if the user clicks a date, or clicks the "today" button? (might be [un]expected behavior, depending on who you ask)
    I just pushed fix to it (forgot to remember last_date).
    ok good good.
  • why should focus events fire this event?
    My experience with textboxes and javascript says that "on lost
    focus"/onblur is valuable source of information that text has changed
    (there are scenarios where text is changed and input and changed events
    are not fired).
    fair enough, as long as you are recording the last date it should be fine.
  • whats up with the onTboxChanged and emitSelectedDate separation? tbox is more of an impl detail and doesn't need to be exposed ... why not merge onDateSelected and emitDateSelected? it seems to me that a new handler is not needed at all, and you simply want to be informed directly if the date changes?
    Well, we could just add default-null parameter to emitDateSelected and
    make it handler of input/changed events, but I think it's worth to keep
    separation between "we selected date by click on calendar/today" and "we
    wrote something into text, maybe valid maybe not". Maybe we will need to
    add some kind of validation in latter?
    well, this is javascript so you have to validate everything in the end
    anyway -- i don't think there is much gain by making the two separate
    (not that we shouldn't try to make it safe, code could def be added to
    abort the update/event if it's not a real date).

my main holdup is that the interface is so much different than the
Calendar, and should be changed to match Calendar as much as possible:

  • rename listeners to changedDateListeners (mirror Calendar)

Done. By delegating it to separate class (DateSelectedHandler)

  • rename emitSelectedDate to onDate (mirror Calendar),
 I have doubts about it. onSomething suggests "this is handler, 

method will be done when Something occur". But here we don't wait until
something occur, we want to something happend. We don't wait for event,
we want to emit event.

But I did it a bit different, please look.

update
_last_date here, but DONT getText here ... signature should match
onDate from calendar: event, yy, mm, dd

I think it's no point to call method with date in arguments, I think
that it's better to call getDate() in common used method, which is
called from few places.

In other words, if emitSelectedDate is called from few places, then it's
better to do self.getDate() in emitSelectedDate, rather than copy&paste
it into few places.

  • rename onTboxChanged to onFieldChanged,

renamed.

split the date and call
onDate with the event (mirror Calendar). if date can't be split into
yy/mm/dd, abort, and update tbox with _last_date (not awesome
validation, but must be splittable at least)

splitting - I would rather like to avoid it, because I would like to use
it at most pythonic way as possible, which I think means that date
should be stored in datetime.date, not in y,m,d fields like in some php
:). Well, we cannot get rid of y,m,d triple for compatibility reasons (I
think), but at least datefield should support using datetime.date

Also, aborting and replacing when date is not parseable is not good,
because in there is no way to write date from keyboard in such case. So
I left as is so far.

What do you think about it?

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Jul 29, 2012

Member

whoa whoa, slow down, we are straying here.

we don't need a new class -- it's superfluous. if you want to modify the addSelectedDateListener signature to accept a keyword argument, that is fine, but it should be descriptive, like useDatetime or asDatetime and needs to match the rest of the API -- hell if it we up to me nothing would even be CamelCase, but that just not how the API is, and straying from these expectations only makes things harder for everyone.

emitDateSelected needs to match the onDate handler from calendar. TBH, i don't think you even need the other calls to emitDateSelected -- the Today/onFocus/etc handlers are calling self.tbox.setText which will fire the onChanged textbox handler later on.

you are probably correct about aborting within the date changed handler, simply accepting the update is fine. it was just a last second idea i had but i didn't consider the handler would fire for each character.

so, action items:

  • drop the new class/etc ... this update needs to be the least possible changes to get the desired behavior.
  • consider storing the listeners as a tuple: (listener, useDatetime) ... or in separate attributes: selectedDateHandlers, selectedDatetimeHandlers
  • pass everything thru a single onDate method linked to change and focus events of the textbox -- there should be no need to call it manually because all other [successful] events eventually result in a self.tbox.setText. this name, onDate, matches other areas of the API (emit* is not used anywhere).
Member

anthonyrisinger commented Jul 29, 2012

whoa whoa, slow down, we are straying here.

we don't need a new class -- it's superfluous. if you want to modify the addSelectedDateListener signature to accept a keyword argument, that is fine, but it should be descriptive, like useDatetime or asDatetime and needs to match the rest of the API -- hell if it we up to me nothing would even be CamelCase, but that just not how the API is, and straying from these expectations only makes things harder for everyone.

emitDateSelected needs to match the onDate handler from calendar. TBH, i don't think you even need the other calls to emitDateSelected -- the Today/onFocus/etc handlers are calling self.tbox.setText which will fire the onChanged textbox handler later on.

you are probably correct about aborting within the date changed handler, simply accepting the update is fine. it was just a last second idea i had but i didn't consider the handler would fire for each character.

so, action items:

  • drop the new class/etc ... this update needs to be the least possible changes to get the desired behavior.
  • consider storing the listeners as a tuple: (listener, useDatetime) ... or in separate attributes: selectedDateHandlers, selectedDatetimeHandlers
  • pass everything thru a single onDate method linked to change and focus events of the textbox -- there should be no need to call it manually because all other [successful] events eventually result in a self.tbox.setText. this name, onDate, matches other areas of the API (emit* is not used anywhere).
@mahomahomaho

This comment has been minimized.

Show comment
Hide comment
@mahomahomaho

mahomahomaho Jul 29, 2012

Contributor

W dniu 29.07.2012 20:34, C Anthony Risinger pisze:

whoa whoa, slow down, we are straying here.

we don't need a new class -- it's superfluous. if you want to modify the addSelectedDateListener signature to accept a keyword argument, that is fine, but it should be descriptive, like useDatetime or asDatetime and needs to match the rest of the API -- hell if it we up to me nothing would even be CamelCase, but that just not how the API is, and straying from these expectations only makes things harder for everyone.

emitDateSelected needs to match the onDate handler from calendar. TBH, i don't think you even need the other calls to emitDateSelected -- the Today/onFocus/etc handlers are calling self.tbox.setText which will fire the onChanged textbox handler later on.

you are probably correct about aborting within the date changed handler, simply accepting the update is fine. it was just a last second idea i had but i didn't consider the handler would fire for each character.

so, action items:

  • drop the new class/etc ... this update needs to be the least possible changes to get the desired behavior.

But ... if you want second (DateField) class to have same functions as
first class (Calendar), which in fact does the same ... isn't it logical
that that functionality should be moved to third, common place? I think
that copy&paste pattern is quite evil ...

So, are you sure you want situation that when you fix some bug in one
place (Calendar.addSelectedDateListener), you need to remember to fix it
in another (DateField.addSelectedDateListener) ?

  • consider storing the listeners as a tuple: (listener, useDatetime) ... or in separate attributes: selectedDateHandlers, selectedDatetimeHandlers
  • pass everything thru a single onDate method linked to change and focus events of the textbox -- there should be no need to call it manually because all other [successful] events eventually result in a self.tbox.setText.
    this name, onDate, matches other areas of the API (emit* is not used anywhere).

Ok, I agree with name change. I'm not 100% sure about not calling it
from onDateSelected handlers.

Contributor

mahomahomaho commented Jul 29, 2012

W dniu 29.07.2012 20:34, C Anthony Risinger pisze:

whoa whoa, slow down, we are straying here.

we don't need a new class -- it's superfluous. if you want to modify the addSelectedDateListener signature to accept a keyword argument, that is fine, but it should be descriptive, like useDatetime or asDatetime and needs to match the rest of the API -- hell if it we up to me nothing would even be CamelCase, but that just not how the API is, and straying from these expectations only makes things harder for everyone.

emitDateSelected needs to match the onDate handler from calendar. TBH, i don't think you even need the other calls to emitDateSelected -- the Today/onFocus/etc handlers are calling self.tbox.setText which will fire the onChanged textbox handler later on.

you are probably correct about aborting within the date changed handler, simply accepting the update is fine. it was just a last second idea i had but i didn't consider the handler would fire for each character.

so, action items:

  • drop the new class/etc ... this update needs to be the least possible changes to get the desired behavior.

But ... if you want second (DateField) class to have same functions as
first class (Calendar), which in fact does the same ... isn't it logical
that that functionality should be moved to third, common place? I think
that copy&paste pattern is quite evil ...

So, are you sure you want situation that when you fix some bug in one
place (Calendar.addSelectedDateListener), you need to remember to fix it
in another (DateField.addSelectedDateListener) ?

  • consider storing the listeners as a tuple: (listener, useDatetime) ... or in separate attributes: selectedDateHandlers, selectedDatetimeHandlers
  • pass everything thru a single onDate method linked to change and focus events of the textbox -- there should be no need to call it manually because all other [successful] events eventually result in a self.tbox.setText.
    this name, onDate, matches other areas of the API (emit* is not used anywhere).

Ok, I agree with name change. I'm not 100% sure about not calling it
from onDateSelected handlers.

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Jul 30, 2012

Member

But ... if you want second (DateField) class to have same functions as
first class (Calendar), which in fact does the same ... isn't it logical
that that functionality should be moved to third, common place? I think
that copy&paste pattern is quite evil ...

So, are you sure you want situation that when you fix some bug in one
place (Calendar.addSelectedDateListener), you need to remember to fix it
in another (DateField.addSelectedDateListener) ?

well, i'm not really disagreeing with your reasoning, i just don't want to modify so much in one shot. TBH, i would prefer if Calendar was not changed at all, and you only added the bits you needed to DateField ... i'm trying to get the functionality you need with minimal change to the codebase. if you only need DateField for your purposes, don't even worry about Calendar. i know it sounds counter intuitive, but don't worry about what's "most correct", just do what's necessary to get what you need with minimal impact.

the thing is, this library is near frozen, no new functionality should really be added at all, as we are preparing for GWT 2.x+. each time we stray from the original GWT sources things get more difficult to maintain over time. once that process start (very soon) this part of the library will freeze and only receive bugfixes.

Ok, I agree with name change. I'm not 100% sure about not calling it
from onDateSelected handlers.

go ahead and try it out -- i think it should work fine, but if it it's causing problems i'll take a look, or we'll just go ahead and pull as-is.

Member

anthonyrisinger commented Jul 30, 2012

But ... if you want second (DateField) class to have same functions as
first class (Calendar), which in fact does the same ... isn't it logical
that that functionality should be moved to third, common place? I think
that copy&paste pattern is quite evil ...

So, are you sure you want situation that when you fix some bug in one
place (Calendar.addSelectedDateListener), you need to remember to fix it
in another (DateField.addSelectedDateListener) ?

well, i'm not really disagreeing with your reasoning, i just don't want to modify so much in one shot. TBH, i would prefer if Calendar was not changed at all, and you only added the bits you needed to DateField ... i'm trying to get the functionality you need with minimal change to the codebase. if you only need DateField for your purposes, don't even worry about Calendar. i know it sounds counter intuitive, but don't worry about what's "most correct", just do what's necessary to get what you need with minimal impact.

the thing is, this library is near frozen, no new functionality should really be added at all, as we are preparing for GWT 2.x+. each time we stray from the original GWT sources things get more difficult to maintain over time. once that process start (very soon) this part of the library will freeze and only receive bugfixes.

Ok, I agree with name change. I'm not 100% sure about not calling it
from onDateSelected handlers.

go ahead and try it out -- i think it should work fine, but if it it's causing problems i'll take a look, or we'll just go ahead and pull as-is.

@mahomahomaho

This comment has been minimized.

Show comment
Hide comment
@mahomahomaho

mahomahomaho Jul 30, 2012

Contributor

W dniu 30.07.2012 03:40, C Anthony Risinger pisze:

But ... if you want second (DateField) class to have same functions as
first class (Calendar), which in fact does the same ... isn't it logical
that that functionality should be moved to third, common place? I think
that copy&paste pattern is quite evil ...
So, are you sure you want situation that when you fix some bug in one
place (Calendar.addSelectedDateListener), you need to remember to fix it
in another (DateField.addSelectedDateListener) ?
well, i'm not really disagreeing with your reasoning, i just don't want to modify so much in one shot. TBH, i would prefer if Calendar was not changed at all, and you only added the bits you needed to DateField ... i'm trying to get the functionality you need with minimal change to the codebase. if you only need DateField for your purposes, don't even worry about Calendar. i know it sounds counter intuitive, but don't worry about what's "most correct", just do what's necessary to get what you need with minimal impact.

I think there are three things which are not achievable together:
a) minimal impact (modify DateField not Calendar),
b) keep signatures identical to Calendar,
c) use datetime.date (important for me).

You want to me to do a+b+c , while only a+b, a+c or b+c are possible.

the thing is, this library is near frozen, no new functionality should really be added at all, as we are preparing for GWT 2.x+. each time we stray from the original GWT sources things get more difficult to maintain over time. once that process start (very soon) this part of the library will freeze and only receive bugfixes.

Oh, looks like I missed some discussion :/ . Where can I read about it?

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

Contributor

mahomahomaho commented Jul 30, 2012

W dniu 30.07.2012 03:40, C Anthony Risinger pisze:

But ... if you want second (DateField) class to have same functions as
first class (Calendar), which in fact does the same ... isn't it logical
that that functionality should be moved to third, common place? I think
that copy&paste pattern is quite evil ...
So, are you sure you want situation that when you fix some bug in one
place (Calendar.addSelectedDateListener), you need to remember to fix it
in another (DateField.addSelectedDateListener) ?
well, i'm not really disagreeing with your reasoning, i just don't want to modify so much in one shot. TBH, i would prefer if Calendar was not changed at all, and you only added the bits you needed to DateField ... i'm trying to get the functionality you need with minimal change to the codebase. if you only need DateField for your purposes, don't even worry about Calendar. i know it sounds counter intuitive, but don't worry about what's "most correct", just do what's necessary to get what you need with minimal impact.

I think there are three things which are not achievable together:
a) minimal impact (modify DateField not Calendar),
b) keep signatures identical to Calendar,
c) use datetime.date (important for me).

You want to me to do a+b+c , while only a+b, a+c or b+c are possible.

the thing is, this library is near frozen, no new functionality should really be added at all, as we are preparing for GWT 2.x+. each time we stray from the original GWT sources things get more difficult to maintain over time. once that process start (very soon) this part of the library will freeze and only receive bugfixes.

Oh, looks like I missed some discussion :/ . Where can I read about it?

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

@mahomahomaho

This comment has been minimized.

Show comment
Hide comment
@mahomahomaho

mahomahomaho Jul 30, 2012

Contributor

W dniu 30.07.2012 03:40, C Anthony Risinger pisze:

Ok, I agree with name change. I'm not 100% sure about not calling it

from onDateSelected handlers.
go ahead and try it out -- i think it should work fine, but if it it's causing problems i'll take a look, or we'll just go ahead and pull as-is.

BTW - I just checked and field.getText().setText(xxx) doesn't fire
events ... at least in my Firefox 14.0.1

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

Contributor

mahomahomaho commented Jul 30, 2012

W dniu 30.07.2012 03:40, C Anthony Risinger pisze:

Ok, I agree with name change. I'm not 100% sure about not calling it

from onDateSelected handlers.
go ahead and try it out -- i think it should work fine, but if it it's causing problems i'll take a look, or we'll just go ahead and pull as-is.

BTW - I just checked and field.getText().setText(xxx) doesn't fire
events ... at least in my Firefox 14.0.1

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Aug 2, 2012

Member

hrm ... ok **** it, we'll go ahead with this ... i'm not sure i'm 100% satisfied with the result, but that's ok.

just confirm the existing API is still intact (eg. existing code doesn't break) and it also does what you need, and i'll pull it.

thanks @mahomahomaho :-)

Member

anthonyrisinger commented Aug 2, 2012

hrm ... ok **** it, we'll go ahead with this ... i'm not sure i'm 100% satisfied with the result, but that's ok.

just confirm the existing API is still intact (eg. existing code doesn't break) and it also does what you need, and i'll pull it.

thanks @mahomahomaho :-)

@mahomahomaho

This comment has been minimized.

Show comment
Hide comment
@mahomahomaho

mahomahomaho Aug 2, 2012

Contributor

W dniu 02.08.2012 06:21, C Anthony Risinger pisze:

hrm ... ok **** it, we'll go ahead with this ... i'm not sure i'm 100% satisfied with the result, but that's ok.

just confirm the existing API is still intact (eg. existing code doesn't break) and it also does what you need, and i'll pull it.

thanks @mahomahomaho :-)

BTW - I'm on vacation so I will probably finish it near middle of the
month. Don't close this pull request :)

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

Contributor

mahomahomaho commented Aug 2, 2012

W dniu 02.08.2012 06:21, C Anthony Risinger pisze:

hrm ... ok **** it, we'll go ahead with this ... i'm not sure i'm 100% satisfied with the result, but that's ok.

just confirm the existing API is still intact (eg. existing code doesn't break) and it also does what you need, and i'll pull it.

thanks @mahomahomaho :-)

BTW - I'm on vacation so I will probably finish it near middle of the
month. Don't close this pull request :)

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Aug 3, 2012

Member

sure sure, just drop a line when your ready.

... and enjoy the hell out of your vacation :-)

Member

anthonyrisinger commented Aug 3, 2012

sure sure, just drop a line when your ready.

... and enjoy the hell out of your vacation :-)

@mahomahomaho

This comment has been minimized.

Show comment
Hide comment
@mahomahomaho

mahomahomaho Oct 7, 2012

Contributor

I just returned from vacation (well, it was month ago but I was buried with superurgent tasks), I reviewed the change and I'm pretty sure that API is intact.

So I think you can safely pull it into trunk.

Contributor

mahomahomaho commented Oct 7, 2012

I just returned from vacation (well, it was month ago but I was buried with superurgent tasks), I reviewed the change and I'm pretty sure that API is intact.

So I think you can safely pull it into trunk.

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Oct 11, 2012

Member

ok, i'll review this shortly and go from there (ie, prob just pull as-is)

Member

anthonyrisinger commented Oct 11, 2012

ok, i'll review this shortly and go from there (ie, prob just pull as-is)

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Oct 23, 2012

Member

this is still relevant to you, yes?

could you rebase your work into a single, unified commit (with title/body message explaining the change, and ideally, how to use it)? i'm unable to merge it as-is for whatever reason, so you may have to resolve some conflicts and verify proper operation.

looking to handle this in the next few days, thanks for your patience, much appreciated.

Member

anthonyrisinger commented Oct 23, 2012

this is still relevant to you, yes?

could you rebase your work into a single, unified commit (with title/body message explaining the change, and ideally, how to use it)? i'm unable to merge it as-is for whatever reason, so you may have to resolve some conflicts and verify proper operation.

looking to handle this in the next few days, thanks for your patience, much appreciated.

@mahomahomaho

This comment has been minimized.

Show comment
Hide comment
@mahomahomaho

mahomahomaho Oct 23, 2012

Contributor

W dniu 23.10.2012 08:42, C Anthony Risinger pisze:

this is still relevant to you, yes?

could you rebase your work into a single, unified commit (with
title/body message explaining the change, and ideally, how to use it)?
i'm unable to merge it as-is for whatever reason, so you may have to
resolve some conflicts and verify proper operation.

looking to handle this in the next few days, thanks for your patience,
much appreciated.

Hmm ... :). I will try to. I'm not very familiar with git (so much
different to mercurial, even if it looked like very similar at
beginning), but I think that good approach would be if I merge it in my
fork.

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

Contributor

mahomahomaho commented Oct 23, 2012

W dniu 23.10.2012 08:42, C Anthony Risinger pisze:

this is still relevant to you, yes?

could you rebase your work into a single, unified commit (with
title/body message explaining the change, and ideally, how to use it)?
i'm unable to merge it as-is for whatever reason, so you may have to
resolve some conflicts and verify proper operation.

looking to handle this in the next few days, thanks for your patience,
much appreciated.

Hmm ... :). I will try to. I'm not very familiar with git (so much
different to mercurial, even if it looked like very similar at
beginning), but I think that good approach would be if I merge it in my
fork.

pozdrawiam

Łukasz Mach - lukasz.mach@pagema.net

@mahomahomaho

This comment has been minimized.

Show comment
Hide comment
@mahomahomaho

mahomahomaho Dec 4, 2012

Contributor

I think I made mess only.

I'm going to re-create my fork from scratch, and make my changes again. I wonder if this pull request will disappear, or I will be able to "switch" to new repo in same pull request?

Contributor

mahomahomaho commented Dec 4, 2012

I think I made mess only.

I'm going to re-create my fork from scratch, and make my changes again. I wonder if this pull request will disappear, or I will be able to "switch" to new repo in same pull request?

@anthonyrisinger

This comment has been minimized.

Show comment
Hide comment
@anthonyrisinger

anthonyrisinger Dec 4, 2012

Member

nah, you can reuse this request, no problem -- this request is tied to the dfevents branch -- you just need to [force] push to this branch: git push -f origin dfevents.

Member

anthonyrisinger commented Dec 4, 2012

nah, you can reuse this request, no problem -- this request is tied to the dfevents branch -- you just need to [force] push to this branch: git push -f origin dfevents.

@mahomahomaho

This comment has been minimized.

Show comment
Hide comment
@mahomahomaho

mahomahomaho Dec 5, 2012

Contributor

I think this pull request is broken too. It refers to commits which are no longer alive (repository deleted and another one, with new name created).

So I will close it, and reopen shadow of it, with new commits :)

Contributor

mahomahomaho commented Dec 5, 2012

I think this pull request is broken too. It refers to commits which are no longer alive (repository deleted and another one, with new name created).

So I will close it, and reopen shadow of it, with new commits :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment