Virtual Custom Property Sample - Recursion Limit Problem

[David Bovill]

The aim is to release a re-useable component framework for Rev. A major part
of this tool framework are "views" - which are MVC style components designed
to replace or enhance the Rev Object Library.

Views can be arbitrarily nested - so if you are constructing a complex
layout you can take some "layout" views and drag and drop components onto
the areas of the layout. Robustness is important and the views must be able
to be replaceable with other views of the same type and continue to
function. I guess you get the picture.

One example of this is that most views can be resized to a rect you specify
using the public property "view_Rect". The arbitrary nesting is then
achieved by a top level view just kowing its own components and given its
own rect where to position a subview. In this way you get a nested series of
views each with there own "view_Rect" handler. A resizeStack event triggers
the top-evel view to resize its contents using the "view_Rect" properties -
all the way down the chain.

There is no way in advance of knowing how many levels of nesting there will
be - a simple view with a "title bar" may end up with a highly specialised
"title bar" comprising of 3 or 4 sub-views. In this way a "View" author only
needs to care about and test that his view does what it is supposed to. Good
examples of applications of this are for arbitrary forms (think xforms) and
modern MVC frameworks like ROR or better Django which can create user
interfaces directly from the DB structure. The aim of doing this in Rev is
to allow fully customizable interfaces using all the flexibility of the
RunRev environment and IDE.

I do not think there is any technique which will allow you to do this other
than using a recursive type walk down the views. The views themselves need
to calculate the sizes of their subviews given their own (new) rect and
their own internal logic. Fixed properties wil not do, and whether you use a
send or getprop/setprop handlers you have a danger of recursion which could
easily be prevented using lock messages if only they worked properly with
get/setprop handlers.