RE: [FR-devel] Updates to System_Command stuff

[Rich Kilmer]

OK...since you guys like the general approach, I will work through the
implications.  Again, I want to maintain the functionality while making
these structural changes.  I would prefer a single chunk at a time (and
then check-in) but it *may* require a global sweep.  Regardless, I will
be doing most of this work tonight (9/16) and tomorrow (9/17) starting
10pm EST.

Regards,

Rich

> -----Original Message-----
> From: address@hidden 
> [mailto:address@hidden On 
> Behalf Of Curt Hibbs
> Sent: Monday, September 16, 2002 10:31 AM
> To: address@hidden
> Subject: RE: [FR-devel] Updates to System_Command stuff
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> Freeride-devel mailing list address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/freeride-devel
> 
>