[nebulastudio-discuss] XML descriptions of Nebula classes to
provide better wrappers and editor integration
bruce at cubik.org
Thu May 13 09:22:35 PDT 2004
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
Perhaps a new directory, interfacedefs, or something:
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.)
More information about the nebulastudio-discuss