Andrzej said:
>I think this wiring should be specified by an
>XML config file. Which in turn could be generated
>by a graphical tool for those that are so inclined.
>[...]
>So long as the GUI tool creates the underlying
>Embedlet XML config file that can be then pumped
>through the Embedlet configurator/builder.
>[...]
>> I do not see why we can not provide both mechanisms
>>especially since they seem to be complementary.
>
>There is no reason we can't do both....
Ok, as long as the specification allows for both, I am satisfied.
Andrzej said:
>The embedlets XML file will likely be just a config
>file that specifies the context for the embedlet
>component, and it's linkages (which events it
>consumes/produces, what JAPL device it talks to and the like)
>
>The graphical tool could just as easily set the
>property values in the XML Config file rather than
>using bean-based introspection and the like.
and James said:
>If we left this part to the bean persistance model
>it would become transparent and I think we would loose
>many benefits of the formalness of the underlying XML document.
I think that there might be some misconceptions on how the wiring tool/ Long
Term Persistence API combination works and perhaps this has caused us
unnecessary difficulties.
The long term persistence API is completely XML based. The XML files generated
by it simply contain all of an object's instance variable values including any
references an object has to other objects. All referenced objects are also
included in the file.
After the XML file is generated it can be freely manipulated either with a
standard text editor or with any XML tool. If one wants to manually change the
value of an instance variable then just edit its value in the appropriate tag
and it is changed.
If one wants to build a Java application by assembling XML tags from scratch
then this is perfectly acceptable too.
One way of looking at the wiring tool is that it just provides a way for
non-Java-programmers to graphically build the XML description of an application
without needing to know either Java or XML.
Another critical aspect that the wiring tool has is that the developer is
working with *live* objects, not just creating dead XML code. If one wants to
hook a LightController Embedlet to a light, as soon as the LightController is
dropped into the wiring area it is instantiated. As soon as it is wired to the
Light peripheral the developer can turn the light on and off by sending the
appropriate events into the LightController.
The whole application can be configured and assembled in this instant feedback
way and when it is done, everything is saved into a standard XML file. The
technique of editing an XML configuration file (by whatever method) looses some
of the instant feedback, intuitive-feel dimension that the wiring tool can
provide.
This is why I am pleased that people think there is room for both techniques in
the specification.
Ted
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
|