On 05/08/2015 10:38, Norbert Hartl wrote: Thanks, Norbert. I get that, but when you do, for example: aComponent := anObject asComponent. then aComponent holds onto the description created above (in asComponent's implementation), as I understand it. This means that as long as aComponent exists, it will always refer to the same description. Is that understanding correct? Thanks - Iwan -- Reahl, the Python only web framework: http://www.reahl.org

On 05/08/2015 11:14, Norbert Hartl wrote: Thanks Norbert, I have to ask stupid questions because I realise I am sometimes struggling for lack of understanding some fundamental concepts. I think I understand how some of the data displayed by a component can change during the lifetime of the component. For example, a MAElementDescriptionComponent>>value will just use the accessor set on the description, so that is quite dynamic. But what I am struggling with is things like setting visibility of a description. For example I could have the following on the instance side of my object: descriptionNumber ^ MANumberDescription new selectorAccessor: #number; visible: self mayBeSeen; yourself ... with the assumption that mayBeSeen is a method on my object that might return a different result during the lifetime of aComponent in my example above. But it seems that visible: can only take a Boolean, which the description then retains for the lifetime of the description. The description in turn lives as long as the MAContainerComponent stays alive. So, I don't really understand how one can change the contents of the MAContainerComponent based on something like visible: on the description. (I thought magritteDynamicObject could help here, but magritteDynamicObject is deprecated in Magritte3.) Regards - Iwan -- Reahl, the Python only web framework: http://www.reahl.org

Verstuurd vanaf mijn iPhone 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 Stephan

On 05/08/2015 13:13, Stephan Eggermont wrote: Hi Stephan, That sounds promising. Where can I read more about this? What is the builder for, is it for the description or for the component? Regards - Iwan -- Reahl, the Python only web framework: http://www.reahl.org

Iwan Vosloo wrote You've hit a limitation of Magritte - forms are fairly static. A "view" is pretty much just a read-only form. Even when you edit the object, you're usually editing a cached Memento, not the object itself. I've sometimes thought about an MAUpdatingMemento, but unless the object is designed for this (e.g. sends announcements) you'd have to use polling. Anyway, the upshot is that #visible: doesn't take a block because Magritte's design freezes forms in time. If you want to do things a different way, it will take more than a block (which would still only be evaluated once), but a rethinking of the infrastructure. Of course, this being Smalltalk, why not! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Understanding-dynamic-descriptions-tp4840991p4843449.… Sent from the Magritte, Pier and Related Tools mailing list archive at Nabble.com.

On 17/08/2015 13:20, Sean P. DeNigris wrote: On 17/08/2015 13:46, Norbert Hartl wrote: Thanks. That is an important thing for me to understand. Coming from other technologies the single thing that stands out the most about Seaside is that components are stateful, and stick around for multiple requests. From what you are saying Magritte goes a bit against that notion, and that for the use case I presented "the magritte way" is to recreate the component tree instead of keeping it around. I was actually not referring to uncommitted data. I am thinking of a scenario where you are on one page, click on a button which executes a callback in which everything validates properly, and the mementos are committed before also effecting some changes in the domain. But, the user stays on the same page (and thus also component) after having clicked on this button. So, the same component is displayed again - but some of its elements that were previously not visible now also appear. I actually really thought this is something many people would need to build on their user interfaces. I'd like to explore how possible this is... We already have modifications of Magritte where we pass in a block that is evaluated each time isVisible is called. What else would need to change? What I know is that MAContainerComponent creates its children components upon construction and it only creates the visible ones. I suppose one would need to be able to refresh it somehow after a callback so that it can update its children to include new ones that have become visible. Or perhaps it should create all child components initially regardless of whether they are visible or not - and only selectively render them based on visibility. Similarly validation should probably only be propagated to visible children. This assumes that the child MADescriptions of the MAContainer on which the MAContainerComponent is based do not ALSO change as a result of the changed domain, which is not a bad assumption in my view. Am I naive to think that it is not really much more complicated than that? I'd happily improve the specification of my little use case if you can point out where I am vague? I will also happily post experimental code people can play with. We are grateful if anyone wants to participate/guide! Regards - Iwan -- Reahl, the Python only web framework: http://www.reahl.org