Is this a bug?

[David Bovill]

On 20/01/07, Chipp Walters <chipp at chipp.com> 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.