Skip to main content

dynamically changing drop-down content

4 replies [Last post]
bpk
Offline
Joined: 2006-02-17
Points: 0

How do I change the content of a drop-down box based on the selection of another drop-down? i.e., I've got two set of and I'd like to switch off on which one I use for a particular drop-down, based on other form input.

Is it possible to do this just with the XML markup?

Reply viewing options

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

jdnc-interest@javadesktop.org wrote:
> How do I change the content of a drop-down box
> based on the selection of another drop-down?
> i.e., I've got two set of and I'd
> like to switch off on which one I use for a
> particular drop-down, based on other form input.

Currently everybody seems to stumble over the still crude binding to
ComboBoxes :-)

The theory:

- listen to the DataModel to get notified of value changes of the
"other" field

- refresh the enumValue of the metaData

now the ComboBoxBinding should update the list ...

In practice that's not working because:

a) the binding is not yet listening to metaData changes (will be added soon)
b) even if it did it would not help while editing of a form, because
there is no clean way to get hold of the uncommitted but changed value.

Hmm ... b) is really nasty but seems to be a more general problem, when
the binding caches the value: the model is updated on push() only and
consequently only then notifies interested parties. Related to that is
an even nastier issue: form-level (DataModel-level) validation does not
work because there is no way to validate the changed but not yet
committed value.

Any ideas? May well be that I simply have a knot in my head :-)

Jeanette

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

mikeazzi
Offline
Joined: 2003-08-11
Points: 0

> In practice that's not working because:
>
> a) the binding is not yet listening to metaData
> changes (will be added soon)
> b) even if it did it would not help while editing of
> a form, because
> there is no clean way to get hold of the uncommitted
> but changed value.
>
> Hmm ... b) is really nasty but seems to be a more
> general problem, when
> the binding caches the value: the model is updated on
> push() only and
> consequently only then notifies interested parties.
> Related to that is
> an even nastier issue: form-level (DataModel-level)
> validation does not
> work because there is no way to validate the changed
> but not yet
> committed value.
>
> Any ideas? May well be that I simply have a knot in
> my head :-)
>
> Jeanette
>

Hi Jeanette,

I have a couple of questions, because I'm a little confused and I need to get some clarity on some basic assumptions. I apologize if this has been discussed before.

In your answer above, are you making the assumption that while making edits to a form, none of the changes is submitted to the back end until the finish, where we explicitly press a submit button, all those changes are then submitted in one shot, committed on the back end, and the screen is refreshed to reflect the changes made? That's certainly one mode of interaction, where only basic (data type) validation is done on the front, and business logic validation is deferred until the form is submitted, and done on the back end.
But there is also another mode (more interactive) of interaction, which we currently use in our application. In this mode every change to a field on the form triggers a implicit submit of that new value to the back end, where business logic validation is performed, and updates are pushed to the front end, which causes to refresh the values displayed. Here we differentiate between submitted values, and committed values, as all these changes are only submitted, and cached in the business tier but not yet committed until the user explicitly does so. This is certainly a more interactive style of communication, and it's very important here to only pass changes back and forth to minimize latency. But it's great as far as end to end validation, and keeping dynamic content uptodate is concerned.
So my questions again are, are you basing you arguments on the assumption that binding framework uses the first mode of interaction, or the second (the highly interactive one)? Because I believe none of these issues are present if the second mode of interaction is assumed. And is the framework going to support both modes? If not why?

Thanks for your time,
Mike

kleopatra
Offline
Joined: 2003-06-11
Points: 0

Hi Mike,

> I have a couple of questions, because I'm a little
> confused and I need to get some clarity on some basic
> assumptions. I apologize if this has been discussed
> before.
>

questions never require apologies :-) I highly appreciate any feedback!

> In your answer above, are you making the assumption
> that while making edits to a form, none of the
> changes is submitted to the back end until the
> finish, where we explicitly press a submit button,
> all those changes are then submitted in one shot,
> committed on the back end, and the screen is
> refreshed to reflect the changes made?

Sorry for having been sloppy - I referred to the current situation only where the bindings are responsible for caching the value until they receive an explicit push(). That method is called in a JForm commit for every contained binding. So yes, currently we have a bulk commit of all bindings in a "screen", kind of dialog-wise.

I'm aware that we need a more interactive - how can we call it? field-level commit? - as well. As I see it the developers need easy access to toggle between different modes/granularities of commit/validate.

Anyway, the problem mentioned in my last post will still be present in the bulk-wise commit. My suspicion is that we are doing the caching somehow wrong, but that's just a first feeling. Reading John's blog about validation convinced me that there are deeper pits than I expected :-)

> application. In this mode every change to a field on
> the form triggers a implicit submit of that new
> value to the back end, where business logic
> validation is performed, and updates are pushed to
> the front end, which causes to refresh the values
> displayed. Here we differentiate between submitted
> values, and committed values, as all these changes
> are only submitted, and cached in the business tier
> but not yet committed until the user explicitly does
> so.

I see ... have to think a bit how this relates to the current situation - hmm, maybe we can add a auto-commit mode in the binding which will push all changes directly into the DataModel.

> So my questions again are, are you basing you
> arguments on the assumption that binding framework
> uses the first mode of interaction, or the second
> (the highly interactive one)? Because I believe none
> of these issues are present if the second mode of
> interaction is assumed. And is the framework going to
> support both modes? If not why?

Just to clarify:

- my concern is based on the _current_ implementation which is the first mode in your numbering
- I agree that it'll probably will not be an issue in the second mode
- yes, I think the framework must support both

Jeanette

rbair
Offline
Joined: 2003-07-08
Points: 0

Hey Jeanette, just a couple of comments

> I see ... have to think a bit how this relates to the
> current situation - hmm, maybe we can add a
> auto-commit mode in the binding which will push all
> changes directly into the DataModel.

We definately need to add an auto-commit mode -- at least, one that will autocommit changes from the gui components to the DataModel.

Here's another use case for ya. I have a user name. I display the user name in the Frame title, and I also have an edit field for changing the user name. I want all of my edits to automatically update the title.

One way of doing this is to auto-commit the changes to the DataModel, and rely on the notification mechanism to notify the Binding for the Frame that the name has changed, thus refreshing it.

> - my concern is based on the _current_ implementation
> which is the first mode in your numbering
> - I agree that it'll probably will not be an issue in
> the second mode
> - yes, I think the framework must support both

I agree with all of these

Richard