RE: [FR-devel] Updates to System_Command stuff

[Curt Hibbs]

Rich Kilmer wrote:
>
> Laurent (and Curt),
>
> I have completed study of the code to date on the FreeRIDE GUI and want
> to pursue a bit of refactoring.  My main goal is to preserve the
> functinality that's implemented, but restructure the way that the
> FreeBASE DataBus is used.  If there's one thing I think we need to use
> consistently is the DataBus.
>
> I will use the System_Command plugins as a working example.
>
> Right now for each command we store an instance of a GenericCommand
> object as the .data of the command's slot.  That object accepts a String
> as a constructor that encodes a bunch of stuff (menu, accelerator, hint
> text) seperated by \t (tabs) and pass a block/proc to call when the
> command is executed.  All of this data could be represented within the
> DataBus itself in slots like:
>
> cslot = bus['/system/ui/commands/FileNew']
> cslot.set_proc {|*params| ... }
> cslot['./Text'].data = '&New'
> cslot['./Accelerator'] = 'Ctl-N'
> cslot['./Description'] = 'Create new edit pane'
>
> This seems more complex, but it can be simplified by adding a manager
> that presents an API to create commands:
>
> cmgr = bus['/system/ui/commands'].manager
> cmgr.add("FileNew",
>          "&New",
>          "Ctl-N",
>          "Create new edit pane" ) {|*params| ...}
>
> and...
>
> cmgr.each_command {|slot| ...}
>
> and...
>
> cmgr.delete("FileNew")
>
> etc...
>
> I know this messes with the whole CommandManager structure but I have
> some thoughts there too...

I think this is the right approach. Just for the record, there are three
basic choices for storing structured data in a databus slot:

1) Store a real object -- this is what the current command implementation
does.

2) Use slot attributes -- this is fine if your data values don't have any
hierarchy.

3) Use child-slots -- this is your proposal.

#1 and #3 are functionally interchangeable, and you can add #2 to that
statement if you only have one level of hierarchy in the data to stored. So
the real question is what kind of guidelines should be used to decide on one
of the above representations -- not just in this case, but in general?

Here are some of my thoughts on this...

Using Child Slots -- One of the main thing you get out of this is that since
each piece of data resides in its own slot that is directly addressable via
its path. You can make, store, and pass around references to each piece of
data without, necessarily, having to know what kind of object it is apart
of. This makes it easy use this data in generic code. It makes it easy
(using the databus inspector) to look at it. It also makes the data
structure dynamically extensible by other pieces of code.

Storing a Real Object -- The main thing you get out of this is encapsulation
(data-hiding). The data can still be accessible via its containing object,
but you can only address and pass references to the object itself. Using
this approach makes sense when the data objects themselves needs to be
arranged in a named/addressable hierarchy because mixing the object's data
values in the same hierarchy would be confusing and problematic (although,
if the data values were flat, you could store the objects as the databus
subtree, and the data values as slot attributes). This also makes sense in
cases where the object needs to maintain strict control over its contained
data.

In general, I would say using child slots would be the preferred choice
unless there were specific reasons for needing to store real objects.

Curt