Tuesday, September 30, 2008

Metawidget: Ready, Set, Action!

The new release of Metawidget furthers its philosophy of 'inspecting the existing back-end for as much information as possible' by going after actions.

So now, in addition to automatically generating and wiring up textboxes, checkboxes etc. based on the properties of your business model, it'll generate buttons based on the actions of your business model.

This support is all pluggable, of course. With this release we've included two plug-ins: one for JBoss jBPM and one for Swing AppFramework.

JBoss jBPM


If your back-end architecture uses JBoss jBPM to define pageflows...

<pageflow-definition name="newuser">
   <page name="contact">
      <transition name="prev" to="account" />
      <transition name="next" to="card" />
   </page>
</pageflow-definition>

...then you can now point a Metawidget at that pageflow...

<m:metawidget value="newuser.account"/>

...and it'll generate command buttons that are localized and wired up to the correct actions...


You can see this in action in the included DVD Store Example, which retrofits an existing Seam application to generate its input fields and command buttons automatically, reducing all that boilerplate code.

Swing AppFramework


If you're using the Swing AppFramework (JSR 296) to structure your Swing app...

@Action
public void save( ActionEvent event ) {
   mMetawidget.save();
}
...then you can now point a Metawidget at your business model, and it'll generate command buttons that are localized and wired up to the correct actions. You can see it in action in the included Car Demo.

You can further combine all this with the other pluggable inspectors, such as JexlInspector to easily and declaratively control your app's actions...

@UiAction
@UiJexlAttribute( name = HIDDEN, value = "${!this.readOnly}" )
public void edit() {
   ...
}

@UiAction
@UiJexlAttribute( name = HIDDEN, value = "${this.readOnly}" )
public void save() {
   ...
}

@UiAction
@UiJexlAttribute( name = HIDDEN, value = "${this.readOnly || this.newContact}" )
public void delete() {
   ...
}

@UiAction
@UiComesAfter( { "edit", "delete" } )
@UiJexlAttribute( name = "label", value = "Back", condition = "${this.readOnly}" )
public void cancel() {
   ...
}

This code is enough to generate:
  • an Edit button that, when clicked, disappears in favour of...

  • ...a Save button

  • a Delete button that only appears if it's not a new business object

  • a Cancel button, that says Back if the user has not edited anything yet

You can see it in action in the included Swing Address Book Example...


So now there are even more places Metawidget can inspect your existing back-end architecture and remove the need for you to write boilerplate code for your existing front-end framework!

5 comments:

Anonymous said...

Sigmund Freud may have edited your pages: Swing/Spring Appframework ?
Regards...

Codezilla said...

Metawidget = Naked Objects with more platforms?

http://www.nakedobjects.org/home/index.shtml

Richard said...

Anonymous: thanks for the correction!

CodeZilla: yes, there are definite similarities with Naked Objects. The three big differences are:

1. Yes, Metawidget runs on more front-end platforms

2. Metawidget runs on more back-end architectures too: this is important! Metawidget does not impose a stylized back-end architecture on your applications (eg. requiring all business logic be put on the domain objects, with no controllers, like Naked Objects does)

3. Metawidget does not try to 'own' the whole UI. It is just a widget that plays well alongside all the other widgets in your UI toolkit, allowing you the full power of your chosen framework.

Anonymous said...

When I saw "jBPM" I thought you may have meant a replacement for the insufficiently rich/pretty forms that can be generated from jBPM Tasks. While the functionality you describe is useful, it has more to do with Seam pageflows and the jPDL syntax than it does the long running business processes I think of when you say jBPM.

That said, I will still be evaluating metawidgets for the purpose of supporting task UIs.

Richard said...

sjgibbs,

Thanks for your interest in Metawidget. Yes, when I say 'JBoss jBPM' I'm referring more to the umbrella product, and you're correct that within that it's more the Seam pageflows and jPDL.

That said, I'd love to more fully support jBPM. I am not aware of the 'forms that can be generated from jBPM tasks'. Can you tell me more about them?