Sapia OSS releases Gumby 1.0

Discussions

News: Sapia OSS releases Gumby 1.0

  1. Sapia OSS releases Gumby 1.0 (9 messages)

    Gumby is a XUL framework that closely sticks to Swing, and will be mastered rapidly by Swing programmers that are looking for a productivity boost.

    One of Gumby's goals is to elimitate the hassles that consume so much time when building UIs in Java: the tedious code-compile-test cycle, the harcodedness and verbose syntax (casting, static typing), the wiring Java code that links UI components with business logic and that often becomes spaghettified.

    Gumby sports the following features:

    - XML markup that is tightly bound to Swing: you use XML elements and attributes to instantiate objects and call methods on these objects.

    - As part of the toolkit, a couple of classes and interfaces that helps structure applications and can easily be integrated with existing lightweight containers.

    - Scripting integration through BeanShell and Pnuts.

    - Support for databinding: build forms in a snap through a clean MVC implementation.

    - Some goodies such as the TablePanel class that puts an HTML-ish face on the dreaded GridBagLayout.

    - Ability to extend the framework with your own tags.

    - Exhaustively documented.

    For more details: http://www.sapia-oss.org/projects/gumby/.

    Threaded Messages (9)

  2. Web Host Down[ Go to top ]

    It seems that Sapia's ISP is currently struggling. We have setup an alternate Gumby site:

    http://sapia.sourceforge.net/
  3. Gumby vs. SwiXML vs. SwixNG[ Go to top ]

    Gumby is a XUL framework that closely sticks to Swing, and
    > will be mastered rapidly by Swing programmers that are
    > looking for a productivity boost.

      Can you let us know how Gumby differs from established Swing XML UI language (XUL) frameworks sucha s SwiXML or SwixNG. See http://xul.sourceforge.net/swixml.html for details.

      - Gerald
    _______________________________
    Thinlet World - http://thinletworld.com
  4. Gumby vs SwiXML[ Go to top ]

    1) Gumby makes use of XML namespaces, which allows cleany separating tags pertaining to Swing vs Gumby tags vs your own tags: name collision risks are minimized.

    2) Gumby IS Swing - it does not abstract Swing details:

    SwixXML:

    <button Text="Click Here" Action="submit"/>

    Gumby:

    <swing:JButton text="Click here">
      <actionListener>
        <myTags:submit />
      </actionListener>
    </swing:JButton>

    3) Gumby has built-in support for scripting

    In the preceding example, SwiXML tag delegates action handling to a method called "submit" - invoked through Java reflection. This implies that your must code your actions in Java (or at least part of them, since this is what SwiXML expects).

    With Gumby's built-in support for scripting, action handling code can be scripted, sparing you the tedious code-compile-test cycles. Thus:

    <swing:JButton text="Click here">
      <actionListener>
        <gumby:Expr>
        import java.awt.event.ActionListener;
        import java.awt.event.ActionEvent;
        new ActionListener(){
          public void actionPerformed(ActionEvent e){
            ....
          }
        }
        </gumby:Expr>
      </actionListener>
    </swing>

    4) Databinding

    Gumby support databinding and MVC in a very clean way. You can use Gumby's built-in JXPath-based tags to handle basic form input, or you can implement your own bindings.

    5) Ease of extension

    Having a look at the source of Gumby tag implementations will prove to you how easy it could be to implement your own tags. Everything is reflection-based.


    Have fun.
  5. Gumby vs SwiXML[ Go to top ]

    Why not producing a JSF renderkit for the same taglib? That would let us to have one XML file for both web and Swing...
  6. Gumby vs SwiXML[ Go to top ]

    Well,

    for one thing, I don't like meta-frameworks: "hey, you can switch to whatever implementation you want behind the scenes"... This has drawbacks: for example you end up having to build abstraction layers that, in the end, hide the power of each actual implementation.

    In addition, it takes time. I'm only human.
  7. Why code Swing in XML?[ Go to top ]

    I still don't get it why everybody is keen on describing their GUIs in XML. There is allready a very efficient and very flexible format to describe GUIs: it's called Java.

    Java code, that builds a GUI, is very efficent (runtime and network) and you can actually run it in a debugger. You can deploy it locally as an app or remotely with an applet or Java Webstart.

    Juergen
  8. Why code Swing in XML?[ Go to top ]

    (runtime and network) and you can actually run it in a debugger. You can deploy it locally as an app or remotely with an applet or Java Webstart.Juergen


    Guess what: Gumby is also Java. It creates Java objects. You can embed Gumby in an applet if you please. Therefore your point does not hold, in many ways...

    What remains is: Java code used to build UIs. You can stick to that if you want. But I find it painful and counter-productive in lots of cases. Hey, what can I say, I'm lazy; I like to sleep at night. I take no glory in the contrary...
  9. Why code Swing in XML?[ Go to top ]

    I still don't get it why everybody is keen on describing their GUIs in XML.

    JDNC does the same thing. By doing things in XML you allow for seperation of concerns. The UI designer can make a prototype and edit XML.
    (Same as DAO in XML, db can have at the SQL Strings)

    You don't care about collor shades and spacing of the white space.

    The future langages will be declearative like XAML and Flex.

    .V
  10. Good Job[ Go to top ]

    HTML-ish face on the dreaded GridBagLayout, and extendable databinding, and ...

    What can I say? Thanks, Yanick.

    BTW, compiling the example source is a little bit annoying, hope this could be added in the antfile in next release :-)