Monday, July 30th, 2007

jMaki Actions: Communicating between toolkits

Category: Java, jMaki

jMaki Actions are a declarative way of associating widget behavior. The goal here is a holy grails of grabbing a Dojo widgets and a Prototype based one, and having them talk together.

Greg shows an example:

Consider a case where you have a Dojo Fisheye and you simply want it to select a tab or URL when an item is clicked. The Dojo Fisheye is in essence provides the same behavior as a menu. You may notice that the models for the Fisheye Model and the jMaki Menu Model are very similar.”

jMaki models uses general conventions for behaviors and properties you can easily swap widgets. For example you could easily use a Dojo Tabbed View or even swap the FishEye for a menu or tree widget.

jMaki actions are great for general interactions like this and makes it really easy to do basic things like this. More advanced interactions should still be done in glue code as described in Widgets talking to Widgets.

Widgets talking to Widgets

Posted by Dion Almaer at 5:00 am

3.1 rating from 65 votes


Comments feed TrackBack URI

Where is the point in mixing widgets from different Frameworks? While technically challenging, I don’t see much practical use in doing it. Most frameworks don’t provide widgets as isolated components but build their widgets on a more or less complex supporting framework. This means in general that mixing widgets will result in a bulk of duplicated code from both frameworks, which will inevitably lead to a bloated application.

Other things like focus handling, keyboard navigation or theming will only apply to widgets of the same framework.

I don’t say mixing frameworks doesn’t make sense. Combining e.g. Backend communication, XML processing and Widget Frameworks is perfectly reasonable. I just don’t see the point for mixing widgets.

Comment by Fabian Jakobs — July 30, 2007

Hi Fabian,

There are a lot of good toolkits and widgets and toolkits out there and we are providing a way for users to make a best of breed UIs taking what they need. With jMaki under the covers we go through great lengths to make sure we keep application size down and use optimized code. We can do this because we use a hybrid client server approach which we plan to further enhance it in the future.

Our users and many of the toolkit providers also believe toolkit interoperability is important. This can be seen with the work being done with the Open Ajax Alliance which the Sun (jMaki team) are participating in.

Comment by Greg Murray — July 30, 2007


Comment by proddy — July 30, 2007

Just to make this clear: Toolkit interoperability IS important. I just have doubts that it is useful on widget level as IMHO the end user experience would suffer from that. I think in most cases it would be more appropriate to choose one toolkit and if widgets are missing port them from other toolkits. This might be more work but in the end the result will be much better.

Comment by Fabian Jakobs — July 31, 2007

Hi Fabian,

I agree that it would be best to stick with one if there is one that provides everything needed. Theming, event management, and drag and drop are other issues also make it difficult to mix and match widget tool sets without a bit of work.

If you look under the covers of jMaki you’ll see we have much of the infrastructure to build some pretty interesting things and as we really promote a structure that cleanly separates behavior/model/markup. The real challenge is how to manage code dependencies and inheritance while at the same time making the code easy to follow and manage by others (it always seems that one user for one reason or another want to change some way a widget operates).

There are finally a lot of good frameworks out there, I dare not try to list them as I am sure I’ll leave one out ;-)

Comment by Greg Murray — July 31, 2007

Leave a comment

You must be logged in to post a comment.