43 | | By convention, the name of the file is ApplicationDefinition.xml. So, create a new file in the {{{hello}}} directory and name it ApplicationDefinition.xml. For our very simple example, we need an ApplicationDefinition tag with a Title tag, a !MapGroup tag, and a !WidgetSet tag to hold our four widgets (see the ApplicationDefinition page for a more complete description). Individual widgets are represented as Widget tags inside the WidgetSet tag where the actual widget is specified by the Type tag and the HTML element that the widget will be created in is specified by the Name tag. Our four widgets each have a specific Widget tag with several options, most of which are not required for this example. The resulting XML for Hello Sheboygan is: |
| 43 | By convention, the name of the file is ApplicationDefinition.xml. So, create a new file in the {{{hello}}} directory and name it ApplicationDefinition.xml. For our very simple example, we need an ApplicationDefinition tag with a Title tag, a [wiki:ApplicationDefinition/MapSet/MapGroup MapGroup] tag, and a [wiki:ApplicationDefinition/WidgetSet WidgetSet] tag to hold our four widgets (see the ApplicationDefinition page for a more complete description). Individual widgets are represented as [wiki:ApplicationDefinition/WidgetSet/Widget Widget] tags inside the [wiki:ApplicationDefinition/WidgetSet WidgetSet] tag where the actual [wiki:ApplicationDefinition/WidgetSet/Widget Widget] is specified by the Type tag and the HTML element that the [wiki:ApplicationDefinition/WidgetSet/Widget Widget] will be created in is specified by the Name tag. Our four widgets each have a specific [wiki:ApplicationDefinition/WidgetSet/Widget Widget] tag with several options, most of which are not required for this example. The resulting XML for Hello Sheboygan is: |
149 | | * the !JavaScript file associated with each identified Widget is loaded |
150 | | * any dependencies of the Widget are loaded |
151 | | * when all Widgets (and their dependencies such as CSS files) are loaded, a new instance of each Widget is created for each HTML element. |
152 | | * when all Widgets have been initialized, the {{{FUSION_INITIALIZED}}} event is emitted. |
153 | | |
154 | | An important step in this process is the loading of the Map Widget(s). After each Map Widget has been created, it: |
| 149 | * the !JavaScript file associated with each identified [wiki:ApplicationDefinition/WidgetSet/Widget Widget] is loaded |
| 150 | * any dependencies of the [wiki:ApplicationDefinition/WidgetSet/Widget Widget] are loaded |
| 151 | * when all [wiki:ApplicationDefinition/WidgetSet/Widget Widgets] (and their dependencies such as CSS files) are loaded, a new instance of each [wiki:ApplicationDefinition/WidgetSet/Widget Widget] is created for each HTML element. |
| 152 | * when all [wiki:ApplicationDefinition/WidgetSet/Widget Widget] have been initialized, the {{{FUSION_INITIALIZED}}} event is emitted. |
| 153 | |
| 154 | An important step in this process is the loading of the [wiki:ApplicationDefinition/WidgetSet/MapWidget MapWidget](s). After each [wiki:ApplicationDefinition/WidgetSet/MapWidget MapWidget] has been created, it: |
181 | | The Fusion !JavaScript API and widgets are installed with the !MapGuide Open Source Web Tier, but they are actually loaded up to and executed in the Client Tier. |
182 | | |
183 | | == !ApplicationDefinitions, HTML and Widgets == |
184 | | |
185 | | The API and widgets are linked to specific HTML elements within an HTML page through the !ApplicationDefinition XML document. A widget is the executable code (!JavaScript class) that is loaded when Fusion identifies an HTML element id and Widget Name that are the same. The Type of the Widget identifies the exact !JavaScript file to be loaded and the !JavaScript object that needs to be instantiated to create a functional widget. The runtime instance of the !JavaScript object is the widget. |
186 | | |
187 | | When the runtime instance is created, it uses the HTML element id to determine where in the HTML page it should display its user interface. Any custom configuration for the widget is placed in the ApplicationDefinition Widget XML block as sub tags (each widget has its own list of what customization is possible, see the Widget API Reference for details). |
188 | | |
189 | | If you are customizing the look and feel of a single widget by overriding the CSS styling for the widget, this is normally done by using the {{{#<id>}}} syntax to limit your changes to that specific widget. |
| 181 | The Fusion !JavaScript API and [wiki:ApplicationDefinition/WidgetSet/Widget Widget] are installed with the !MapGuide Open Source Web Tier, but they are actually loaded up to and executed in the Client Tier. |
| 182 | |
| 183 | == [wiki:ApplicationDefinition ApplicationDefinitions], HTML and [wiki:ApplicationDefinition/WidgetSet/Widget Widgets] == |
| 184 | |
| 185 | The API and [wiki:ApplicationDefinition/WidgetSet/Widget Widget] are linked to specific HTML elements within an HTML page through the !ApplicationDefinition XML document. A [wiki:ApplicationDefinition/WidgetSet/Widget Widget] is the executable code (!JavaScript class) that is loaded when Fusion identifies an HTML element id and [wiki:ApplicationDefinition/WidgetSet/Widget#Name Widget Name] that are the same. The Type of the [wiki:ApplicationDefinition/WidgetSet/Widget Widget] identifies the exact !JavaScript file to be loaded and the !JavaScript object that needs to be instantiated to create a functional [wiki:ApplicationDefinition/WidgetSet/Widget Widget]. The runtime instance of the !JavaScript object is the [wiki:ApplicationDefinition/WidgetSet/Widget Widget]. |
| 186 | |
| 187 | When the runtime instance is created, it uses the HTML element id to determine where in the HTML page it should display its user interface. Any custom configuration for the [wiki:ApplicationDefinition/WidgetSet/Widget Widget] is placed in the ApplicationDefinition [wiki:ApplicationDefinition/WidgetSet/Widget Widget] XML block as sub tags (each [wiki:ApplicationDefinition/WidgetSet/Widget Widget] has its own list of what customization is possible, see the Widget API Reference for details). |
| 188 | |
| 189 | If you are customizing the look and feel of a single [wiki:ApplicationDefinition/WidgetSet/Widget Widget] by overriding the CSS styling for the [wiki:ApplicationDefinition/WidgetSet/Widget Widget], this is normally done by using the {{{#<id>}}} syntax to limit your changes to that specific [wiki:ApplicationDefinition/WidgetSet/Widget Widget]. |
211 | | Widgets in Fusion also use and trigger events. Widgets are designed to be completely independent of one another, allowing them to be added to, or removed from, applications with little or no impact on the other widgets in the application. However, there are cases (especially with the Map widget) where it is important that widgets be able to communicate with other widgets or with the application as a whole. For these situations, there is an event mechanism built into Fusion that allows widgets, and applications built on Fusion, to register for and trigger events. The event mechanism allows widgets to be independent of each other, but still provide a high level of integration when required. |
212 | | |
213 | | To register a callback function for a widget event, the application must first obtain a reference to the widget through one of the methods of the Fusion object ({{{getWidgetById}}} typically) and then call {{{registerForEvent}}} passing one of the event IDs that is valid for that widget. |
| 211 | [wiki:ApplicationDefinition/WidgetSet/Widget Widgets] in Fusion also use and trigger events. [wiki:ApplicationDefinition/WidgetSet/Widget Widgets] are designed to be completely independent of one another, allowing them to be added to, or removed from, applications with little or no impact on the other [wiki:ApplicationDefinition/WidgetSet/Widget Widgets] in the application. However, there are cases (especially with the [wiki:ApplicationDefinition/WidgetSet/MapWidget MapWidget]) where it is important that [wiki:ApplicationDefinition/WidgetSet/Widget Widgets] be able to communicate with other [wiki:ApplicationDefinition/WidgetSet/Widget Widgets] or with the application as a whole. For these situations, there is an event mechanism built into Fusion that allows [wiki:ApplicationDefinition/WidgetSet/Widget Widgets], and applications built on Fusion, to register for and trigger events. The event mechanism allows [wiki:ApplicationDefinition/WidgetSet/Widget Widgets] to be independent of each other, but still provide a high level of integration when required. |
| 212 | |
| 213 | To register a callback function for a [wiki:ApplicationDefinition/WidgetSet/Widget Widget] event, the application must first obtain a reference to the [wiki:ApplicationDefinition/WidgetSet/Widget Widget] through one of the methods of the Fusion object ({{{getWidgetById}}} typically) and then call {{{registerForEvent}}} passing one of the event IDs that is valid for that [wiki:ApplicationDefinition/WidgetSet/Widget Widget]. |