Delegating views

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Delegating views

Luke Gorrie
Hoi,

What is the best way for an object to delegate one or more GTInspector views to other objects?

I have been using a pattern like this:

gtInspectorFooIn: composite
   <gtInspectorPresentationOrder: 5>
   otherObject gtInspectorFooIn: composite

but I am wondering whether there is a better way, and also whether this method is valid (I've occasionally seen odd behavior, like Inspector panes disappearing after I "Refresh", and I wonder if I could be somehow confusing the model or if this is not relevant.)

also: Supposing this pattern is valid, is there an easy way to override the title of the view(s) added by otherObject?

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Delegating views

Andrei Chis
Hi,

On Mon, Aug 7, 2017 at 9:44 AM, Luke Gorrie <[hidden email]> wrote:
Hoi,

What is the best way for an object to delegate one or more GTInspector views to other objects?

I have been using a pattern like this:

gtInspectorFooIn: composite
   <gtInspectorPresentationOrder: 5>
   otherObject gtInspectorFooIn: composite

This is indeed the normal way of delegating the construction of a view to another object. Just if otherObject can be nil it might be better to use an accessor that ensures the object is present. If that's not an option then either add a nil check or use a dynamic presentation.
 

but I am wondering whether there is a better way, and also whether this method is valid (I've occasionally seen odd behavior, like Inspector panes disappearing after I "Refresh", and I wonder if I could be somehow confusing the model or if this is not relevant.)

Should not be relevant. But there can always be a bug. If you find a reproducible case that would help. Also when reusing presentations like above it's better to define the #display block like this 'display: [ self computeValuesToDisplay ] ' instead of 'display: [ :each | each computeValuesToDisplay ]'.
 

also: Supposing this pattern is valid, is there an easy way to override the title of the view(s) added by otherObject?

If you return the actual presentation then you can customize any property of that presentation:

gtInspectorFooIn: composite
   <gtInspectorPresentationOrder: 5>
   
   ^ (otherObject gtInspectorFooIn: composite)
     title: 'Another title'

 
Cheers,
Andrei



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Delegating views

Luke Gorrie
On 7 August 2017 at 11:02, Andrei Chis <[hidden email]> wrote:
Hi,

On Mon, Aug 7, 2017 at 9:44 AM, Luke Gorrie <[hidden email]> wrote:
Hoi,

What is the best way for an object to delegate one or more GTInspector views to other objects?

I have been using a pattern like this:

gtInspectorFooIn: composite
   <gtInspectorPresentationOrder: 5>
   otherObject gtInspectorFooIn: composite

This is indeed the normal way of delegating the construction of a view to another object. Just if otherObject can be nil it might be better to use an accessor that ensures the object is present. If that's not an option then either add a nil check or use a dynamic presentation.

Here is the part that I am missing: How do I tell the Inspector that the *value* to inspect is otherObject instead of self?

I mean, it seems like this code constructs the GLMPresentation for otherObject but then applies it to self, which may not be compatible.

Maybe I should add 'display: [ otherObject ]' ?



but I am wondering whether there is a better way, and also whether this method is valid (I've occasionally seen odd behavior, like Inspector panes disappearing after I "Refresh", and I wonder if I could be somehow confusing the model or if this is not relevant.)

Should not be relevant. But there can always be a bug. If you find a reproducible case that would help.

I have not finally tracked down this issue yet but it seems to be related to error cases e.g. pressing "Abandon" in the debugger. Symptom is that the first pane of the inspector mysteriously disappears. I will open an issue when I know how to reproduce it.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Delegating views

Tudor Girba-2
Hi,

The way you make presentations reusable in other contexts id by making gtInspectorFooIn: display self. Something like this

SomeOtherClass>>#gtInspectorFooIn: ccomposite
<gtInspectorPresentationOrder: 5>
composite text display: [ :ignoredObject | self … ] …

So, the display block depends on self and not on the object you get in the block.

Like this, when you do:

SomeClass>>gtInspectorFooIn: composite
   <gtInspectorPresentationOrder: 5>
   otherObject gtInspectorFooIn: composite

You will actually apply the inner presentation on otherObject (instance of SomeOtherClass), rather than on the current object (instance of SomeClass).

Does it make sense?

Cheers,
Doru


On Sep 8, 2017, at 11:02 AM, Luke Gorrie <[hidden email]> wrote:

On 7 August 2017 at 11:02, Andrei Chis <[hidden email]> wrote:
Hi,

On Mon, Aug 7, 2017 at 9:44 AM, Luke Gorrie <[hidden email]> wrote:
Hoi,

What is the best way for an object to delegate one or more GTInspector views to other objects?

I have been using a pattern like this:

gtInspectorFooIn: composite
   <gtInspectorPresentationOrder: 5>
   otherObject gtInspectorFooIn: composite

This is indeed the normal way of delegating the construction of a view to another object. Just if otherObject can be nil it might be better to use an accessor that ensures the object is present. If that's not an option then either add a nil check or use a dynamic presentation.

Here is the part that I am missing: How do I tell the Inspector that the *value* to inspect is otherObject instead of self?

I mean, it seems like this code constructs the GLMPresentation for otherObject but then applies it to self, which may not be compatible.

Maybe I should add 'display: [ otherObject ]' ?



but I am wondering whether there is a better way, and also whether this method is valid (I've occasionally seen odd behavior, like Inspector panes disappearing after I "Refresh", and I wonder if I could be somehow confusing the model or if this is not relevant.)

Should not be relevant. But there can always be a bug. If you find a reproducible case that would help.

I have not finally tracked down this issue yet but it seems to be related to error cases e.g. pressing "Abandon" in the debugger. Symptom is that the first pane of the inspector mysteriously disappears. I will open an issue when I know how to reproduce it.


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"Value is always contextual."





_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev