Yeah, that’s the problem. It seems like changesets were built (or at least tested) with a singular “one changeset per destination” mindset, or possibly a “data has one source and one destination” mindset, rather than a plural “one changeset per source” mindset. This is proving simplistic if you’ve got data that can come from different places with error lists that have to be handled separately.
I was hoping I might get some clarification here from the authors whether this is, in fact, the case. Since the changeset lies between the model data and the GUI, I was wondering if there was anything in the Data-Down side, which is clearly operating in the changeset’s proxy, that could be used to update the error list as well.
If not that you could probably wire it up to revalidate when your model changes but then you’re using an observer-ish pattern so I see why that’s not ideal.
Or I could do something imperative from the action on one changeset to flash other active changesets to revalidate when it successfully performs a save, except that I can’t see a way to imperatively ask a changeset to “revalidate all data, not just the dirty fields”. Setting a field to the same value as the one it proxies doesn’t mark it as dirty, so it won’t even test it, and in this case, we are revalidating to clear errors that no longer apply, not to look for new errors.
So right now, I can’t see how to use changeset-per-source, even using the supplied changesets as primitives. It seems like I’m not provided sufficient mechanisms to do it. It’s frustrating 