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. _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
