2008/8/31 Ken Ray <kray@...>

> Thanks for posting this, David... it's a good topic for this group.
>
> > *Background*
> > I put a lot of effort into abstracting out code into generic libraries,
> and
> > there is always a battle between making the code simple and generic, and
> > making it flexible enough to all the uses it could be put to. What tends
> to
> > happen is that the handlers steadily sprout parameters, and what started
> > simple ends up requiring a big manual to get your head around.
> >
> > I separate my code now into a semi-strict structure with the visual code
> in
> > the controls - libraries in used stacks, and the program logic on the
> card
> > script.
>
> Can you clarify what you mean by this? When you say "the visual code in the
> controls", what do you consider "visual code"?


Any code that relates to the visual appearance of the view displaying data
or interacting with the user. Typically code relating to things like
geometry, or colours or other visual styles. This is contrasted with code
that fetches or manipulates the actual data, or code involved in the logic
of the particular application. So yes - I keep this visual code separate -
either in the "views" themselves (usually groups taken from a library), or
abstracted into a library that multiple views can share.

separating your code, you're talking about separating it for a full project,
> and not just for libraries, right? (Just trying to be clear.)


Yes - in particular I am finding the separation of visual code from the
program logic helpful. Not just used stacks or front / back scripts - but
more interestingly I have started to put all program logic in the card
script (sometimes stack script) - but never in the card based groups or
controls. The acid test here is always can I replace a control on the card
with an updated version, or a different style of control and everything
still keep working. Early on I experimented with having custom scripts
sections that would be saved and restored when the view is updated /
replaced - but now I find I nearly always can do what I want and keep the
code on the card script.

So if I'm understanding you properly, the reason why this:
>
> put the graph_NodeColour [nodeID] of the target into someColour
>
> is preferable to this:
>
> put the uOPN["NodeColour"] of the target into someColour
>
> is because the end user can intercept the getProp to run custom code if
> they
> wanted to do something other than just set the one `uOPN["NodeColour"]` of
> the target?
>
> If so, then why couldn't the end user simply intercept the getProp on the
> `uOPN["NodeColour"]` instead of intercepting the getProp of
> `graph_NodeColour[nodeID]` ?


Not really. The main point of the post was the use of custom property calls
from the library down to the visual controls as a form of end user
customisation. The choice of doing this with explicitly wrapped handlers is
not important. I do this for readability - I find that if I don;t use
getprop / setprop handlers I cannot tell by looking at the code - I miss
part of the program logic visually. I prefer to be able to see this by
looking at the organisation of the handler in the handler list. I use uOPN
to indicate that this is an actual custom property and to ensure
compatability in cases where there may be other people code mixed in.

>
> >> end graph_NodeRect
>
> I'm assuming the custom props above should be `uOPN["NodeShape"]` and
> `uOPN["NodeRect"]` instead of `uOPN["NodeColour"]`, right? (I'm assuming
> it's just a copy-and-paste error... something I do all the time ;-)


Yes sorry - just a typo.

Well, here's my two cents... and keep in mind that I may very well be
> reacting from an engrained development approach... but it *seems* to me to
> be a bit more abstracted than it needs to be (IMHO). I like the idea of
> custom property-trapping in order to allow the end-user/developer to add
> custom behaviors,


Thats the main point really.


> but I guess I'm struggling with the additional
> abstraction.


I did not mean to emphasise that.

Here's an example: I have a library called "libSTSControls" that manages
> custom controls (like a splitter object or a search box), that exist as
> groups on the card of the main stack of the library. When a new "splitter"
> is needed, I have a handler that can be called which will create a copy of
> that splitter control on the current card:
>
> stsControls_Create "splitter"


Similar. I have a database of views. Each view is in its own stack, and
stored together in a folder. They are named so that they are structured
hiearchicly - so the are Title Views ("View|Title|Simple" or
"View|Title|Icon"), there are layout views, form views, teree views, image
views, etc. Then I have a generic library to insert, delete, and update the
views. So in your example above I would.

set the view_Insert of group "layout" of card 2 to "View|Simple|Tree"

Which in turn generates an "stsControls_NewControl" message with params
> about the type of object being created, and if it is not trapped by any
> user's code, it hits the "backstop" in the library:
>
> on stsControls_newControl
> end stsControls_newControl


I think that the same - I use a front script which checks the uRIPs and if
its a view - stores or updates info in the database. The front script is
passed and does not affect the ability to trap the messages locally.

Each custom control (group) has a uRIP["type"] that corresponds to the type
> of control (like "STSSplitter") so that if I have any code that needs to
> see
> how many splitters are on a card, say, it can quickly iterate through the
> groups on the card and check the uRIP["type"] of each group.


I use uRIP["type"] for "library" or "view" or "menu" - its underused really
and I use the uRIP["name"] for a full path like "View|Title|Simple". Maybe I
should use "type" for that.

The getprop/setprop for this property lives in the library, not in the group
> itself - in fact, I prefer to keep my custom controls codeless so they are
> only a group of objects and custom properties to control them.


Yes. I also have stopped storing data in the views that may change. I use
the card script now as a default. I do however put the logic for things like
geometry inside the view (group). I like to be able to go into the code and
tweak it, and I don't like the Rev based way of using libraries and custom
properties - again I like the readability of the code. So I leave code in
the view that has to do with visual presentation and is relatively stable.

The code in the library always refers to "the target",


Again I use custom properties for how you refer to things - so instead of:

put the text of the target

you'd either have

put the tree_Text of the target

, or

put the text of the tree_Field of the target.


[Non-text portions of this message have been removed]