Posted by Eitan Suez
Wed, 06 Dec 2006 17:07:00 GMT
Reasons to license JMatter:
- Fee is per-developer: no royalties; can build as many apps as you like
- Free updates; no upgrade traps
- Excellent documentation
- No support fees; your questions answered in a
timely manner on the mailing list, by the framework's
author, and by others JMatter-savvy developers
- Comes with all the source code!
Cost-Benefit Analysis
Estimate how much time and effort you might save by using JMatter.
Perhaps one man-year? Now do the math: $500 / year for JMatter
compared to the cost of one man-year of development (perhaps
$100,000), with no promise that you'll have a workable product at
the end? That's a 2000:1 ratio.
Reasons to consider donating
- Do you like what you see?
- Do you want to see it thrive?
- Without your contribution, this project may not
be able to sustain further development indefinitely
7 comments
Posted by Eitan Suez
Thu, 30 Nov 2006 13:00:00 GMT
In many ways, JMatter is:
- massive
- rich
- well documented
Still, there are more features than there is
documentation. This blog has helped me redress
the situation somewhat.
So in this entry I'd like to discuss another feature,
not completely polished, that's been in JMatter for
a while that you may or may not know about: the
fact that JMatter saves and restores end users'
desktops between sessions.
That is, the size and positions and other information
about all open windows is recorded and stored to the
database when you quit or log out, and restored when
you log back in.. which makes this feature independent
of the workstation you log in to.
no comments
Posted by Eitan Suez
Wed, 29 Nov 2006 18:36:00 GMT
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.
4 comments
Posted by Eitan Suez
Tue, 28 Nov 2006 11:52:00 GMT
Every Swing application gets for free the ability to use the underlying platform's copy and paste capabilities when working with JTextFields and JTextAreas.
In JMatter you might have noticed that instances also sport their own Copy/Paste commands. You'll find this feature to be a little more powerful and interesting compared to the basic clipboard copy/paste feature.
The main difference is that unlike the clipboard, where you get one temporary area to copy to, JMatter provides a temporary "buffer" area for every distinct type.
So, for example in the Contact Manager demo application, I can go about and copy an Address here, a Contact object there, or an entire Person instance and all three copies exist in memory simultaneously, each in its own buffer. I can then, say, create a new Person instance and right-click "Paste" on the title view for the new instance. All of the information is copied over. This use case may not be very interesting or real.
But there are other situations. Take for example how a Person has a Contact property modeled using composition (or aggregation). Each instance has its own copy. Yet it's very possible for two persons to have the same contact information, or perhaps the same address, with the very real possibility that the two copies will change/diverge over time.
The copy/paste commands on instances are automatically placed by JMatter in a number of context menus for a number of views. You'll find these commands in the title view's context menu, as shown below.
You'll also find it on aggregate objects' nodes as shown below.
Finally, you'll find it on the context menus for individual tab title views, as shown here:
This is a minor, though useful feature that comes in handy and can save repetitive data entry tasks, where one might otherwise have to invoke copy/paste individually on atomic fields.
no comments
Posted by Eitan Suez
Mon, 27 Nov 2006 09:49:00 GMT
The JMatter project has reached a small but very important milestone over the last week: our mailing list has now reached 100 users!
I haven't really been pushing very hard in terms of marketing JMatter over the last few months. Yet, our mailing list and interest in JMatter in general has been slowly but steadily growing. This is an important trend.
To me it means that the ideas behind this framework are important. It also means that this idea is not a fad and will not simply go away. Finally it means that people believe that this framework will grow in importance and in maturity over time.
I think we, the JMatter community, should all be proud of this achievement. We should see over the next couple of months some really strong momentum, including a new release, and steady progress in a number of directions.
no comments
Posted by Eitan Suez
Fri, 17 Nov 2006 23:21:00 GMT
I admit it's now been a while since I wrote this code. So as
I give you the information on Field Paths, I'll also be giving
myself a refresher.. :-)
The idea is simple but essential. The JMatter codebase has this
notion of a field path. It's basically a way of serializing
a field object as a string.
Many situations call for such a feature. The main one I can think
of at the moment is regarding one of JMatter's features:
the ability to define and save ad-hoc queries.
In JMatter, one can construct a query visually right there in the
application and save it for later user. Let's look at an example:
Let's fire up the Contact Manager demo application. You can browse
contacts. In my app, I've created a single person contact who lives
in the city of Austin.
Next, I right-click "Find" on "Person Contacts" and define a query:
I'm looking for all people who live in Austin. I can navigate the
ComboTree widget to the right field: Person->Contact->Address->City
In this case, I specified "city starts with austin" when in fact
"city is austin" might have been a better choice.
Anyhow, one of the features of JMatter is the ability to name and
save this query. Indeed queries in JMatter are like other JMatter
objects: they can be persisted, listed, and queried (as in
"show me all queries containing the word "Austin" in their name).
So somehow JMatter needs to be able to save the query. If you look
at the database schema, you will see tables such as "queryspecifications"
and "compositequery" which concern themselves with this task.
If we peek at queryspecifications we can see that the query has
indeed been persisted. Fields are serialized as field paths and
restored from these field paths.
The fieldpath that was created for our query is:
com.u2d.contactmgr.PersonContact#contact.address.city
Let's take another example. Let's try to find users who belong to the
"Default" role.
Figure 2 shows that I've defined and saved my query. The corresponding
field path is:
com.u2d.app.User#role|com.u2d.app.Role#name
We note two things about this:
- JMatter query specifications allow users to traverse associations;
- The way these associations are denoted in field paths is via a
vertical bar character.
Being able to define query specifications and to execute them and
finally to persist them is very important and fundamental. It can
be used as a building block for building a generic mechanism for
constructing reqports. Indeed, this is one of my goals for JMatter:
to build into the application the ability for users to define reports:
to associate queries with a specification of the report: what
columns to display, in what order, how to sort the results, etc..
Paths appear to be something not so unique to fields but more general
to Members. Commands may be specified also using a path-like notation,
for example: com.u2d.type.composite.Person#Edit can represent the
Edit command on Person's. In the latest subversion commits, it does.
Finally, field paths don't have to be something that is hidden behind
the scenes of an implementation. We can use them actively as a simple
means of identifying paths for relating metadata.
So for example, in subversion I can now specify the default search
field for a type as a field path. If you recall the tip of the
week from July 7 entitled Associations made easy I describe how
association editors allow you to search in-place for objects of
a certain type for the purpose of associating one to another
object. The screenshot in that blog entry illustrates how this
works.
At the time, we used to have to write code like this to specified
the default "search-by" field:
static
{
ComplexType type = ComplexType.forClass(Speaker.class);
type.setDefaultSearchField(type.field("name").field("first"));
}
Now you do it like this:
public static String defaultSearchPath = "name.first";
Technically the value that this field takes is a relative field path.
So now you know about field paths. I've recently been thinking about the design for authorization. JMatter has had authorization-related code built-in for a while but the
implementation is not complete. I'm realizing that essentially what I'm doing
there is building a JMatter application where the domain in question happens
to contain some meta-types. We're specifying restrictions on Commands
and restrictions on Fields. I hope to have a fairly usable implementation soon,
with a predefined default authorization policy, and the ability for administrators
to define new roles and their authorization policies visually directly in JMatter.
Much of that has to do with empowering meta-information as true JMatter objects
in JMatter. I'll be writing more about that in a future blog entry.
/ eitan
no comments
Posted by Eitan Suez
Thu, 16 Nov 2006 21:28:00 GMT
Yesterday I redid the Icon resolution for types. I thought this might be a good topic for re-starting the jmatter blog entries. Activity here has been somewhat dormant for a while..
The way icons are associated with types is by following a naming convention. The idea was well-illustrated in NakedObjects v1.0. For example, if you have a class User.java, you can place icons User32.png and User16.png in the resources/images directory and that icon would be used in a number of the views representing instances of this type.
In JMatter, there are a number of twists. For one, you can specify different icons to be used for lists of users. So Users32.png and Users16.png are also automatically picked up for use by views of lists of users.
Here's the second twist: User.java in JMatter is Stateful. A User can be in Locked or Unlocked State. So, UserLocked32.png and UserUnlocked32.png are also automatically picked up and preferred for instances in a given state. I use this to show an icon of a user with a Lock icon overlayed on top of it.
Of course, JMatter will pick up either a png or a gif.
Here's the new twist I put in yesterday (in subversion): inheritance fallback. So take the ContactManager demo application as an example. In it, I create the class PersonContact which extends the Person class. I no longer need to provide a PersonContact32.png icon. The app will automatically fall back to using Person32.png.
I feel good about this small enhancement. In the next weblog entry, I will talk about some of the progress I've been making recently on the meta-front. Lots to talk about and it's pretty exciting.
/ eitan
no comments
Posted by Eitan Suez
Wed, 08 Nov 2006 05:37:00 GMT
Although you should see very little difference between the jmatter.org web site today and the version of jmatter.org that existed a few minutes ago, the new jmatter site now runs on the latest version of the typo content management system.
You'll notice that the spam in the comments is now gone. :-)
I'm planning on enhancing the look of the jmatter web site. This will likely not take place for another month. We hope to provide a new logo and branding for this project and an improved look and feel.
If you'd like to volunteer some of your time and talent to this end, drop me a note! ( eitan.suez@gmail.com )
2 comments
Posted by Eitan Suez
Mon, 11 Sep 2006 23:46:00 GMT
We have just published a paypal button to accept donations for supporting this open source project.
Show your support for JMatter by donating to this project.
Sincerely,
Eitan Suez
no comments
Posted by Eitan Suez
Thu, 07 Sep 2006 03:44:00 GMT
We are taught that interface-based modeling is preferred over models that do not employ interfaces. I concur. In this short tip, I'd like to demonstrate how to do interface-based modeling in JMatter.
As an illustration, let's take the original Sympster application and extend it. Sympster is a conference manager demo application. Up until now, one could use this application to define a symposium, speakers, their talks, and to schedule sessions. A session is defined as a talk given at a specific date and time, and with a specific duration, at a specific location.
I'd like to broaden the definition of a session to include events other than speakers' presentations. What about BOF's (Birds of a Feature session) for example? Or maybe a panel discussion including a number of participants. At NFJS symposia, we actually hold informal BOFs with 2-3 participants where we discuss a particular topic.
Accompanying this blog entry are the code changes committed to Sympster in subversion revision #84, which essentially implements this enhancement. Let's walk through the code.
The first thing I do is define the interface Event:
public interface Event extends ComplexEObject
{
}
It's not much of an interface but it turns out that ComplexEObject already includes the contract that I will need: the requirement that every event have a title:
public Title title();
I still want to define this interface as it serves as a mechanism for qualifying event types.
Next, let's go ahead and define a new object to model a BOF:
public class BOF
extends AbstractComplexEObject implements Event
{
private final StringEO title = new StringEO();
private final RelationalList participants = new RelationalList(Speaker.class);
public static Class participantsType = Speaker.class;
public static String[] fieldOrder = {"title", "participants"};
public BOF() { }
public StringEO getTitle() { return title; }
public RelationalList getParticipants() { return participants; }
public Title title()
{
return title.title().append(" with", participants);
}
}
Finally, let's retrofit our existing class Talk:
eitan@ubuntu:~/build-area/jmatter-ba/demo-apps/Sympster/src/com/u2d/sympster$ svn diff -r83:84 Talk.java
Index: Talk.java
===================================================================
--- Talk.java (revision 83)
+++ Talk.java (revision 84)
@@ -7,7 +7,7 @@
import com.u2d.reflection.FieldAt;
import java.awt.Color;
-public class Talk extends AbstractComplexEObject
+public class Talk extends AbstractComplexEObject implements Event
{
private final StringEO title = new StringEO();
private final TextEO talkAbstract = new TextEO();
As you can see from the above diff, all I had to do was specify that Talk implement Event.
Finally, remaining is broadening Session's definition. Rather than define an association to a Talk, we'll revise that to be be an association to an Event. I won't show you all the edits. Here's the gist of the change:
- public Talk getTalk() { return talk; }
- public void setTalk(Talk talk)
+ public Event getEvent() { return event; }
+ public void setEvent(Event event)
And that's it. Now let's take a look at how these changes manifest themselves in our application:
Polymorphic Queries: Listing Events
Discussion:
JMatter models the polymorphic association using Hibernate's
implicit polymorphism mechanism, otherwise known as any
associations.
Polymorphic Instantiation: Creating a new Event
Discussion:
JMatter will prompt the user whether they wish to create
a talk or a BOF.
The calendar:
Discussion:
We see two events on this calendar. The first is a talk on JMatter,
and the second is a BOF on Programming. :-)
no comments
