welcome to the group
David Durham
Thanks for your interest in the project. I've not been particularly
motivated to do more work with it because I'm no longer doing GWT "on
the job." However, I still enjoy working with GWT and this project in
particular. If interested, let's start filing issues and knocking out
some features.
Dave
charlie
David Durham
> Ok great, let me get it built and running.
Let me know if you have any issues with the build. It's maven2, so
should be fairly straight forward. I know I had to manually install
some additional libraries for the appengine demo, but the core library
did not require non-maven-central dependencies, as I recall.
Let me know,
Dave
David Durham
david.durham.jr
correct or document the issues. One I know is that the gxt.jar is not
in the maven central repository, last time I checked.
gwtfanb0y
this project sounds very interesting to me, i give it a try in the
next few days.
I have a question, is gxtform working with ListField (ListStore) and
Drag N Drop
components (ListViewDragSource, ListViewDropTarget) ?
David Durham
<siegfri...@googlemail.com> wrote:
>
> Hello David,
> this project sounds very interesting to me, i give it a try in the
> next few days.
> I have a question, is gxtform working with ListField (ListStore) and
> Drag N Drop
> components (ListViewDragSource, ListViewDropTarget) ?
No it's not. If you're interested, let's talk about how to best implement.
charlie
gwtfanb0y
project! You can save much time creating forms with binding.
It works very smart but i am missing the previously mentioned
features. Any idea how to implement them?
On 30 Okt., 15:12, David Durham <david.durham...@gmail.com> wrote:
> On Fri, Oct 30, 2009 at 2:55 AM, gwtfanb0y
>
David Durham
>
> So i had spend some time for gxtforms and i think it is a great
> project! You can save much time creating forms with binding.
> It works very smart but i am missing the previously mentioned
> features. Any idea how to implement them?
Yeah, I have some ideas. You're looking for something like:
@ListField(dragAndDrop=true)
private List<MyClass> myList;
I think that's how the annotation would go, though I haven't thought
too much about it. The implementation is bit more tricky.
1. How do we populate the list options? Enumerations are an easy
target. Other types are more difficult and touch a few different
parts of the server-side. Likely, there'd need to be some custom list
options code on the server that a user would have to write.
2. Then we need to plug in a Converter on the client side, similar to
what has been done for enumerations.
-Dave
gwtfanb0y
my ideas:
* Only one List with some attributes:
@ListField(styleName="mycss_style", enabled=true,
onClick="doClickAction()")
private ListStore<Person> personListStore;
* Drag and Drop is similar:
@ListField(id="dragA", boundedWithDropTarget="dragB")
private ListStore<Person> availablePersonListStore;
@ListField(id="dragB" boundedWithDragSource="dragA")
private ListStore<Person> assignedPersonListStore;
What do you (and others) think?
On 1 Nov., 17:26, David Durham <david.durham...@gmail.com> wrote:
David Durham
On Mon, Nov 2, 2009 at 2:06 AM, gwtfanb0y <siegfri...@googlemail.com> wrote:
> I am not sure how we can use the annotation in a proper way. Here are
> my ideas:
>
> * Only one List with some attributes:
>
> @ListField(styleName="mycss_style", enabled=true,
> onClick="doClickAction()")
> private ListStore<Person> personListStore;
Probably styleName and enabled need to be added for all the fields.
I'll start a feature list for the next release on the wiki.
I don't understand onClick. If this is a hook into a native
javascript function, I'm not sure if we should add it to the core
library. I have some other ideas about one off customization that
would allow this kind of thing to be done outside of annotations.
I'll describe that more when I get a chance.
> * Drag and Drop is similar:
>
> @ListField(id="dragA", boundedWithDropTarget="dragB")
> private ListStore<Person> availablePersonListStore;
One thing that I've been careful about is to not require any gxt
dependencies in the model objects (in fact the only gxtforms
dependencies in the model objects are the annotations themselves) .
There are very good reasons for having a clean separation between gxt
and the classes being annotated. Will go more into this when I can.
> @ListField(id="dragB" boundedWithDragSource="dragA")
> private ListStore<Person> assignedPersonListStore;
>
>
> What do you (and others) think?
Thanks for your input.
-Dave
David Durham
>> onClick="doClickAction()")
>> private ListStore<Person> personListStore;
>
> Probably styleName and enabled need to be added for all the fields.
> I'll start a feature list for the next release on the wiki.
http://code.google.com/p/gxtforms/wiki/NextReleaseFeatures
> I don't understand onClick. If this is a hook into a native
> javascript function, I'm not sure if we should add it to the core
> library. I have some other ideas about one off customization that
> would allow this kind of thing to be done outside of annotations.
> I'll describe that more when I get a chance.
I added some brief info about subclasses for FormPanel and FieldSet
(not sure what to call them). The basic idea for now is to add
getField(String fieldName) and getFieldSet(String fieldSetName)
methods so that someone could, for instance, add an additional onclick
handler that otherwise would be very difficult (probably not worth it)
to implement with annotations.
-Dave
gwtfanb0y
>> @ListField(styleName="mycss_style", enabled=true,
>> onClick="doClickAction()")
>> private ListStore<Person> personListStore;
>> javascript function, I'm not sure if we should add it to the core
>> library. I have some other ideas about one off customization that
>> would allow this kind of thing to be done outside of annotations.
>> I'll describe that more when I get a chance.
Events on the created ListField.
Or we provide an other way to add listener. I think that using
ListStore to add Listener for
Click-Events is to late in the command-chain.
>
> I added some brief info about subclasses for FormPanel and FieldSet
> (not sure what to call them). The basic idea for now is to add
> getField(String fieldName) and getFieldSet(String fieldSetName)
> methods so that someone could, for instance, add an additional onclick
> handler that otherwise would be very difficult (probably not worth it)
> to implement with annotations.
I have an other idea for an improvement, what me sometimes really
makes me mad is
the missing function to clean the isDirty-state. You can solve it with
this snippet:
public class MyFormPanel extends FormPanel {
public void clearDirtyFields() {
for (Field f : getFields()) {
if (f.isDirty()) {
f.setOriginalValue(f.getValue());
}
}
}
}
Setting new assinged values as default (original) values is possible
with this snippet:
formbinding.addListener(Events.Bind, new Listener<BaseEvent>() {
public void handleEvent(BaseEvent be) {
for (FieldBinding fieldbinding : formbinding.getBindings
()) {
fieldbinding.getField().setOriginalValue
(originalValue);
}
}
}
Hope this can help you!
- Siegfried
David Durham
> I have an other idea for an improvement, what me sometimes really
> makes me mad is
> the missing function to clean the isDirty-state. You can solve it with
> this snippet:
>
> public class MyFormPanel extends FormPanel {
> public void clearDirtyFields() {
> for (Field f : getFields()) {
> if (f.isDirty()) {
> f.setOriginalValue(f.getValue());
> }
> }
> }
> }
I don't understand the problem you're solving here. Can you explain
it to me from a user's perspective?
One thing I've done in the GXTFormBuilder class is clear the
validation errors that appear after databinding. Not sure if that's
related to the problem you're solving.
-Dave
gwtfanb0y
set the updated data as new original data. My workaround for this was
the code snippet.
Imagine you are browsing through a list of Userdata-Models, when you
click
on a Model the data is injected into the corresponding FormBinding.
Now the form thinks
you have changed data (isDirty==true). To avoid this, you have to use
the snippet.
I don't how you can use it, just posted it :-)
> One thing I've done in the GXTFormBuilder class is clear the
> validation errors that appear after databinding. Not sure if that's
> related to the problem you're solving.
On 2 Nov., 21:11, David Durham <david.durham...@gmail.com> wrote:
David Durham
>
> The problem occurs when you update the model in runtime and want to
> set the updated data as new original data. My workaround for this was
> the code snippet.
> Imagine you are browsing through a list of Userdata-Models, when you
> click
> on a Model the data is injected into the corresponding FormBinding.
> Now the form thinks
> you have changed data (isDirty==true). To avoid this, you have to use
> the snippet.
> I don't how you can use it, just posted it :-)
Got it. Thanks.