Am 17.08.2015 um 11:29 schrieb Iwan Vosloo <iwan@reahl.org>:

On 05/08/2015 14:35, Iwan Vosloo wrote:
On 05/08/2015 13:13, Stephan Eggermont wrote:

Op 5 aug. 2015 om 11:42 heeft Iwan Vosloo <iwan@reahl.org> het volgende geschreven:

But it seems that visible: can only take a Boolean, which the description then retains for the lifetime of the description.
Normally the evaluation happens at component creation time. You can however use a builder that evaluates at other points in time. The component has a reference to the description so everything you need is there. You just need a smarter builder and/or component

I have looked at this a bit more... but still have no clue as to how to do this. I get lost somewhere between MAPRagmaBuilder and the fact that a MAContainerComponent creates its children components when it get initialised - all on top of a set of related Descriptions that can never be replaced by others.

I'm not sure replacement of the child descriptions is the right way to take it. You are building a form at a specific point in time. The view you will see an the screen reflects that. The relationship between uncommitted data in your form and the change in the structure of the view is not obvious. If you want to have the UI reflect a behaviour in visibility the best way might be to recognize the change in that boolean and to recreate/replace the view with a new one. This way you could track the side effects of changing a single value as well. If you want to keep uncommited data there might be a possibility to recreate the view but make it use the current memento. Without dedicated and specified use case it is hard to tell if there is a good way to do it or if there are shortcomings in magritte.

Wouldn't it be simpler to just change visible: to be able to take a block similar to addCondition: and always evaluate that block when isVisible is called (for example)? This can be done consistently for a bunch of other things too, like isReadonly, isRequired etc.

If you take your single use case it might seem feasible. But what if have components that are hidden if another one is visible and vice versa. The interdependencies can be really complex. From this point of view recreating the whole thing (as described above) might be the best way to do.