FYI
> This seems to work quite well. If I then override - aspectValue: on
> Presenter and get it to instantiate one of these instead of an
> ValueAspectAdaptor then your cluster code needs no changes at all.
>
> e.g. in the above it would be: rangeModel := pb aspectValue:
> #rangeUpper.
>
> Not sure of this last addition - but it seems to me that asking for
> aspects of a presentor is not something you would do, and in fact you
> probably wanted to get hold of an attirbute of the presenters view?
> Its a bit slimy but maybe a useful way of doing this?
This is a bad idea - as the CodeMentor actually watches aspects of presenters,
so doing this prevents you from opening new browser windows... ooops.
My workaround for the moment is to ask a presenter for a ViewHolder - which
has a level of indirection to the view by holding onto the presenter. The
viewHolder also overrides #aspectValue: and answers the ValueViewHolderAspectAdaptor
I mentioned earlier.
Thus the example above would be:
rangeModel := pb valueHolder aspectValue: #rangeUpper.
The real problem all of this is getting around is that Presenter are initialize
with a view that is a DeafObject - this is not ideal as you end up with an
object that cannot turn back into a real view if you ask too soon. In my
opinion you shouldn't have to know this, and there should really be a ViewPromise
so that if you ask before the view is ready you get a promise for the view
that will work when the view is finally ready.
Tim
Locked
