Sounding out the View Tree (again)

http://objology.blogspot.com/2012/05/querytwo.html

--
Travis Griggs
Objologist
For every adage, there is an equal and contrary un-adage



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> http://objology.blogspot.com/2012/05/querytwo.html



"lightweight communication between view tree objects"

IMO, this entire approach is flawed. You are hard-wiring application behavior into individual widgets. This kind of coordination belongs into an application-owned composite class that keeps track of its components (using instance variables) that it needs to operate on directly (e.g. to recompose and invalidate itself).

This query thing further complicates the immense complexity of VisualWorks even more. I would rather look at simplification, rather than adding more and more subsystems.

Andre


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 5/30/2012 8:13 AM, Travis Griggs wrote:
> http://objology.blogspot.com/2012/05/querytwo.html


I dislike where this is going for several (admittedly touchy-feely) reasons:

-- I need to learn a new language for every query builder in VW it
seems, I miss the *ect: family of method names.
-- deficiencies in the View hierarchy are compensated for in query
classes, ergo the view hierarchy API does not mature..
-- there are two radically different traversals, but they are
shoe-horned into a single query object.
-- queries are first class but never stored or passed around


I'd rather be able to write such stuff using established vocabulary and
idioms:


self topWrapper withAllChildren
     select: #isAbstractComparisonRollupView
     do:[ :view | view hideTypes: hiddenTypes]

self children detect: [:view | view property: #id satisfies: [:id | id =
#foobar]]

self topWrapper withAllChildren
     reject: [:view | view property: #frame satisfies: [:rect | rect
area isZero]]
     do: #invalidate

self withAllParents do: #flash

self topWrapper withAllChildren
     select: [:view| view hasProperty: #updateGroup]
     do: #update


Hope this helps,

Reinout
-------

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Let me explain why I believe that subclassing composite views might be the simplest approach to the proposed problem. I agree the view tree has issues, but I doubt that a sophisticated tool to traverse it is a good answer.

I'd rather not be required to deal with the tree at all. Here's how that would work:

A special purpose composite (i.e. a visual that features complex behavior) can keep a reference to the components it needs to talk to directly, in instance variables. Each time it recomposes, these references are updated anyway, so why bother with searching the view tree?

I'm doing it this way with extremely complex UIs and it works great. My composites know how to compose themselves according to the current state of the model. During the composition, they keep a reference to individual components that need to be accessed programatically (not many, by the way, because most of the time when something changes, they simply recompose entirely).

Really, if you want to do things like "invalidate all borderless input fields left of the middle of their parent views", you have seriously messed with everything. This is a strong indication that you need to rethink your UI design.

Andre



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 5/30/2012 11:35 AM, Reinout Heeck wrote:
> self children detect: [:view | view property: #id satisfies: [:id | id =
> #foobar]]

I forgot the 'all' there:

self allChildren detect: ...



R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc