I was thinking of a slightly more complex use case where you might have full
model objects.
public class ListBoxModel implements HasValue<ListItem>{
...
}
public class ListBoxDataManager implements DataManager<ListBox,
ListBoxModel>{
...
}
public class MyListBox extends Composite implements HasValue<ListItem>{
private ListBox wrappedWidget = new ListBox();
private ListBoxModel model =
ListBoxDataManager().getCurrentManager().get(this);
ListItem getValue() {
model.getValue();
}
}
>
> public void setData(ListBox widget, String data) {
>
> // go through the list of
> for (int i = 0; i < widget.getItemCount(); i++) {
> if (widget.getValue(i).equals(data)) {
> widget.setSelectedIndex(i);
> break;
> }
> }
> }
> }
On Fri, Oct 3, 2008 at 11:59 AM, Arthur Kalmenson <[EMAIL PROTECTED]>wrote:
>
> > > Why wrappers? Why not have the widgets simply implement a HasData
> > > interface?
>
> As Emily pointed out, this helps separate presentation logic from the
> data model. Furthermore, there are cases when you want to get data out
> of the same widget in different ways. A good example is a DataManager
> for ListBoxes. A simple implementation would look something like this:
>
> public class ListBoxDataManager implements DataManager<ListBox,
> String> {
> public String getData(ListBox widget) {
> String result = null;
> if (widget.getSelectedIndex() > -1) {
> result = widget.getValue(widget.getSelectedIndex());
> }
> return result;
> }
>
> public void setData(ListBox widget, String data) {
>
> // go through the list of
> for (int i = 0; i < widget.getItemCount(); i++) {
> if (widget.getValue(i).equals(data)) {
> widget.setSelectedIndex(i);
> break;
> }
> }
> }
> }
>
> However, if you're working with a lot of ListBoxes that have a default
> value set at index 0, you might create a different DataManager to
> handle that particular use case and return null if the first index is
> selected.
>
> > The same widgets might be used to get/set different data types and it
> > separates the presentation logic from the data model, so separating the
> two
> > seems to make some sense. On the other hand, it means that there is no
> > simple interface that can be used when you actually do have data model
> > objects:
> >
> > So what if we combined the two:
> >
> > public interface HasData<T> {
> > public T getData();
> > public void setData(T data);
> >
> > }
> >
> > then:
> >
> > public interface DataManager<T, S extends HasData> {
> > public HasData getData(T widget);
> > public void setData(T widget, S data);
>
> That's a good point but I'm not sure I really understand the sample
> code. Is the idea that if I have a data model Widget, it would
> implement the HasData interface? It seems that S would end up being
> the same as T in the generic implementation. I'll try to implement
> this to get an idea what you mean.
>
> Best regards,
> Arthur Kalmenson
>
> On Oct 3, 11:25 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
> > Having worked on similar projects, I am very enthusiastic about the idea
> of
> > creating a full gwt forms module, as apart from it being a true pain in
> the
> > neck to create them by hand, improving the overall quality of such forms
> > will, in the long term, save lives, so I'm looking forward to this work.
> >
> > -------------------
> >
> > The same widgets might be used to get/set different data types and it
> > separates the presentation logic from the data model, so separating the
> two
> > seems to make some sense. On the other hand, it means that there is no
> > simple interface that can be used when you actually do have data model
> > objects:
> >
> > So what if we combined the two:
> >
> > public interface HasData<T> {
> > public T getData();
> > public void setData(T data);
> >
> > }
> >
> > then:
> >
> > public interface DataManager<T, S extends HasData> {
> > public HasData getData(T widget);
> > public void setData(T widget, S data);
> >
> >
> >
> > }
> > On Fri, Oct 3, 2008 at 11:06 AM, Isaac Truett <[EMAIL PROTECTED]> wrote:
> >
> > > Why wrappers? Why not have the widgets simply implement a HasData
> > > interface?
> >
> > > public interface HasData<T> {
> > > public T getData();
> > > public void setData(T data);
> > > }
> >
> > > Maybe I'm just not seeing your use case.
> >
> > > On Fri, Oct 3, 2008 at 10:55 AM, Arthur Kalmenson <
> [EMAIL PROTECTED]>
> > > wrote:
> >
> > > > Hello every,
> >
> > > > Just a little backgrounder for this RR. For some time now, a coworker
> > > > and I have been working on and off on a library/framework to simplify
> > > > creation of GWT applications, specifically those that cover most of
> > > > our use cases. For the most part, the applications we build involve
> > > > filling out rather large forms, retrieving data, generating reports,
> > > > etc. Building these large forms by hand is very tedious, so we
> created
> > > > an open source project called Mount Sinai Hospital Application
> Builder
> > > > (mshab) which you can find here:http://code.google.com/p/mshab/.
> >
> > > > I started to overhaul the project to make it easier to use and easier
> > > > to extend. As I started the overhaul, I noticed that the incubator
> > > > started to get populated with a lot of similar widgets and libraries
> > > > that I was redeveloping. I contacted Emily Crutcher about the
> > > > Validation aspect and we ended up talking a bit about the incubator.
> I
> > > > decided that it'll be best to try to commit back to the incubator so
> > > > we could avoid having to throw away our code after the incubator
> > > > implemented the same ideas. I'll start making RRs about the various
> > > > parts that we were working on to get feedback and hopefully
> > > > incorporate it into the incubator.
> >
> > > > Now, to the meat of the post. Right now, extracting data from widgets
> > > > is very different depending on the widget. From a TextBox, you call
> > > > textBox.getText(). For a ListBox you call
> > > > listBox.getValue(listBox.getSelectedItem()). Setting the data is
> > > > different too, and sometimes pretty "complex" (ListBox involves a
> > > > loop, etc). Therefore, I'm proposing a common interface that wraps
> > > > around core GWT widgets and provides one way to extract and set data
> > > > to widgets. There are a number of use cases where this can be
> applied.
> > > > Some good examples are validation and simple data binding.
> >
> > > > The interface is a straight forward generic interface that works with
> > > > a generic widget and a generic data type (comments removed):
> >
> > > > public interface DataManager<T, S> {
> >
> > > > public S getData(T widget);
> >
> > > > public void setData(T widget, S data);
> > > > }
> >
> > > > Here's an example of how it would be used to manage TextBoxBase
> > > > widgets.
> >
> > > > public class TextBoxBaseDataManager implements
> > > > DataManager<TextBoxBase, String> {
> >
> > > > public String getData(TextBoxBase widget) {
> > > > return widget.getText();
> > > > }
> >
> > > > public void setData(TextBoxBase widget, String data) {
> > > > widget.setText(data);
> > > > }
> > > > }
> >
> > > > To help developers easily get the appropriate DataManager for a
> > > > specific widget, I created a DataManagerCollection interface where
> you
> > > > can get the specific DataManager for a given widget and then start
> > > > working with it. The developer can either use existing
> > > > DataManagerCollection implementations or wire their own.
> >
> > > > public interface DataManagerCollection {
> >
> > > > public boolean hasDataManager(Widget widget);
> >
> > > > public DataManager<?, ?> getDataManager(Widget widget);
> >
> > > > public void setDataManager(Widget widget, DataManager<?, ?>
> > > > dataManager);
> > > > }
> >
> > > > We're currently working on creating wrappers for all the core GWT
> > > > widgets and the incubator ones. Feedback would be much appreciated.
> > > > Thank you for your time.
> >
> > > > Best regards,
> > > > Arthur Kalmenson
> >
> > --
> > "There are only 10 types of people in the world: Those who understand
> > binary, and those who don't"
> >
>
--
"There are only 10 types of people in the world: Those who understand
binary, and those who don't"
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
