Hello all:
There is an inconsistency in thinlet that is sometimes
aggravating: While thinlet allows me to create a UI with
strings (in XML), to make UI changes at runtime, I am forced to
use thinlet's non-string API. Since it's so wonderful to create
components via strings/XML, why not expose that interface to the
programmer?
For example: to set an integer in XML:
<progressbar name=pb value=0>
but in the thinlet API:
setInteger(find("pb"), "value", Integer.parseInt("50"));
Most of the time, this native type interface is adequate and
sometimes even preferred, but there have been times when I
wanted to also use a string-based API at runtime.
It would be nice to have a complementary API that operates at
the string level:
set(find("pb"), "value", "50");
set(find("hi"), "icon", "icons/thisicon.png");
The code to support this has to already be in the XML parser of
thinlet. It would be nice if there was an external interface for
programmers to use it.
Can xml2swing have this additional level of interface?
It might be nice also to extend this idea to allow easier
creation of dialogs and components at runtime instead of using
thinlet's clumsy create() and parse() methods. You can define
the whole XUL in a string and perhaps set parameters within that
string (idea borrowed from JDBC PreparedStatement):
// trivial example
XML2SwingString newDialog = new XML2SwingString(
"<dialog name=hi>
<label text='please enter a ?'/>
<textfield name=entry columns=?/>
</dialog>");
// now set the two parameters
newDialog.set(1, "number");
newDialog.set(2, "10");
// this will create the whole thing, just like it was
// loaded with parse()
add(create(newDialog));
Again, this is just an extension to the XML parser that already
exists in the core. The question is: is it a good idea to expose
the XML (or string) parsing of the core to the programmer?
john
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
