Let me offer a use case and see if that helps. If I'm just off base
here, do please let me know.
First, some definitions (please excuse the crudity of these models. I
didn't have time to build them to scale):
public interface HasData<T> {
public T getData();
public void setData(T data);
}
public abstract class Form<T> extends Composite implements HasData<T> {
// Some reusable form-y stuff here.
}
public abstract class ContrivedReadOnlyWidget<T> extends Composite
implements HasData<T> {
// A contrived example of something else that HasData.
}
public class Foo {
// My data
}
public class LoadFooCommand implements Command {
private String fooId;
private HasData<T> dataWidget;
public LoadFooCommand(String fooId, HasData<Foo> dataWidget) {
this.fooId = fooId;
this.dataWidget = dataWidget;
}
// Load the Foo with the specified into the dataWidget.
public void execute() {
Foo myFoo = getFoo(fooId);
dataWidget.setData(myFoo);
}
}
I have a pattern very close to this in my current project. Basically,
I can reuse simple Commands to do things like populate forms or
display pages with existing database records.
What would you do with the DataManager interface in this example? Or
if it doesn't apply in this example, what would be an example of how
it would be used?
On Fri, Oct 3, 2008 at 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"
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
