JMatter Blog: Sneak Preview: Naked Members?

Sneak Preview: Naked Members?

Eitan Suez — Wed, 29 Nov 2006 12:36:00 -0600

A new JMatter release is overdue and coming soon! I need to tie together the loose ends, such as updating the documentation to reflect what's changed (there's a lot coming!), and making sure everything is in sync, that everything works together.

This blog entry is about one of the features that you will find in the upcoming release of JMatter: the fact that administrators now have the ability to view and edit Member metadata directly from the GUI.

What does this mean? And more specifically, what metadata? Let's fire up our trusty ContactMgr demo application (bundled with JMatter) and take a look.

In the above figure we're viewing a model object: a contact. Here's what's new: fields' commands are exposed in a context menu on each field's caption:

Let's take a look at the "Home Phone" field:

Let's edit this information. We'll customize the label for this field to "Home Tel.". Let's also mark the field as required, specify a mnemonic, even provide a description (which will appear as a tooltip on the field):

Usability side note: note how the user interface for doing all this is precisely the same mechanism used for editing any old JMatter object. End users (administrators in this case) are already familiar with the gestures, how to go about manipulating their information.

Ok, let's now save our changes and dismiss the view. We notice the changes take place immediately:

Pretty neat eh? All this information is saved to the database, just like any other old JMatter object. So, we now have multiple ways for designers to specify metadata: there are annotations and conventions in the code. You can even use ultraviolet's designer to specify graphically some of this information. UV will faithfully generate the proper code for you. Here we see a different approach to code generation: the meta objects are part of the system and as such can be viewed, edited and managed.

Ryan (the author of ultraviolet) and I have had a discussion or two along these lines. Perhaps some day, full design capabilities will exist as a JMatter application proper: Type definitions, modeling, code generation, auto-compiling of the code, and finally, running the application.

One more round: Commands

We have two types of members: fields and commands. Let's do for commands what we just did for fields. Let's right-click on a command button to expose its context menu:

Let's open the Edit command and edit some of the information about it:

In this case, I didn't change the label or mnemonic, but I did add a tooltip, and marked the command as sensitive. Sensitive commands are ones that you want to guard, perhaps with a lock. The Delete command is a good candidate: to guard against inadvertant deletions, you have to first unlock the command and then invoke it (a sort of are you sure? mechanism).

Ok, let's save the object and view the change in action:

We see here the tooltip showing. Also, the command was locked; I first unlocked it before producing the above snapshot.

There you have it: the new Naked Members feature (in subversion), available in the upcoming JMatter release.

A note on Authorization

Since these features are really design features, they're accessible only if you login as a user with administrative privileges. In order to make this work, I've been hard at work on supporting authorization in JMatter. I've made a lot of progress on this front, but am not completely finished.

More information on authorization will follow.

Let us know what you think.

"Sneak Preview: Naked Members?" by Eitan

Wed, 29 Nov 2006 23:07:09 -0600

If this is your line of thinking then

no, it's not my line of thinking.

i'm just suggesting that perhaps some aspects of development are better suited for the ide (after all, it is called a 'development' environment).

typically, thinking about the tradeoffs of doing things one way or another helps me form a better opinion. i hope that makes sense.

ultimately i do believe that the domain of software development is just that: another business domain. and so perhaps we too can use the same type of environment we deliver our customers for doing our work. and if that environment is not good enough, then maybe it's not good enough for our customers either and we should improve upon it. :-)

"Sneak Preview: Naked Members?" by peter qwerty

Wed, 29 Nov 2006 22:51:06 -0600

"changing a field type from a gui, or directly in a text editor or ide"

If this is your line of thinking then, why not leave the metadata changes you just implemeneted in the text editor rather than the gui?

At the end of the day, it is cumbersome to change a few things in the gui while others in a text editor, while having a 3rd party application do other changes.

The same can be said of changing properties files here while changing xml files in another place to configure your application.

"Sneak Preview: Naked Members?" by Eitan

Wed, 29 Nov 2006 22:10:02 -0600

thanks! Complete modeling/design capabilities are really the domain of UltraViolet. and i hope that's where it'll eventually go. actually field types can be specified in ultraviolet right now. also, which is easier: changing a field type from a gui, or directly in a text editor or ide? :-)

"Sneak Preview: Naked Members?" by peter qwerty

Wed, 29 Nov 2006 21:08:26 -0600

Not a bad effort, but seems only limited to trivial changes - more useful if you can edit field validation rules in the gui, add fields or change the field type from string to integer.