Skip to main content

Form/Binding blues...

3 replies [Last post]
Anonymous

.. can you take some more grumbling, Amy :-?

The context:
I tried something very simple - have a button bar with submit/reset
buttons which are coupled to the corresponding actions and en/disable
them in synch with the modified state of the form.

That's possible though a bit enervating: register
propertyChangeListeners to every single Binding of the form. It's
unsafe/incomplete because the Form does not report additional/removed
Bindings and FormBinding is buggy in that it does not report modified
changes of contained bindings. And it's dirty code because it needs a
reference to the view (the JForm) to do some work which is a (data)
control task.

All these issues can be resolved by introducing something like a
"FormModel" which would handle the collection of bindings, guarantee
proper notifications (also after remove/add bindings) and do the work
...

Having a look at the current api:

The Binding api is not clear about its bound properties: judging from
the implementation of AbstractBinding they are

- modified
- validState
- validationPolicy (which is not a Binding method - just curious: why
not?)

If we agree that those are indeed bound properties (which they should
be) then FormBinding is violating its contract by not reporting nested
changes.

Additionally Binding supports some operations

- pull
- push
- isValid - which looks like a property but actually is the process of
validating (how about renaming to validate?)

JForm has (besides the creation of components/bindings) a similar api
(working on top of a collection of bindings) for controlling the
transfer/state of the bound values

property (unbound)
- modified

operations
- pull
- push
- isFormValid - which again is a canditate for renaming

Guess what's coming :-)

interface Transaction {

//---- bound properties
boolean isModified();
// ?? boolean getValidState();

//---- operations
boolean pull();
boolean push();
boolean validate();

//-------- notification
void add/removePropertyChangeListener(...);

}

interface Binding extends Transaction {
// the binding specifics...
}

interface FormModel extends Transaction {

Binding[] getBindings();
// anything else?

}

with a JForm exposing the FormModel (or BindingModel? - could not come
up with a really fitting name)

JForm ...{

FormModel getModel();
// support a setter?
// it would remove all old components and add the
// ones represented by the bindings
void setModel(FormModel)
}

the task above would be easy and safe. An additional plus might be that
a "Transaction" (again the name might need some polish) does not have
any inherent notion of transfering between model <--> view but can be
re-used anywhere, implementations are free to define sender/receiver as
they like. That's just an after-thought - I'm no database enthusiast

Opinions, comments?

Greetings
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Kleopatra

Hi Amy,

> > .. can you take some more grumbling, Amy :-?
>
> always (9 years working on the jdk has toughened me up :-)

[..snip..]

Looks like we agree in general. Just a couple of comments:

> Agreed on renaming isValid. One tricky part of the *valid* nomenclature
> runs into conflict and confusion with Component's "validate" APIs
> which relate to layout. maybe "validateData" ?
>

didn't think of that one... yeah, if a JForm (or any custom form-like
component) should expose the method then it needs a different name, a
postfix "Data" sounds okay ....
>
> interface Binding {
>
> //---- bound properties
> boolean isModified();
> int getValidState(); // UNVALIDATED,VALID,INVALID
>
> //---- operations
> boolean pullData();
> boolean pushData();
> boolean validateData();
> ? getValidationErrors();
>
> //-------- notification
> void add/removePropertyChangeListener(...);
> }
>

- though I would not append it to the push/pull, they are expressive
enough. But may be just a matter of taste.

As for the "Binding"/"UIBinding" I would prefer that to become
??/"Binding" (with ?? yet to be found) because for me "binding" is
always the layer nearest to the component (or the view model).

> interface BindingGroup extends Binding {
> Binding[] getBindings();
> }
>

Hmm, needs to return (in your terminology) a UIBinding[]. That's a
slight asymmetry which might indicate that the design is not yet quite
correctly factored. We'll have to play a bit with it, I think.

> JForm implements BindingGroup {
> // has-a or is-a or both??? (to be or not to be...)
>

that is the question :-) Has-a only, IMO.

>
> - I really want to avoid requiring (or falsely implying) that JForm
> users have to construct and install a "FormModel". My first version
> of the API had that, and although it sits nicely in the Swing patterns,
> it felt way too confining. It should be easy to just bind to fields
> on arbitrary data models without having to formally construct a 'model'.
> Obviously veneer API could be a way to facilitate this if we decide
> on "has-a" vs. "is-a".
>

100% ACK.

> - Related to that, I think BindingGroup (FormModel, whatever we call it)
> should feel easily usable outside a JForm, which is why my initial
> preference is not to call it a "FormModel" (avoiding the "TableModel"
> trap).
>

okay.

> As an aside, I'm very keen to get your take on whether we should abandon
> the jdnc binding approach in favor of Karsten's. You now have intimate
> experience with both AND an unbiased perspective as the creator of neither.

you are overestimating my progress into JDNC :-) Can't decide yet - at
the moment I'm only trying to _use_ Karstens binding in the context of
the jdnc api, mostly to "feel the wind" of jdnc.

> I intend to explore this option (as well as the implementation you posted
> awhile back), but have just been struggling to find the time, since I'm
> trying to keep up with forums, bugs, and pulling together a cohesive 1.0
> project plan.
>

Sounds like your team's a bit understaffed

Greetings
Jeanette

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

Amy Fowler

Kleopatra wrote:

> .. can you take some more grumbling, Amy :-?

always (9 years working on the jdk has toughened me up :-)
The current binding/form APIs are admittedly a very rough first cut.

>
> The context:
> I tried something very simple - have a button bar with submit/reset
> buttons which are coupled to the corresponding actions and en/disable
> them in synch with the modified state of the form.

I agree this should be easy to do and automatic in the highlevel JNForm
component. And I also agree that the current API is wholely deficient
in making this easy.

[snip]
>
> Having a look at the current api:
>
> The Binding api is not clear about its bound properties: judging from
> the implementation of AbstractBinding they are
>
> - modified
> - validState
> - validationPolicy (which is not a Binding method - just curious: why
> not?)

validationPolicy *should* be a bound Binding property - this is just an
oversight on my part.

>
> If we agree that those are indeed bound properties (which they should
> be) then FormBinding is violating its contract by not reporting nested
> changes.
>
> Additionally Binding supports some operations
>
> - pull
> - push
> - isValid - which looks like a property but actually is the process of
> validating (how about renaming to validate?)

Agreed on renaming isValid. One tricky part of the *valid* nomenclature
runs into conflict and confusion with Component's "validate" APIs
which relate to layout. maybe "validateData" ?

>
> JForm has (besides the creation of components/bindings) a similar api
> (working on top of a collection of bindings) for controlling the
> transfer/state of the bound values

I would really like to de-couple the processing of a group (and or
hierarchy) of bindings from the JForm component. I think a JForm component
is great for convenience, but it should be *very* easy to use the
binding framework for your own garden-variety panels/gui if you wish.
I think this jives well with your proposal to factor out the API
into a separate interface and/or class.

>
> property (unbound)
> - modified
>
> operations
> - pull
> - push
> - isFormValid - which again is a canditate for renaming
>
> Guess what's coming :-)
>
> interface Transaction {
>
> //---- bound properties
> boolean isModified();
> // ?? boolean getValidState();
>
> //---- operations
> boolean pull();
> boolean push();
> boolean validate();
>
> //-------- notification
> void add/removePropertyChangeListener(...);
>
> }
>
> interface Binding extends Transaction {
> // the binding specifics...
> }
>
> interface FormModel extends Transaction {
>
> Binding[] getBindings();
> // anything else?
>
> }
>
> with a JForm exposing the FormModel (or BindingModel? - could not come
> up with a really fitting name)
>
> JForm ...{
>
> FormModel getModel();
> // support a setter?
> // it would remove all old components and add the
> // ones represented by the bindings
> void setModel(FormModel)
> }
>
> the task above would be easy and safe. An additional plus might be that
> a "Transaction" (again the name might need some polish) does not have
> any inherent notion of transfering between model <--> view but can be
> re-used anywhere, implementations are free to define sender/receiver as
> they like. That's just an after-thought - I'm no database enthusiast

I like your train of thought, but agree "transaction" might be a dangerous
term to use in the data-aware space.

In looking at what's in Binding, but not in Transaction:
- getComponent
- getDataModel
- getFieldName
- getValidationErrors

Trying something out for size.......

interface Binding {

//---- bound properties
boolean isModified();
int getValidState(); // UNVALIDATED,VALID,INVALID

//---- operations
boolean pullData();
boolean pushData();
boolean validateData();
? getValidationErrors();

//-------- notification
void add/removePropertyChangeListener(...);
}

interface UIBinding extends Binding
//---- bound properties
int getValidationPolicy();

//---- connecting components to data model
Component getComponent();
DataModel getDataModel();
String getFieldName();
}

interface BindingGroup extends Binding {
Binding[] getBindings();
}

JForm implements BindingGroup {
// has-a or is-a or both??? (to be or not to be...)

setBindingGroup(BindingGroup group);
}

DefaultBindingGroup implements BindingGroup {
void addBinding(Binding b);
void removeBinding(Binding b);
}

Couple thoughts:

- I really want to avoid requiring (or falsely implying) that JForm
users have to construct and install a "FormModel". My first version
of the API had that, and although it sits nicely in the Swing patterns,
it felt way too confining. It should be easy to just bind to fields
on arbitrary data models without having to formally construct a 'model'.
Obviously veneer API could be a way to facilitate this if we decide
on "has-a" vs. "is-a".

- Related to that, I think BindingGroup (FormModel, whatever we call it)
should feel easily usable outside a JForm, which is why my initial
preference is not to call it a "FormModel" (avoiding the "TableModel"
trap).

As an aside, I'm very keen to get your take on whether we should abandon
the jdnc binding approach in favor of Karsten's. You now have intimate
experience with both AND an unbiased perspective as the creator of neither.
I intend to explore this option (as well as the implementation you posted
awhile back), but have just been struggling to find the time, since I'm
trying to keep up with forums, bugs, and pulling together a cohesive 1.0
project plan.

Thanks for the grumbling,
Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

charles.armstrong
Offline
Joined: 2006-02-17

I think the JGoodies binding approach and the
JDNC approach are aimed at different types of
developers. The JDNC is very data orientated,
and works well for binding to simple data structures -
like Rowsets - but doesn't map well to Domain Objects.

The JGoodies approach is for more complex Object
Orientated clients. It won't suit developers who don't
get Object Orientation/Domain Objects etc. It also
makes persistence harder as you have to map the
Domain Objects to a persistence structure (maybe via
something like Hibernate).

I prefer a (Domain) Object Orientated approach -
but think it would mean a big change in philosophy for JDNC.

Charles.