Download the PDF document (for better readability here).
The challenge:
There are several architectural and feature differences in JavaScript and Java.
Java is statically typed where as JavaScript is dynamically typed.
Java does not support function references where as JavaScript supports.
As such, it becomes very difficult to support template-based widgets in DWT, as is the case in Dojo Widget System – Dijit.
Added to it, Google Web Toolkit (GWT) differentiates JavaScriptObject inherited types v/s other Object-inherited types. Though finally non-JavaScriptObject types are compiled to JavaScript types, the hosted-mode (emulation layer) fails to recognize “dynamic” properties and result in errors.
Proposed Solution:
Statically typed languages can be converted to dynamically typed language using collections like an array or a map (java.util.List and java.util.Map).
List provides an index-based access to the properties where as Map provides a name-based access.
As such, what I propose is the following:
- All properties would be stored in a combination of Map<String, Object>. This includes even simple items like the ID, widget-ID or other attributes. The key is the name of the property.
- All dojoAttachPoint-s would be stored in Map<String, Element>. The key is the name of the attach-point.
- All dojoAttachEvent-s would be stored in a slightly more elaborated Map<String, Map<String, List<EventListener>>>
Widget Properties:
All widget properties would be stored in a variable – say, properties – of the type Map<String, Object>.
It will contain all properties that are required for the working of the widgets. As such, the class will not contain any fields other than what is required to manage the system.
The Widget-inherited types may introduce custom fields as may be required.
Access to the values would be made available through the methods get(String) and set(String, Object)
Dojo Attach Point-s:
All attach points, as parsed from the templates, would be stored in a variable – say, attachPoints – of the type Map<String, List<Element>>.
The basic question – why should the value be List<Element> rather than Element? The answer lies in the file dijit/_Templated.js (part of Dojo distribution).
The following is the code snippet from the file (lines 144 – 149, version 1.1.1):
while((point = points.shift())){
if(dojo.isArray(this[point])){
this[point].push(baseNode);
}else{
this[point]=baseNode;
}
}
As such, I decided to make it a List<Element>.
The methods getAttachPoints(String), getAttachPoint(String) can be used access the attach-points programmatically.
Methods addAttachPoint, setAttachPoints, removeAttachPoint and removeAttachPoints may be used for further programmatic manipulation [1].
I propose to keep all the methods public unless there is a pressing reason against it.
Dojo Attach Event-s:
dojoAttachEvent-s is a trickier part since Java does not support method references. As such, dojoAttachEvent-s are not supported in the form as in Dojo.
A widget-author can use the following methods to register attach-events programmatically:
- registerAttachEvents(Map<String, Map<String, List(<EventListener>>)
- registerAttachEvents(Map<String, Map<int, List(<EventListener>>>)
- registerAttachEvents(Map<Element, Map<String, List(<EventListener>>>)
- registerAttachEvents(Map<Element, Map<int, List(<EventListener>>>)
- addAttachEvent(String, String, EventListener)
- addAttachEvent(Element, String, EventListener)
- addAttachEvent(String, int, EventListener)
- addAttachEvent(Element, int, EventListener)
The Map<String, Map<String, EventListener>> comprises of the main key as attach-point-name and the sub-key as the DOM-event-name or the ID (as defined by GWT).
registerAttachEvents is a protected method and would be called during the build-up process. addAttachEvent is a public method for further manipulation.
Overloaded methods removeAttachEvent can be used to remove the listeners [1].
The field – say, eventListeners – of type Map<String, Map<int, List<EventListener>>> would be used to manage all event listeners.
Widgets may publish helper methods, say for example, addClickListener for Button or addChangeListener for TextBox or simply addListener for the ease of the developer.
[1]: Not sure if it is really required.
Final Structure:
public class Widget
{
private Map<String, Object> properties;
public Object get(String name);
public set(String name, Object value);
}
public class TemplatedWidget extends Widget
{
private Map<String, List<Element>> attachPoints;
private Map<String, Map<int, List<EventListener>>> eventListeners;
public List<Element> getAttachPoints(String name);
public Element getAttachPoint(String name);
public void addAttachPoint(String name, Element element);
public void addAAttachPoints(String name, List<Element> elements);
protected void registerAttachEvents
(Map<String, Map<String, List(<EventListener>>);
protected void registerAttachEvents
(Map<String, Map<int, List(<EventListener>>);
protected void registerAttachEvents
(Map<Element, Map<String, List(<EventListener>>>);
protected void registerAttachEvents
(Map<Element, Map<int, List(<EventListener>>>);
public void addAttachEvent(String, String, EventListener);
public void addAttachEvent(String, int, EventListener);
public void addAttachEvent(Element, String, EventListener);
public void addAttachEvent(Element, int, EventListener);
public void removeAttachEvent(String, String, EventListener);
public void removeAttachEvent(String, int, EventListener);
public void removeAttachEvent(Element, String, EventListener);
public void removeAttachEvent(Element, int, EventListener);
}
Feedback:
The DWT team looks forward to your inputs – critics and suggestions on the approach.
Feel free to drop in a comment at http://dwt.sourceforge.net/blog or write a mail to dwt@edujini-labs.com or dwt-users@lists.sourceforge.net.
Mailing-list URL: http://sourceforge.net/mailarchive/forum.php?forum_name=dwt-users
