| Language Independent Dialog Disogn [message #583557] |
Fri, 27 September 2002 15:51 |
Eclipse User |
|
|
|
Originally posted by: cpklapper.yahoo.com
To my mind, one of the biggest flaws of Java as a development environment
was that it never provided a dialog specification language like DCL
(dialog control language). As a result, each IDE was left to its own
devices in creating their own or, worse, trying to maintain compatibility
by implementing dialog design through code insertion. Meanwhile,
Microsoft's C++ development imbedded dialog specification into a
monolithic resource file, though thankfully in text form so that with a
little tweaking programmers can copy dialog designs from one project to
another. Sharing is another matter entirely.
Eclipse can do a great service by providing a standard format for
(OO)language-independent dialog specification. My little insight into
this matter is to provide the language independence through the dialog
compilers producing the abstract base class in the compiler's target
language. That will allow each language-dependent application to use the
dialog through its own derived class. Eclipse would have to pick up
changes to the dialog which affect the signature of that class in the same
way C++ IDEs do for include files. A nice little additional feature would
be a dialog scripting language for intra-dialog interactions such as input
verification and control dependencies that are part and parcel of the
dialog specification. Again, the dialog compiler for Java would translate
these scripts into byte code and the dialog compiler for C++ would
translate them into object code.
All of this assumes a language-independent way of handling
controls(widgets) and bringing some extensibility through a control design
tool. As with beans and ATLs (COM-based Windows controls), the
language-independent control (LIC) should define a signature which the
language-independent dialog (LID) can then use. As with the LIDs above, a
LIC could include scripts and design elements that limit the
implementations to truly language-dependent code. A LIC would thus
produce two abstract classes: one for implementation and one for use. If
the implementation class is empty, no language-dependent implementation is
needed; the language dependence has been completely satisfied by the
control compilers. If the implementation class is not empty and there is
no implementation of the LIC for the project language, eclipse should
produce an error during linking and advise the developer to find an
implementation of the LIC for the project language, or configure a
cross-language call into an implementation of the LIC in a different
language. Existing work could be preserved with a tool which produces the
LIC and a shell implementation for an existing control.
Now that ought to keep us all busy for next year.
|
|
|
Powered by
FUDForum. Page generated in 0.03095 seconds
] 
Search
Help
Register
Login
Home
