- The user interface is not very customisable. You are stuck with the 3 column layout.
- There is a 1:1 relationship between the Web Layout (that defines the AJAX viewer interface) and the Map Definition. What this means is that you don't have the ability to switch between maps within the same AJAX viewer, without some server-side hackery with dynamically created Web Layouts.
- You cannot programmatically manipulate the state of user interface elements (eg. Enabling/Disabling toolbar buttons)
- It is hard to interface with the AJAX viewer from JavaScript. For example, to listen to a selection event in the AJAX viewer, you currently have to use ugly hacks, such as overriding the AJAX viewer methods with your own.
- It uses frames, which are absolutely evil
- Discrete separation of functionality and style.
- Flexible, free-form layout of user interface elements.
- Componentisation of application behaviour (via widgets)
- Styling of user interface elements via CSS.
Also, the widget-based approach allows a non-developer to quickly assemble a mapping application by choosing a Fusion template, and adding in the desired functionality via widgets. Fusion already comes bundled with lots of widgets covering many common functionalities and tasks (zoom, pan, buffer, measure, map switching, attribute browsing, and much more)
The architecture of the framework lends itself to clean separation of roles. Designers can focus on the design (templates), and developers can focus on the behaviour (widgets).
One of the (small) problems now with Fusion is the reliance on PHP to provide the required server-side behaviour for some of the Fusion widgets. Hopefully in the future, there will be complementary asp.net and java versions available.
As the title indicates, this will be the first of many posts I'll be writing about the Fusion Framework. Stay tuned.
No comments:
Post a Comment