Skip to main content

Some questions regarding Jmaki

2 replies [Last post]
Joined: 2007-06-16


I am currently evaluating Jmaki as the widgeting framework for our website and had some questions. I searched the forum but didnt find satisfactory answers:

1) How do I create widgets on the client side i.e. on the fly as the user interacts with the website. I found injector API as one means of doing it , but that requires me to have a special service just to host the widgets and in that it loads the URL everytime. So if I have a jmaki widget which takes some config parameters and I need X instances of it when the user takes a particular action I have to hit the widget service X number of times. Is there another way of creating parameterized widgets on the fly ?

2) How do I define composite widgets i.e. widgets composed of smaller widgets (parent/child relationship ?) declaratively and crisply (like the template file or nested tags) rather then programmatically (injector API).

3) The postLoad() API in the widget doesnot work in Firefox. I specified a postLoad() method in my widget but it was not invoked. In the jmaki.js I found that loadWidget() API uses
(wimpl.postLoad == 'function' )

to check the existance of postLoad() method, shoudnt it be
(typeof wimpl.postLoad == 'function') ?

I really liked the concept of jmaki and best part being it does what a widgeting framework is suppose to do.

-- oosiris

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-07-31

Hi oosiris

It's nice to see that you are digging deep into the guts of jMaki. Here are some answers to your questions.

1) Widgets can be created on the fly and as you can see with the Injector (the API) and the DContainer (short for dynamic container which uses the injector) you can do most of what you want.

If you look at the Injector code you will see that it dynamically adds widgets at runtime by default. jMaki was designed to do this from the start though there are a couple of catches.

a) Some widgets like the Google Maps, Dojo Editor, and Google Ajax expect that their includes be written out when the page was initially written. This is done using a document.write which if called after your page onload event has fired will cause the page to go blank. You will notice we flag all widgets that can not be dynamically loaded and we use a jmaki function addLibrary which will prevent these types of things from happening. There is a way around this by adding an iframe : true property to the jmaki.DContainer. Basically a new JavaScript context will be created for that widget but the good news is the publish/subscribe bus spans iframes. So even if you have an iframe inside of another widget or in the page and it has a jmaki widget you can get the events. This will make more sense when I explain your 2nd question.

b) If you dynamically create widgets you will need to have a div in the page where the widget gets loaded into. This is pretty easy to do dynamically.

2) We have spent a lot of time considering what to do with composition and we have decided the best way to do this is via URLs that generate the included content. This design is consistent across all jMaki widgets. Examples of this include tab views, accordions, the dojo drawer, and the DContainer Widget. All of these widgets use the jmaki.DContainer API (not to be mistaken with the widget that is simply implements the API). The beauty of the jmaki.DContainer API is it handles resizing, loading, and can be switched to be an iframe.

Now we have been exploring specific JSF widgets that do the parent child relationships using tags. This works great if you have JSF but you also need to remember we have PHP, Phobos and Ruby implementations that are not tag based which makes parent child relationships difficult.

One of the other things I've been mulling over is to enable widget composition at the template level as you had suggested. I am really concerned about the potential performance implications as parsing HTML on the client can be really slow if you have too much composition.

If you have any thoughts on this I'd be more than happy to get some discussions started with the team.

3) Post load should be using typeof (I didn't catch that and will fix it right away). Great catch.

The interesting thing about jMaki was it was really meant to be a simple widget model and we found you can do alot using all the different toolkits out there.

We'd be more than happy to have you get more involved. If your interested please let me know gmurray71 at

jMaki Lead

Joined: 2007-06-17


I have a follow-up question regarding composition of widgets. In my use case I'm supposed to search for some information, and the result need the following composition of widgets:

View modes: * Tree structure * Map * Image
- tabbedview
- - tab1
- - - Tree
- - - Map
- - - Some other information shown as image
- - tab2
- - - Tree
- - - Map
- - - Some other information shown as image
- - tabX
- - - Tree
- - - Map
- - - Some other information shown as image

Each search result is supposed to show up in a new tab in the tabbed view, and the result can be shown in three different ways; either as a tree structure, in a map or as an image. When the user click on a tab, the tree view is shown as default, but by clicking on links above the tabbed view, he can change what's shown on the tab to be either the Map, the image or the tree structure.

The way the map and the image is generated is another issue, but what my initial problem is how I can generate each new tab in the tabbed view and how I can change the content of the tab to be either a tree widget, a map widget or a plain panel with an image on.

Could you provide either an example or some hints on how I can do this widget composition?

The way I want the widgets to work is similar to what google analytics does when showing results, each result in a tab and several ways of viewing it by selecting view modes by clicking links above the tabs. I can provide you with an image of it if you don't understand what I'm looking for.