Just stepping back I have a question below. First let me say, please don't take offense if the question is too basic. I grapple all the time with the question of "is the model logic?", or "is it application specific logic?" -- Remember that Magritte descriptions help define default dialogs/editors for *one* imagined application using the object, but there is no way you will define one set of Magritte descriptions for all applications of instances of your class. [At least for highly reusable model components.] Even with "one" imagined solution, Magritte helps you put an interface on the object, but much of your interaction with the object may be through other code that does not stop to ask the MagritteDescription how to do something. So my first question is: Is this a presentation problem/question or a model integrity problem/issue? Why not define a method to get the #effectiveDate or whatever method. You said "to many" relationship, so which date should be displayed if there are 5 associated objects and they all have different dates? This sounds like some logic that belongs outside of the magritte description. - I quickly gave up trying to be "minimal" with Magritte descriptions. They are very handy and powerful. So I just clone them to create new ones that serve my needs... and move on. -Cam On Mon, Oct 7, 2013 at 4:20 PM, John McKeon <p3anoman(a)gmail.com> wrote:

Sean, Perhaps I am misunderstanding and solving a different problem.. but it sounds like... **if** all of these instances actually store the date... Seems to me the Parent instance #date methods should be accessed using simple method accessors of a Magritte Date description. The tricky part of model integrity should be logic of the instances of Parent and not dependent on the Magritte description -- with myriad good reasons to make exceptions. e.g. "I just need to meet the deadline or else i am fired!" The tricky part, can be solved by either having the parent always push data down (with direct wiring) or registering self as a dependent, or the children as dependents; or the other major option is that of having the children pull it on demand (e.g. ifNil: [ date := parent date]). - You probably want simple methods for your parent object that *push* the date to children. e.g. define something like... #updateChildrenStates self children do: [:child | child date: self date. ... ] Whether you use #changed/#update/dependency-management or announcements, or "direct wiring" with this approach is up to you. If using #changed you would do something like this (as well as register self as a dependent): Parent >>date: aDate date := aDate asDate. self changed: #date. and Parent >> #update: aSymbol self updateChildrenStates *if* the child is registered as a dependent but has no handle to the parent, implement: Parent >> update: aSymbol with: anObject aSymbol == #date ifTrue: [ self date: anObject date ]. - Or, if using "direct wiring" Parent >> date: aDate date := aDate asDate. self updateChildrenStates. "or more specifically self updateChildrenDates" -- If on the other hand, the children are pulling, then they need a handle on the parent to query lazily. Good luck! Cam On Tue, Oct 8, 2013 at 6:51 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote;wrote:

Hi Sean, I think I understand your problem. You need to create your custom ToManyComponent and override the "add" message. The basic implementation is: add self root show: (self validatedFormOn: self selected new) onAnswer: [ :result | result isNil ifFalse: [ self value: (self value copyWith: result); refresh ] ] The "self selected new" you want to change into something you want. Perhaps it would be nicer if this is replaced by a hook, having the default implementation of add: add self root show: (self validatedFormOn: self newInstance) onAnswer: [ :result | result isNil ifFalse: [ self value: (self value copyWith: result); refresh ] ] newInstance ^self selected new And then override the newInstance. But in all cases you need a custom ToManyComponent that makes sure it creates the correct instance. Cheers, Diego On Oct 9, 2013, at 2:04 PM, Sean P. DeNigris wrote: