[nebulastudio-discuss] XML descriptions of Nebula classes to provide better wrappers and editor integration

[Bruce Mitchener]

Leaf Garland wrote:
> On Thu, 13 May 2004, Bruce Mitchener wrote:
>>I'll need to consider (and likely just decide in the absence of
>>feedback) where these XML files should go within the source tree, but
>>expect to see this stuff start to land in CVS before Monday.  I may not
>>deel with begin/add/end type setters in my initial pass as I haven't any
>>great ideas yet on how to handle them.
> 
> At a guess in code/contrib/nwrapper

But they'll be useful to things other than nwrapper .. and then any 
contirbs, etc would have to place new files into nwrapper rather than 
being self-contained.

Perhaps a new directory, interfacedefs, or something:

   nebula2/code/nebula2/interfacedefs/kernel/nroot.xml
   nebula2/code/contrib/nmap/interfacedefs/nmapnode.xml

and so on?  And perhaps a better extension for hooking it up to an 
editor application one day ...

 > What else would go into CVS at this point? Where do you see the code
 > that converts xml files into editable properties going? In nwrapper?
 > Does nwrapper become something that will be needed at run time too.

That wasn't my plan.  I don't want to see nwrapper at runtime. :)

 > So NebulaStudio would say property foo = 12 and nwrapper handles the
 > actual dispatching of script cmds to do that?

I think Nebula Studio would be able to load the XML files (which would 
mean distributing them along with the org.nebuladevice.engine plugin) 
and load/parse that data to find out what methods and so on were 
involved.  From there, it could use reflection to invoke the correct 
methods.  So, if there were an editor for a property foo being used and 
the value changed, then Nebula Studio would use reflection to call the 
setFoo method on the corresponding Java object, which would do whatever 
the generated code did. (Right now, it does the script command dispatch 
to talk to the core C++ code.)

  - Bruce