On 20/01/07, Chipp Walters <[EMAIL PROTECTED]> wrote:
And Dave has demonstrated EXACTLY my problem with this. The simple fact is, I am creating grouped widgets, which I have differently named components within, which I would like to be able to address.
I have gone through using names (the problem you have now) - then ids (don"t work when you copy the object to another stack = new id, - id indexes automatically updated - a pain - and at the moment I use long ids and getprop handlers - which seems to be working OK. I am not quite sure hw to use simple names at the moment - my inclination is to leave this up to the user and allow them to rename them as they see fit to make it easy for them to use the components in a natural way - the trick is then to have a "meta" way to refer to the "views" and their classes. Mark, your example also demonstrates the power of same named instances of
object. I guess it all boils down to each of us trying our best to create reusable grouped components, each with the same codebase. A most difficult task.
I have a library of components I call views and a way of automatically keeping an index of all instances of the views so that they can then be all updated . I use newgroup and deletegroup messages and search down througn the groups for nested compnents. For instance, take altFldHeader which creates column headers for fields.
( go URL "http://www.gadgetplugins.com/altplugins/altFldHeader.rev"; ) While it's been stable now for years, modifying old altFldHeaders still is a problem as each instance has all of the code embedded in the group. The same is true for many of my so called 'objects.' A benefit of this approach is it's easy to do exception programming and track code as well with everything being neatly packaged in a group. A big drawback is when you want to modify the codebase, you have to replace each group, especially if you end up adding a new control.
If you are looking at this Chipp - I'd appreciate some feedback on the way I am doing it _ I've got a copy of altFldHeader as a view that I made a while back now as a test on principle. Separating the 'object' into a GUI library group and a background library
has it's own set of problems as well. You need to carefully track what libraries are still being used. For instanec, they have to be inited from a startup handler, so now you have at the minimum 3 different places for custom object 'pieces': the library stack script, the GUI control group, and a piece of init code in startup.
At the moment "views" (the GUI control group) can use libraries - and therefore have a dependency property for this. I think the only way is to have a global database of keeping track of the connections such as these and using system events to ensure they are kept up to date. That is a "model" of these connections kept in memory.
You also need to be very careful using 'the target' and if you have other system handlers, you'll need to make sure they don't interfere, as they're called ALL THE TIME, instead of only when needed. I'm not crazy about this approach, unless you're coding something like libURL
A naming convention like uRIP is the only way to go here at the moment for libraries - I use over 20 libraries at the moment and have renamed all the handlers (nearly) to fit the naming convention. I am intrigued at the moment by how useful naming conventions are - as they also allow scripts to auto-magically use the names to refer to other properties - I picked this up from the MVC frameworks like RubyOnRails. For instance in you have a property like "view_Colour" a script can automatically look for a property called "view_Colours" to draw a menu or check for a legal value. _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
