Previous contents here thinking of a XML dialect to describe the gui is moved to the java wiki JinxWiki on the SwikiFarm to the page "Gui XML Projects" http://jinx.swiki.net/165 ---- My beloved DeclarativeGuiLanguage, after much evolution, worked out very well (says me) and was used for the configuration wizard part of the (discontinued) BluetailMailRobustifier. More recently, we did a new incarnation of the GUI stuff in Erlang. So don't be too afraid the next time you consider writing part of that Java program in SchemeLanguage! -- LukeGorrie Interesting, did you use XML? No. In Scheme, there isn't much point, since it has its own support for representing and manipulating tree-structured data. Also, I'm of the "XML is a poor-man's SEXP" opinion. -- LukeGorrie ---- Here is an example program in my ficticious declarative language for describing GUIs. I hope to grow a language like this, and have some humble beginnings. ;;; Declaration of a username/password entry dialog. ;; Initialise the components. `password' and `password-verify' are the ;; usual sort of "enter same password in both fields for confirmation" ;; arrangement. (make-components (username text-field) (password password-field) (password-verify password-field) (ok ok-button) (cancel cancel-button)) ;; Layout the components. username, password, and password-verify get ;; their own rows, but the buttons are laid out horizontally on the ;; same row. (layout username password password-verify (horizontal ok cancel)) ;; The username is valid when it's non-blank. The password is valid when ;; it's both non-blank and equal in value to the password-verify field. (constraints (username (valid-when not-blank)) (password (valid-when (and not-blank (eq? (value-of password) (value-of password-verify))))) ;; the OK button is only enabled (unshaded, clickable) when the ;; username and password are valid. (ok (enabled-when (and (valid? username) (valid? password))))) I think that this will be very useful. I think I'll be able to grow things incrementally by starting small, allowing arbitrary java and scheme code to be mingled with declarations, and then incrementally rewriting imperative code into declarations. I'm interested in hearing from anyone who's having similar thoughts, if such a person exists. -- LukeGorrie ------- WyCash used a declarative definition for the numerous data entry screens in the product. The minimal format was easy to enter, store and interpret. #(('Customer Information') ('Name' 20 firstName lastName) ('Addr' address) ('City' city) ('State' 10 state 'Zip' zip)) This is a Smalltalk literal array with elements of four different types that are used as follows. * Array -- the inner ( ) -- a complete line of the form * String -- label text * Symbol -- from which getters, setters and format info is retrieved by reflection * Integer -- temporarily overrides the default field width We had previously used well factored code to create all of our screens, much like is now the convention with Swing. We found the declarative form to be a huge improvement, mostly because we didn't have to think up and remember so many names. We converted all of our source code to the new form through an elegant refactoring (WardsRefactoring) where we executed the code and asked the resulting object structure to report the decleration that would reproduce it. We started this development one morning and were finished before lunch. -- WardCunningham Beautiful tale, very inspiring. And I'm happy to say that after a good night's hacking, I've implemented most of my language. I never knew GUI coding could be this much fun. ;-) --LukeGorrie Well we are trying to start with this ourselves. We don't think this would be much difficult. see "Swing XML Project" (http://jinx.swiki.net/384) on the JinxWiki (a wiki for java) on the SwikiFarm --SebastianPetzelberger ''Is this a codified DataDictionary?'' Sorry, I don't understand your question. Belongs it to "Swing XML Project" or to WyCash? ---- I don't really think you can get rich interactivity with just simple property assignments. You can add event hooks, but too many of those defeat the entire purpose of a declarative language. Back when I was in high school, I wrote GUI software for an engineering company that had lots of these input screens. I ended up writing a declarative tool, but I allowed the properties to be arbitrary functions of other properties. Even then, I thought the results were mixed, I may have been better served just by writing a bridge to get a clean interface to the GUI layer and writing code directly. JoeHendrix ---- It's a very good technique. However, GeoWorks asserts an egregious software patent [SoftwarePatents] over this whole technique. You're not allowed to use it. Yes, I'm serious. See http://internetalchemy.org/items/1050/ [BrokenLink, 2003-02-13] and http://www.google.com/search?q=geoworks+wap+patent ''Too stupid a patent to acknowledge. Being outside the US, there's probably no need for me to, though.'' Also, it seems that the technique has been implemented by several people before, and so falls under prior art. Known uses include: * Ward's WyCash example, quite a ways before this patent. * NatPryce and Hal Fossa's CORBA object browser (http://www-dse.doc.ic.ac.uk/~np2/mmn/tools.html). * Meta-GUI, a declarative GUI toolkit for Tcl/Tk (http://www.stratasys.com/software/metagui/). According to an article in DrDobbsJournal, The GUI toolit for the RebolLanguage will also follow this approach. ''The mere existence of PriorArt does not mean that the patent can't be used as a threat. In any case, the victims of the patent are fairly substantial ConsumerElectronics companies: one would think that Nokia would be able to fight this patent if anybody is.'' ---- See also RemoteGuiProtocols, MozillaXul, DataDictionary, DeclarativeGuiFrameworks ---- CategoryUserInterface