自定义 GWT 日期框
Customizing GWT DateBox
我正在定制 GWT 2.5.1 的 DateBox。
我的要求是:我不能允许超过 31/12/9999 的日期,我需要始终严格地进行日期解析(也就是说,我只需要允许 DD/MM/YYYY 格式的日期,这是我的 MyDatePickerFormat 格式使用的格式),我需要检索解析错误并将错误传播到编辑器框架(并在实现 HasEditorErrors 的自定义 Widget 的某个位置显示它)。
这是我为此目的创建的 类 列表:
1. MyDateBox extends DateBox implements ParseEvent.HasParseEventHandlers.
2. MyDatePickerFormat implements Format
3. MyDateBoxEditorDecorator extends Composite implements HasEditorErrors<Date>, HasEnabled, HasValue<Date>,
IsEditor<LeafValueEditor<Date>>, HasEditorDelegate<Date>
详细:
1.
public MyDateBox()
{
super();
this.getTextBox().setMaxLength(MyDateBox.MyDatePickerFormat.MAX_DATE_LENGTH);
final MyDatePickerFormat myPickerFormat = new MyDateBox.MyDatePickerFormat();
setFormat(myPickerFormat);
ParseEventHandler handler = new ParseEventHandler()
{
@Override
public void onParseEvent(ParseEvent event)
{
MyDateBox.this.fireEvent(event);
}
};
myPickerFormat.setParseEventHandler(handler);
}
Instanciates 1 MyDateBox object.
Takes a ParseEventHandler to propagate parsing issues.
Overrides com.google.gwt.user.datepicker.client.DateBox.Format.parse(DateBox,
String, boolean) to always call
com.google.gwt.i18n.shared.DateTimeFormat.parseStrict(String), and caps the
parsed date to 01/01/9999 at most.
At the end of the parse method, it instanciates a ParseEvent and calls the "parent" ParseEventHandler handler method.
3.
public MyDateBoxEditorDecorator()
{
dateBox = new MyDateBox();
dateBox.addParseErrorHandler(new ParseEventHandler()
{
@Override
public void onParseEvent(ParseEvent event)
{
MyDateBoxEditorDecorator.this.onParseEvent(event);
}
});
initWidget(Binder.BINDER.createAndBindUi(this));
contents.add(dateBox);
}
我的问题如下:
- The event handling seems pretty clumsy to me (an event is instanciated
and handled using one handler, which then fires this event at the
enclosing Widget level (let's call that widget "w") which is handled
by the handlers that were added to w using its 'addParseHandler'
method. That final handler calls an instance method on my
MyDateBoxEditorDecorator instance. These are many steps, I guess there must be better ways to handle this ? (I am overcomplicating it ?)
- MyDateBoxEditorDecorator error handling does
not integrate well with my editor hierarchy. What happens is that, when the
user modifies the date field content (repeatedly...), multiple parsing
events are eventually issued. My MyDateBoxEditorDecorator instance
(let's call it "myDateBoxEditor") ends up calling its delegate's
recordError() multiple times. Then, when I finally call flush() to
flush my entire editor hierarchy, myDateBoxEditor's
showError(List errors) method gets too many errors as
input (all errors since the last call to flush(), I think). What can I
do to avoid that ? (would using an additionnal driver with my
MyDateBoxEditorDecorator instances and flush it -every time parsing is
done- be the right solution for that problem ?)
谢谢。
PS。我对 SO 格式不太了解,已经尽力了(它看起来很丑但足够可读)。
只是一个 heads-up:我已经解决了最大的问题(我的编辑器层次结构错误处理问题)。原因是我曾经在单个编辑器周期中多次调用 getValue() (例如,每次用户修改字段时),这就是导致显示重复错误的原因 - 根据 Valueboxeditordecorator 来源,一个是 不应该这样做。
至于其他问题,我希望有优雅的解决方案,但我认为可以。
我正在定制 GWT 2.5.1 的 DateBox。
我的要求是:我不能允许超过 31/12/9999 的日期,我需要始终严格地进行日期解析(也就是说,我只需要允许 DD/MM/YYYY 格式的日期,这是我的 MyDatePickerFormat 格式使用的格式),我需要检索解析错误并将错误传播到编辑器框架(并在实现 HasEditorErrors 的自定义 Widget 的某个位置显示它)。
这是我为此目的创建的 类 列表:
1. MyDateBox extends DateBox implements ParseEvent.HasParseEventHandlers.
2. MyDatePickerFormat implements Format
3. MyDateBoxEditorDecorator extends Composite implements HasEditorErrors<Date>, HasEnabled, HasValue<Date>,
IsEditor<LeafValueEditor<Date>>, HasEditorDelegate<Date>
详细:
1.
public MyDateBox()
{
super();
this.getTextBox().setMaxLength(MyDateBox.MyDatePickerFormat.MAX_DATE_LENGTH);
final MyDatePickerFormat myPickerFormat = new MyDateBox.MyDatePickerFormat();
setFormat(myPickerFormat);
ParseEventHandler handler = new ParseEventHandler()
{
@Override
public void onParseEvent(ParseEvent event)
{
MyDateBox.this.fireEvent(event);
}
};
myPickerFormat.setParseEventHandler(handler);
}
Instanciates 1 MyDateBox object. Takes a ParseEventHandler to propagate parsing issues.
Overrides com.google.gwt.user.datepicker.client.DateBox.Format.parse(DateBox, String, boolean) to always call com.google.gwt.i18n.shared.DateTimeFormat.parseStrict(String), and caps the parsed date to 01/01/9999 at most.
At the end of the parse method, it instanciates a ParseEvent and calls the "parent" ParseEventHandler handler method.
3.
public MyDateBoxEditorDecorator()
{
dateBox = new MyDateBox();
dateBox.addParseErrorHandler(new ParseEventHandler()
{
@Override
public void onParseEvent(ParseEvent event)
{
MyDateBoxEditorDecorator.this.onParseEvent(event);
}
});
initWidget(Binder.BINDER.createAndBindUi(this));
contents.add(dateBox);
}
我的问题如下:
- The event handling seems pretty clumsy to me (an event is instanciated and handled using one handler, which then fires this event at the enclosing Widget level (let's call that widget "w") which is handled by the handlers that were added to w using its 'addParseHandler' method. That final handler calls an instance method on my MyDateBoxEditorDecorator instance. These are many steps, I guess there must be better ways to handle this ? (I am overcomplicating it ?)
- MyDateBoxEditorDecorator error handling does not integrate well with my editor hierarchy. What happens is that, when the user modifies the date field content (repeatedly...), multiple parsing events are eventually issued. My MyDateBoxEditorDecorator instance (let's call it "myDateBoxEditor") ends up calling its delegate's recordError() multiple times. Then, when I finally call flush() to flush my entire editor hierarchy, myDateBoxEditor's showError(List errors) method gets too many errors as input (all errors since the last call to flush(), I think). What can I do to avoid that ? (would using an additionnal driver with my MyDateBoxEditorDecorator instances and flush it -every time parsing is done- be the right solution for that problem ?)
谢谢。
PS。我对 SO 格式不太了解,已经尽力了(它看起来很丑但足够可读)。
只是一个 heads-up:我已经解决了最大的问题(我的编辑器层次结构错误处理问题)。原因是我曾经在单个编辑器周期中多次调用 getValue() (例如,每次用户修改字段时),这就是导致显示重复错误的原因 - 根据 Valueboxeditordecorator 来源,一个是 不应该这样做。 至于其他问题,我希望有优雅的解决方案,但我认为可以。