Marking list models dirty when elements change

[Nick Hebner]

I have a Project bean that contains a list of ProjectEntry beans. Both
beans have separate models and separate editors. Clicking on a
ProjectEntry display widget in the Project editor causes the
ProjectEntry editor to be displayed for the clicked entry. Once the
ProjectEntry editor is finished, it issues a ProjectEntryUpdated event
which is received by the Project editor. My question is what should I
do in this event handler to signal that the Project should now be
dirty since an entry has been altered?

Thanks,

Nick Hebner

[Andrew]

Hi Nick,

Does you editor need to add and remove ProjectEntry's or the the size
of the list fixed?

[Nick Hebner]

Yes, the Project editor supports adding, removing, and editing ProjectEntries. Both adding and removing using model.entries.add() and model.entries.remove() cause the Project to be marked dirty since the list size changes. The tricky one is editing since the list size does not change, and the Project dirty flag does not incorporate the state of the ProjectEntries in the list. I have tried calling model.entries.setElements(model.entries.asUnmodifiableList()), but this doesn't work since the list items are still identical. I have also tried bind model.entries to a custom HasValue, but this doesn't seem to work either. I am not sure what else to try.

Thanks,

Nick

[Andrew]

Are you using something like the following:

BeanModelProvider<Project> projectProvider = ...;
ListModel entries = projectProvider.getListModel("entries");

and then using `projectProvider.dirty()` for your dirty model?

On Aug 11, 10:33 am, Nick Hebner <hebn...@gmail.com> wrote:
> Yes, the Project editor supports adding, removing, and editing
> ProjectEntries. Both adding and removing using model.entries.add() and
> model.entries.remove() cause the Project to be marked dirty since the list
> size changes. The tricky one is editing since the list size does not change,
> and the Project dirty flag does not incorporate the state of the
> ProjectEntries in the list. I have tried calling
> model.entries.setElements(model.entries.asUnmodifiableList()), but this
> doesn't work since the list items are still identical. I have also tried
> bind model.entries to a custom HasValue, but this doesn't seem to work
> either. I am not sure what else to try.
>
> Thanks,
>
> Nick
>

[Andrew]

Actually, I don't think I need to know the answer to the previous.
I'm not sure exactly how your implementing your editors but I tend to
use nested controllers and then delegate the responsibility for
tracking dirty to them (they typically use an internal
BeanModelProvider as required).

* I'd give my ProjectEntryEditor a `ValueModel<Boolean> dirty()`
method (that most likely delegates to an internal
BeanModelProvider<ProjectEntry> dirty model).
* I'd have a ProjectEntriesEditor (or controller depending on what
you're calling things) that also has a `dirty()` model. Internallly
I'd use a ReductingValueModel for this that uses an Or function build
from the list of `projectEntryEditor.dirty()`. i.e. when ever an
editor is added or removed it's `dirty()` model is added/removed from
the ReducingValueModel.
* From here I'd the dirty would be an Or of your existing dirty and
the projectEntriesEditor.dirty().

There's definitely scope for improvement with pectin here, and I'm in
the process of thinking about a standard set controllers for this kind
of thing (there's a very brief blurb about this in the future
directions wiki page). I've also started pondering a Bindgen style
approach to generating models from beans which may prove to be more
flexible and allow type safe graphs with automatic nested dirty
tracking... but that's a fair way off unless someone want's to have a
crack at it themselves.

In the end though the controller approach is a lot more flexible since
it lets you layer additional functionality (like validation etc) as
your project requires instead of having BeanModelProvider do
everything for everybody.

Cheers
Andrew

[Nick Hebner]

Thanks, that helps. I was sort of thinking that it would take something like that, but I wasn't sure how the value model delegation and reduction work. I will read up on that and try it out.

Thanks for the help and the great library!

Nick

[Andrew]

On Aug 11, 11:57 am, Nick Hebner <hebn...@gmail.com> wrote:
> Thanks, that helps. I was sort of thinking that it would take something like
> that, but I wasn't sure how the value model delegation and reduction work. I
> will read up on that and try it out.

Yeah, it's really something I need to at least address on the wiki
until I've got some standard controllers in place (I've answered this
style of question a couple of times). I've been thinking alot about
editing deeply nested structures and I can't see how it can be done
(in an extensible/flexible manner) without a nested controller
approach. It's just a matter of figuring out the mechanics to combine
convenience with flexibility.

> Thanks for the help and the great library!

No worries (c:

Cheers