[Fipa-os-contribution] Data binding submission (and tiny Win98 change)

[Robert K. <kr...@ne...>]

I've enclosed a .zip of a sparse source tree containing those files that
I've modified to support the data binding strategy I mentioned in
yesterday's developers list (which I've enclosed for reference at the end of
this message). The veneer that I've added is fairly thin, but there have
been some changes to some existing classes as well, most notably
ScriptEditor and FIPAOSConfigurator. Though I've not written a unit test for
this new layer (nor ran regression tests as I'm unable to tell yet which
ones should succeed or fail), I'm fairly confident that this change has
little to no impact on existing features. But it does open the door for a
language-independent data binding layer in FIPA-OS.

This .zip also includes a modified version of the SetupFIPAOS.bat script
that work correctly on Windows 98, along with the STRINGS.COM DOS command
needed to support the change to SetupFIPAOS.bat.

I should probably also note that this first submission of the data mapping
classes doesn't include any schema document support. I was able to get away
with this on the XML side because reading in profiles is a very easy
process. The ScriptDataMapper class is an implementation that will only
really support the SetupFIPAOS script and nothing more. I could have put
schema support in for this class, but it would have been a total waste of
time as SetupFIPAOS is about to disappear anyway. So I just put in enough
support to handle the single use case that we have.

Oh, the starting point for these changes was the tree extracted from
SourceForge using the FIPAOS_OS2_1_0 tag.

Comments and suggestions are of course welcome.

Bob

--------------------------------


on 7/24/01 1:32 PM, Bob Krause at neo...@ne... wrote:

> Chris,
> 
> I see your name in the Enhydra mailing list archives talking about data
> binding. Are you actively working on data binding for FIPA-OS? I ask because
> I'm sure you've seen the discussion Alan and I have begun on the subject. My
> read is that he's saying you guys are still uncertain as to how to tackle data
> binding. Witness...
> 
>>> I have another question about your thoughts on data-binding. Are you looking
>>> are JAXB for XML data-binding? If you looking for format-independence, are
>>> you looking to insert an abstraction layer on top of JAXB? If so, what would
>>> the SL0, ACL and RDF implementations of this layer be built upon?
>>> 
>> The jury is still out ;)  Any suggestions are welcome (although I suggest we
>> break this off into another thread......)
> 
> But with people busy in Sendai and me not there, I've spent the last couple of
> days testing a design that I believe addresses the data binding functional
> requirements that I'm aware of. I've plugged it into by 2.1 tree with hardly a
> hiccup, though it currently just handles profiles and that SetupFIPAOS script
> that's going away soon (I hope). The approach is as follows...
> 
> (BTW, I'm still fighting with the TogetherSoft support crew trying to get
> their Control Center up on my machine. So I don't have any UML diagrams to
> show you as yet. Sorry.)
> 
> Firstly, I agree with everything Brett said in his series of articles on data
> binding last fall. So for XML support I use the data binding library based on
> his work that I was asking about the source of yesterday. The data binding
> library is used via the XMLDataBinding class that I believe you wrote.
> (Right?) All I've done is add another layer between XMLDataBinding  and the
> application that I believe is necessary to make data binding work in a
> format-independent manner. I call this layer 'data mapping'. I could see XML
> support for the abstraction layer I've added eventually folding into the work
> you're doing, but in order to preserve the existing API, I've just added a
> separate layer for now.
> 
> Right now there are only four classes. An abbreviated version of their public
> interface is as follows...
> 
> public class DataMapperFactory
> {
> public static interface Creator
> {
> public DataMapper createIfSupported(
> String data_url, String schema_url);
> }
> 
> public static void register(DataMapperFactory.Creator creator);
> public static DataMapper createDataMapperByURL(
> String data_url, String schema_url);
> public static DataMapper createDataMapperByFile(
> String data_file, String schema_url);
> }
> 
> public interface DataMapper
> {
> public String marshall(Object object) throws IOException;
> public marshallToUrl(Object object) throws IOException;
> public Object unmarshall() throws Exception;
> }
> 
> public class XMLDataMapper implements DataMapper
> {
> public XMLDataMapper(String data_url, String schema_url);
> public String marshall(Object object) throws IOException;
> public marshallToUrl(Object object) throws IOException;
> public Object unmarshall() throws Exception;
> }
> 
> public class ScriptDataMapper implements DataMapper
> {
> public ScriptDataMapper(String data_url, String schema_url);
> public String marshall(Object object) throws IOException;
> public marshallToUrl(Object object) throws IOException;
> public Object unmarshall() throws Exception;
> }
> 
> As you can see, DataMapper is an abstract interface currently with two
> subclasses that support XML and script data mapping. The XML support delegates
> the heavy lifting to XMLDataBinding. The ScriptDataMapper does some lifting,
> but leans heavily on ScriptEditor. Each of these subclasses registers a
> creator function with DataMapperFactory. Application code simply passes either
> a file or URL string and an optional schema to the factory to obtain a data
> mapper of the proper type, then uses the DataMapper interface to marshall and
> unmarshall objects.
> 
> Reading and writing profiles and setup scripts is relatively easy business as
> there isn't even a schema involved. I also want to add some functions to the
> factory class to bind application-specific classes to class names referred to
> in the schema or instance documents. But the functions I've shown here should
> survive those additions without change. Further, I believe we could use the
> DataMapper interface as a front-end to the various language parsers to allow
> objects to be marshalled and unmarshalled in a language-independent fashion.
> 
> I've got a tree that implements this approach. I've also modified the rest of
> my tree so that all code that used to use XMLDataBinding and/or ScriptEditor
> directly now uses this. I'm going to bundle it up and mail it to the
> contributions list tomorrow. Whether it's to be folded in to the main tree
> will probably involve further discussion.
> 
> 
> Now, getting back to the original question... The reason I was asking for
> source to the data binding code is that Zeus isn't ready yet and fipaos is
> using the databinding library today. I wanted to explore the issues for
> supporting application-specific classes before moving to Zeus. Once this is in
> I would look at adding other DataMapper subclasses (ACL, SL0, RDF, ...).
> 
> The bottom line is that, yes, I'm still interested in looking at the data
> binding source if you don't mind.
> 
> Bob
> ----------
> Bob Krause
> NeoLogic Systems, Inc.

----------
Bob Krause
NeoLogic Systems, Inc.