Discussions

News: Abstract User Interface Markup Language Toolkit

  1. Abstract User Interface Markup Language Toolkit (7 messages)

    The AUIML Toolkit includes the AUIML VisualBuilder, which is an Eclipse-based visual panel editor built on top of the Eclipse Visual Editor Project. The AUIML VisualBuilder allows developers to build user interfaces and generate Java data and event-handling code for them. Additional Java code can be written to AUIML's API to control application flow, data validation, and to listen for events. Once the application is implemented, it can be deployed as a Java Swing application or as an HTML servlet without changing the application's code.

    The current release of the AUIML Toolkit includes both a Java Swing Renderer and an HTML Renderer. The Swing Renderer provides rich client functionality for installed applications by using Java Swing technology to display the panels. The HTML Renderer runs as a servlet and sends an HTML representation of the panel to the client browser, allowing the same application to run on the Web without any source code changes.

    Read about the Abstract User Interface Markup Language Toolkit

    Threaded Messages (7)

  2. Do you have any idea how the abstract user interface markup language compares to other XUL (XML UI Language) toolkits such as SwiXML, XUI, Thinlet, xWidglets or Luxor? Does it support tags such as hbox, vbox, grid, tabbox, etc.? Can you point me to an example?

    - Gerald

    PS: To find out more about alternative XUL toolkits you might wonna check out the XUL Alliance site online @ http://xul.sourceforge.net

    PPS: Does anyone know anything about IBM's RCPML (rich client platform markup language) XUL dialect for the Eclipse-Powered Lotus Notes Client/Workplace?

    PPPS: I invite you to cast your vote in the ongoing Java Republic online poll asking: "What Java XUL Toolkit Do You Use Most?".
  3. Gerald,

    Why are you such a controversial figure? I personally find your views and opinions very vernomous. Please help me understand this behavior of yours.

    Francis
  4. XUL Motor = AUIML Renderer ?[ Go to top ]

    I'm not really familiar with either of these, but one thing I like about AUIML is the renderer support for Swing and HTML. So one script can be a web app or a Swing app. Zipping through the XUL site you posted, I did not see any HTML XUL motors. Does such a thing exist ?
  5. XUL Motor = AUIML Renderer ?[ Go to top ]

    So one script can be a web app or a Swing app

    Nicholas: I can give you an example where one script can be a web app or a desktop app ;). I'm talking about Zulu (zulu.netspedition.com)

    Anodos: You could check that link too if your're curious about other implementations of XML based declarative user interfaces using MVC internally.

    Ovi
  6. How does it work?[ Go to top ]

    Without taking time to look at the actual download, I'm curious as to how this is implemented... does it do its magic at runtime, or does it require the Eclipse plugin for some kind of code generation based on the targeted UI? Does it use any other frameworks internally, such as JSF, Struts, Spring, etc? Does it use MVC internally? What kind of controls does it come with/use? Does it have to reinvent all of its controls, or can it somehow reuse Swing or some other platform's controls (JSF)?
  7. scripting option ?[ Go to top ]

    just checked it out - very neat !
    guess we are well on our way to MDA...

    only comment I had was see if there is/will be any scripting
    support to embedded processing directives in the AUIML file
    itself using ECMAscript etc.., and not delegate it all to java

    I know it might get messy and there would be no clear separation
    between view/model - however, scripting support might help
    easy customization in the field etc.

    just my 2cents...
  8. abstractness[ Go to top ]

    only comment I had was see if there is/will be any scripting
    support to embedded processing directives in the AUIML file
    itself using ECMAscript etc.., and not delegate it all to java

    Well, to avoid repeating the JSP debacle. I think the way to solve this is to allow users to write their own renderers, and the renderers would decide what ECMAscript activation code gets run. You may need to add some declarative fields to AIUML to get this to work though..