Summary: | [chameleon] "Viewer" type widget for fast, truly simple deployment | ||
---|---|---|---|
Product: | Chameleon | Reporter: | Dean Gadoury <dgadoury@dmsolutions.ca> |
Component: | Widget | Assignee: | chameleon-dev <chameleon-dev@lists.maptools.org> |
Status: | NEW | ||
Severity: | enhancement | ||
Priority: | P2 | ||
Version: | 1.99 | ||
Target Milestone: | FUTURE | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
There are probably several ways this could be done and probably several possible goals. I'll provide an ideal situation (which may or may not be possible) and an idea of a more achievable one. First of all, the idea is to allow application developers to use as few tags as possible, ideally only one, to deploy a simple mapping application. Users could supply the chameleon location, mapfile/context location and a few simple attributes like map size and the result would be a map with simple navigation. Some assumptions could be reasonably made, like there will be no keymap, scalebar or other advanced functions. The 'viewer' could include zoom in, out, pan, identify tools etc. - just enough to embed a navigable map in a web page. Perhaps a widget (or compound widget) could be written to do this. This widget would have to use default images for tool buttons, fonts and all other attributes. Ideally there would be no need for any shared resources. A first step could be to develop a 'viewer' widget that could be embedded in a regular HTML template. The HTML template would still need the regular required elements like the onload function and possibly a shared resource or two. The ideal situation would be that a user could just put in a line of code in their HTML page that would embed the chameleon application. The developer would put in something like an <embed> tag with the location of chameleon (local or service instance), the map file and a few attributes and that would be all that was required. If some form of this idea is actually feasible we would need to do a detailed requirements analysis to define how it could work and how the widget would be defined, i.e. what user inputs would be required.
Changed target to FUTURE.