Announcing: MapGuide Maestro 6.0m10 and a new build of Fusion

This announcement is a double-whammy because they are both somewhat intertwined.

Firstly, we'll start with a new build of Fusion that cleans up several aspects of the viewer framework. These changes in Fusion are slated for inclusion in a future release of MapGuide

New PHP entry point for fusion templates

This new build of Fusion introduces a new PHP entry point for the 5 fusion templates.

Instead of loading say ... the slate template like so:

http://servername/mapguide/fusion/templates/mapguide/slate/index.html

You can now load it like so:

http://servername/mapguide/fusion/templates/mapguide/index.php?template=slate

This entry point supports all the same query string parameters as the original templates but with support for the following additional parameters:

• template (required) - The name of the template to load 
• debug (optional) - If set to 1, the entry point will use fusion.js instead of fusionSF-compressed.js, making the whole debug/development process way more simpler.

The entry point also fetches the application definition and writes it out to the underlying template as JSON, avoiding the need for the initial round trip to fetch this document among other things.


Fixing external base layer support 

The way external base layers are currently supported in Fusion is a bit crufty which this build also addresses:

• Fusion no longer attempts to append script tags to support Google Maps / Bing / OSM / Stamen. The way we do it is unsafe according to modern browsers. That is now the responsibility of the new entry point.
• For Bing / OSM / Stamen, we no longer load external helper scripts at all. This is because such support is already present in OpenLayers itself and the external scripts are merely convenience wrappers that we can easily implement ourselves in Fusion.
• Finally, XYZ layers are now properly supported in Fusion. This means you can do things like consuming OSM tiles from your own OSM tile server, or maybe use non-watermarked CycleMap/TransportMap layers, or you can finally be able to consume your own MapGuide XYZ Tile Set Definitions.

Now the reason this announcement is a double-header is because these changes in Fusion really needs tooling assistance to best take advantage of these changes, so here's also a new release of MapGuide Maestro as well. Here's the notable changes.

Fusion XYZ layer editor support

Now that we have proper XYZ tile layer support in Fusion we now have support for consuming external XYZ tile sets.

 
Because MapGuide XYZ Tile Sets Definitions can now be consumable with Fusion, you can specify a tile set URL for such a Tile Set Definition by clicking the new Add from XYZ Tile Set Definition toolbar button.

If you want to consume OSM tiles from your own OSM tile server you can use this editor and point it to your OSM tile server with the requisite ${x}, ${y} and ${z} placeholders.

RtMapInspector tool improvements 

The other major feature of this new release is improvements to the RtMapInspector.

For a refresher, the RtMapInspector tool was introduced way back in a beta release of Maestro 5.0 and the purpose of this tool was to easily inspect the state of any runtime map if you know its session id and map name so you can easily debug map manipulation and state updates. Did your MapGuide application code correctly added your new layer? You can use this tool to inspect the map state and find out.

Having looked at this tool more recently, I've come to realise that I'm only skimming the surface of what this tool is capable of and with this release, the capabilities have been significantly expanded.

For example, the tool now lets you see the map image for the current map state

But it also occurred to me if we're inspecting a map, we can (and should be able to) also inspect its layers (and their feature sources) too! So when you select any layer in this tool, a new Inspect Layer button is enabled.

Clicking it will bring up an inspection dialog that shows the layer's XML and be able to interact with its feature source using the same components as the local feature source preview.

Other Changes

• Now requires .net Framework 4.7.1. The windows installer will check for this (and install if required)
• Maestro API now uses the latest stable releases of NetTopologySuite and GeoAPI
• The MgTileSeeder tool now targets .net Core 2.1

Download MapGuide Maestro
Download test build of Fusion

Using Bing Maps? Here's some new builds of Fusion.

I gave out the warning last month, and just in time before Microsoft pulls the plug on the Bing Maps legacy controls and services on June 30th 2017, here's some new builds of Fusion with support for the current iteration of Bing Maps.

The current iteration of Bing Maps now requires an API key, so if you don't have one you can signup for one at the bing maps portal.

I don't normally put out releases of Fusion like this. I'd normally would just roll it into a new point release of MapGuide Open Source, but I'm currently not in a suitable position at the moment to put out new builds of MapGuide, so this will have to suffice.

Download Fusion for your particular version of MapGuide here:

Fusion for MGOS 2.6

Fusion for MGOS 3.0

Fusion for MGOS 3.1

To install, just extract the zip file contents to the www directory of your MapGuide installation. Be sure to back up or remove the existing fusion directory before doing this.

Now, having not put out a new release of MapGuide for a while, there are also plenty of fixes and minor enhancements made to these respective branches of Fusion since the version bundled with their respective released version of MapGuide. You can check out the changelogs for these respective branches here:

Fusion for MGOS 2.6 Changelog

Fusion for MGOS 3.0 Changelog

Fusion for MGOS 3.1 Changelog

So you've got your Bing Maps API key, where in the Application Definition do you put this key in?

Maybe you want to check out the next post.

MapGuide tidbits: Fusion and Bing Maps

If you use Fusion with Bing Maps, you should start applying for an API key because on June 30th, 2017, the legacy Bing Maps controls (ie. The ones that don't require an API key) will shut down.

I gather Autodesk have already taken care of this problem for their next release of AIMS, but for the rest, I'll make sure that this is backported to older Fusion branches before the June 30th deadline.

And also to make sure that Maestro has the updated Fusion Editor UI to match.

React-ing to the need for a modern MapGuide viewer (Part 6): Emulating the Aqua fusion template

After announcing mapguide-react-layout to the public, the next major task was to bring the viewer up to parity with Fusion by:

• Supporting the ability to load a viewer from an Application Definition document
• Porting across the 5 existing Fusion templates to our equivalent layout components

The first part was actually pretty simple. The Application Definition schema is actually simpler to model than the Web Layout one (due to the heavy emphasis on key-value pairs, which is why the schema is still at v1.0.0, the key-value pair mechanism allows for arbitrary extension to support new features). It was a case of mapping the loaded Application Definition to the common initialization structure that the Web Layout currently maps to.

Though we didn't have any of the 5 templates ported at this point, we could throw an Application Definition at the "ajax-viewer" template and it is able to understand a majority of the widgets, with the exception of toolbars, because toolbars are uniquely named for each Fusion template and the Application Definition is expected to be referencing the template-specific toolbars.

So at this point, it was now a case of porting across the 5 templates. As we currently lack an accordion or tab component, the logical place to start is the Aqua template, which uses neither.

We start off with the existing "ajax-viewer" template, re-arrange the layouts of the various toolbars/menus and using our modal dialogs to house the Task Pane, Legend, etc, and taking advantage of widespread modern browser support for CSS gradients and we get ...

Let's compare that to the original

What do you reckon? I think it's a good visual emulation of the original.

And here's an extra added bonus. Currently, the toolbars (in any layout component) do not handle overflowing toolbar items at all. It turns out that applying a standard CSS overflow:auto on the toolbar container element gives us a very usable solution:

I've decided to activate this for toolbars with horizontal orientation only, as this trick doesn't work very nicely on toolbars with vertical orientation and I am going on the assumption that one wouldn't pack a vertically oriented toolbar with too many items.

Unfortunately, the process of porting across the Aqua template has revealed some teething issues.

1. Task Pane / Selection Panel / Legend does not play nice with Modal Dialogs

All the work in making these components full height presents issues when housed within our modal dialogs. For example, here's what the selection panel looks like

It completely overwrites the container for the modal dialog, so we can't hide the dialog or drag it around. The Task Pane has the same problem.

2. We sort of need InvokeScript support as that is what the original templates use to show the Task Pane / Selection Panel / Legend / etc. 

Failing that, we probably have to hard-code this toggling functionality into the layout component.

3. Flyout menus don't play nice either

See that scrollbar? The flyout menu is overflowing inside the toolbar container! I hope the react-flyout component we're using allows us to break out of parent-child element relationships for a flyout menu and its toggling button, otherwise we'd have to look at an alternative.


Once these problems are solved. That's when I think I'll put out a new release.

MapGuide 3.0 feature showcase: Stamen tiles

With MapGuide Open Source 3.0, we've expanded the set of available external base layers in Fusion with support for Stamen tiles.

Stamen tiles provides stylish cartographic renderings of OpenStreetMap data in 3 different styles:

Toner

Watercolor

Terrain

You can specify these new external layer types in your Application Definition. The latest M4 release of Maestro 6.0 already supports these new layer types.

Which gives your Fusion applications extra base layers for real-world context.

Other new things (or things I forgot to talk about) in Fusion for MapGuide 2.6

This post has been stuck in my draft queue for several months now. I guess I forgot about this post so some of the content in this post may have already been talked about. Still, there some content here that I'm certain hasn't been talked about, and since I currently don't have idea at the moment what has and hasn't been talked about, I've decided to just publish the whole post.

So here's some new features (or features I've probably already talked about) in Fusion for MapGuide Open Source 2.6

OpenLayers updated to 2.13.1

OpenLayers in Fusion has been updated to the latest stable release, which is 2.13.1. This gives us important fixes for tiled layers in IE10, among other fixes and improvements from the 2.12 release.

Short of a few specific customizations to the Google layer (to disable tilt at lower levels), you'll be glad to hear that the OpenLayers included with Fusion is now mostly vanilla with very few modifications. Making your own custom OpenLayers build should be a painless affair.

Built with Closure

fusionSF-compressed.js is now built with the Google Closure Compiler.

Besides giving us a 50kb reduction in file size over YUI compressor with default settings, building through Closure gives us Source Map support for modern browsers.

What this means is you can now debug and step through fusionSF-compressed.js in its uncompressed form with full comments without having to modify the template files to switch to a debug version of Fusion. Current versions of Chrome and Firefox both support source maps in their respective developer tools.

With advanced optimizations, fusionSF-compressed.js file size can be reduced by up to 500kb! Unfortunately, building with closure's advanced optimizations may actually alter application behaviour and requires a thorough audit of the code in Fusion first before we can determine if it is safe for us to flick the switch. So for now, we build with default settings.

Delayed refresh on layer/group toggle in legend

When you toggle a layer or group on/off in the legend, it triggers a map refresh. If you do this on multiple layers/groups in quick succession, it's going to fire off that many refresh requests. Not very efficient.

For this release, we've added support for a new DrawDelay extension property in the Map element of the MapGroup. Setting this property will cause any toggle in the legend to delay the refresh for that amount of time (in ms).

Having this property set will allow you to toggle multiple layers/groups in the legend in quick succession, but only trigger a single refresh request at the end as long as each individual toggle falls within the delay period. This feature is opt-in. By default, the delay is 0 which means legend widget will behave like before where each toggle triggers a refresh immediately.

More QuickPlot tweaks

The legal disclaimer is now a configurable element

Of course, you may want this element to be mandatory, so we've added a new AllowDisclaimerToggle extension property that determines whether this checkbox will be shown.

In addition, you can configure the initial checked state of these elements through the following new extension properties:

• ShowLegend
• ShowNorthArrow
• ShowCoordinates
• ShowScaleBar
• ShowLegalDisclaimer (does nothing if there is no legal disclaimer attached or AllowDisclaimerToggle = false)

Announcing: mapguide-rest 0.8

Here's a new release of mapguide-rest.

The main feature is the support for XYZ image and vector tiles. This feature is HIGHLY EXPERIMENTAL and should not be used for production purposes unless your own internal testing has given you enough confidence to use this feature in a production setting.

Check the release notes for other changes

Download

Better Fusion errors

So I'm currently hacking on Fusion to make it try and give us errors (if any occur) that actually mean something instead of a wall-of-gibberish that's alert()'ed out.

Now this is an error in Fusion that actually contains useful information!

And if you're wondering how useful that above error was, it told me that the CreateSession.php helper script had some syntactical compatibility issues for PHP 5.5, something that obviously slipped under the radar when I was upgrading PHP and assorted PHP code for the next release of MapGuide Open Source.

So in the process of building this feature, it immediately went straight to work and caught some server-side problem that would've taken several debug cycles to dig out. And I didn't even have to break into Firebug/Developer Tools to get this information! I'm loving the taste of this dogfood already!

MapGuide 2.6 feature showcase: Fusion

Since the 2.6 preview release bundles a trunk build of Fusion, I might as well cover what's new in Fusion in addition to a whole bunch of bug fixes and minor improvements.

OpenLayers upgraded to 2.12

OpenLayers has been upgraded to the 2.12 release. This gives Fusion plenty of new toys to play with.

• Client-zoom. If you have a Map Definition with an OpenStreetMap backdrop, the OpenStreetMap tiles will stretch appropriately if you zoom to an unsupported OSM scale

• Improved touch support for mobile devices. Try viewing your Fusion layout on an iOS or Android device. Not that we're going to officially support Fusion for mobile devices (my recommendation is to still build a dedicated viewer or use an existing mobile-optimized viewer for mobile devices), but you might be surprised to find that the Fusion is quite serviceable on tablets/phones due to the improvements provided by OpenLayers 2.12.
• Cleaner custom build experience. As a result of the OpenLayers upgrade, we've also took the opportunity to restructure how we keep OpenLayers under version control. Now we also keep any customizations to OpenLayers under a separate directory so that creating your own custom build of OpenLayers for Fusion is a case of extracting the 2.12 release to a temp directory, overlaying our modified files on top and then building a new OpenLayers.js which can then be incorporated into the Fusion installation

Time/resources permitting, we may look to bump this to the latest stable (2.13.1)

New Geolocation widget

The Geolocation widget taps into the new HTML5 geolocation API allowing you to pan (and optionally zoom) to your current position on the map.

Of course, the utility of this widget is somewhat diminished if you (the user) are nowhere physically within the area of the map you're looking at (like myself, based in Melbourne, Australia looking at a map of Sheboygan, Wisconsin, USA). The widget will warn you if your physical location is outside the bounds of the map.

New Coordinate Tracker widget

The Coordinate Tracker widget allows you to view your current mouse coordinates in various different coordinate systems.

Unlike MapGuide, we're leveraging Proj4js to do these transformations (because CS-Map is not available for us to use in JavaScript), and we also keep a pretty big list of coordinate systems that are convertible between CS-Map and proj4 to ensure maximum compatibility of most coordinate systems.

Improved Load/Selection performance

If you're working with a version of MapGuide that supports the new CREATERUNTIMEMAP and QUERYMAPFEATURES operations (ie. The 2.6 Preview Release), you should see improvements in map loading and selection. For large maps, you should see significant loading improvements.

Otherwise we stick to the existing set of PHP web tier glue for doing map loading/selection.

Redline Enhancements

The Redline widget also sees continued improvements

Firstly, the redline widget now supports Advanced Stylization. In terms of what you see on the map, it shouldn't be much different visually from Basic Stylization except that labels you include with drawn redline objects will always be visible regardless of scale. Previously, under Basic Stylization feature labels were subjected to "MapGuide knows best" label placement which is not a good thing to have when you've made some notes on the map and you can't see the actual notes!

The lines actually have labels too, but "MapGuide knows best" label placement has determined that it can't find a suitable place to draw a label. Point styles under basic stylization had an option to override this behaviour, to always draw the label regardless. Unfortunately, line or area styles do not have an equivalent setting.

Moving to Advanced Stylization gives us this capability for all geometry style types.

As you can see, all the labels are now visible even if not packed nicely. But at least this way, you know for certain visually whether a redline feature has labels or not.

But this is not to say we've removed basic stylization support. You can choose what type of stylization to use through the new StylizationType widget extension property.

Secondly, we've continued to improve the user workflow and continue to reduce the amount of setup steps a user needs to take. You can now specify the desired redline data store format and geometry types upfront as widget extension properties. Having these properties set turns the main redline from this

To this

No need for the user to have to choose (he/she probably has no clue). Just click the big button to start.

Thirdly, we've improved the redline editing process. The redline list box is now multi-selectable, meaning you can now select/delete/edit text of multiple redline objects at once instead of doing it one-by-one

QuickPlot Enhancements

The QuickPlot widget now supports legends. The legend is produced through the existing GETMAPLEGENDIMAGE operation.

Also the QuickPlot UI lets you configure which elements you want to show in the final PDF plot.

Try it now

If you can't install the MapGuide 2.6 preview release, we've made available a trunk snapshot of Fusion for you to download and try out.

• Download zip or tarball release
• Download build tools to allow you to rebuild a new fusionSF-compressed.js from a fusion installation

Just extract the zip or tarball to the www directory of your MapGuide web tier installation. If you want a side-by-side install without replacing the current Fusion, just rename one of the fusion directories and change the "fusion" in your viewer URL to this renamed directory as well.

This snapshot includes the 5 MapGuide templates and is newer than the Fusion that is bundled with the MapGuide 2.6 preview release.

MapGuide Open Source 2.4.1 and newer are the versions of MapGuide that will work with this release. Versions older than 2.4.1 are un-tested and aren't guaranteed to work.

Changing the default redline style in Fusion

So as you know, we've vastly streamlined the Fusion redlining widget so you don't have to wade through so many pages of setup in order to start drawing lines and squiggles.

You might also be aware that all redlines drawn will have the same style applied to them, and if you want to change this, you have to go back to the Redline Management page to edit the layer style for that redline layer.

You might also be wondering if we can change this default style so the above doesn't have be done for every redline layer you create. Yes you can. Here's how.

From the root directory of your Fusion installation. Open defaultstyle.php under the widgets\Redline\classes directory.

This file defines the default layer style settings to use when creating a new redline layer on the map.

Edit the values in this file to suit your desired default style. Save the file, reload the viewer and the Redline widget will be using your new values.

MapGuide tidbits: OpenLayers in relation to Fusion

I'd had been holding off on this particular post for quite some time because what is written below wasn't exactly true or applicable until MapGuide RFC 132 was implemented. Now that the RFC is completed, the time to publish this post is more suitable.

As some of you know, Fusion is built on top of the powerful OpenLayers library.

But what you may not know (and probably want to know) are the specifics.

What version of OpenLayers?

Believe it or not, I myself do not know what version of OpenLayers is currently bundled with the Fusion that comes with MapGuide Open Source 2.5 (or older releases). Our bundled copy in Fusion has the release version number scrubbed out by SVN making it hard to determine the actual version number.

I strongly believe it is OpenLayers 2.10 due to the lack of touch event support.

For the next release of MapGuide Open Source (2.6) the answer will be crystal clear: Fusion will be using OpenLayers 2.12. What OpenLayers 2.12 brings to the table for Fusion will be the topic of another post.

What OpenLayers build profile?

As some of you may know, OpenLayers is not a monolithic library. It can be customized with various build profiles to include/exclude certain parts of the OpenLayers library. What that means in practice is that some parts of the OpenLayers API may not be available to be used in Fusion because we use our own custom build profile for OpenLayers. Our custom build profile is defined in fusion.cfg, there you can see what parts of the OpenLayers API we've included and what parts we've excluded.

Now sadly, the way OpenLayers is set up within the fusion source tree (before RFC 132) is that we are keeping in a "built" version of OpenLayers.js and have customizations done on that one file. This makes customizing your own OpenLayers build for use with Fusion much more harder as our current audit trail of Fusion-specific customizations is very hard to track. This means that customizing your own OpenLayers for Fusion may not be as simple as:

1. Download the OpenLayers zip/tarball
2. Build it with your desired build profile
3. Overwrite Fusion's OpenLayers.js with your built copy.

For the Fusion that will come MapGuide Open Source 2.6, this will be much more clearer. We'll be reserving a section of the Fusion repo, for Fusion-specific customizations to individual js files in OpenLayers such that customizing your own OpenLayers becomes:

1. Download the OpenLayers 2.12 zip/tarball
2. Overlay the directory (where you unzip/untared) with our Fusion-specific modified files
3. Build OpenLayers with your desired build profile
4. Overwrite Fusion's OpenLayers.js with your built copy
5. Re-build and re-minify Fusion with your custom OpenLayers.

This way, the OpenLayers build you customize will retain our Fusion-specific changes where necessary, and allows you to tap into parts of OpenLayers that we may have excluded from our custom build.

MapGuide Open Source 2.5 released

Here it is! The final release of MapGuide Open Source 2.5.

Download

This final release includes the following changes from RC2

Fusion

We landed in a big changeset which should put this whole saga of conflicting widgets behind us:

• Quick Plot, Select Radius and Select Polygon widgets are no longer mutually-exclusive widgets. For Select Radius/Polygon this means they are now "click once to select once" affairs. If you need to re-select, just re-click the menu/toolbar item.
• All digitizer actions now raise a new MAP_DIGITIZER_ACTIVATED event when digitization begins and raise a new MAP_DIGITIZER_DEACTIVATED event when digitization stops. All widgets that would require the user to draw a geometric shape will raise these events
• The maptip, pan and zoom widgets will disable/restore themselves on these digitizer events to prevent them for interfering with you drawing your geometry. You can still mouse wheel zoom while digitizing, panning while digitizing is not possible. Ideally, we'd like to still pan around while digitizing with the middle mouse button, but the mouse button is hard-coded in OpenLayers :( Something that's nice to address in the future.
• Fix the z-index on the Scalebar widget which caused it to be drawn *below* the map viewer.
• Small UI tweaks on the FeatureInfo/Query/Redline widgets
• All digitization prompts now have a cancellation link attached just in case the manual button (eg. Measure) or ESC key cancellation method is not available

Other changes

• MgException::GetDetails() now includes the stack trace information as per API documentation.
• MgFeatureService::UpdateFeatures() should now behave correctly in non-transactional mode. This API should finally behave as described in the API documentation and my dedicated post to it.

What's next?

I've been trying to push for faster release cycles (I think we can all agree 2.4 to 2.5 has been much faster than 2.2 to 2.4), but realistically I don't think we will see a 2.6 release until early 2014 at the most.

This is because MapGuide is strongly tied to FDO and unlike MapGuide, I don't have much influence with FDO's release cycle. I don't really want to put out new releases of MapGuide that use a trunk build of FDO unless they're preview releases. I cannot consider starting a release cycle for 2.6 until the next FDO at least hits beta and since history has shown that new binary releases of FDO happen around December-April, we should try to adjust the MapGuide release cycle to be in sync with FDO as much as we can.

This isn't necessarily a bad thing. As it means we have plenty of time in the interim to land in this backlog of new features that couldn't make it into 2.5 and flesh out some sandboxed work into fully working new features that can realistically land in 2.6.

So I guess what that means realistically is that in terms of any future MapGuide releases this year, you'll probably only be seeing 2.5.x point releases and maybe the occasional 2.6 preview release as a "snapshot" of what's happening for 2.6. 2.6 proper probably won't happen until 2014 ticks over.

Announcing: MapGuide Open Source 2.5 RC2

I was wrong.

I thought we would only need one RC before pumping out the final release, but the amount of fixes, polish and shine that's been done to Fusion since RC1 is such that a second RC is warranted.

The changes from RC1 are mostly Fusion-centric, and it's a big list.

Templates

We've fixed up some annoyances that are present in the 5 templates that come with MapGuide

Toolbar text on the TurquoiseYellow is much more legible. Black text on a black gradient toolbar did not scream readability

The templates also had various behavioural fixes to improve the user experience:

• The sidebar of the LimeGold template could not be expanded once it was collapsed
• For templates with collapsible sidebars, they will re-expand the sidebar if the user invokes any of the (Show Legend/Overview/TaskPane/SelectionPanel) menu items, or a widget has loaded content into the Task Pane.

Greater Widget Autonomy

Some widgets were treated as mutually exclusive widgets. That meant, if you invoke this widget, it became the active widget. These widgets had no business hijacking the active widget state and brought unnecessary confusion to the user experience. The widgets in question are:

• Redline
• Buffer
• Feature Information
• Measure
• Query
• Theme

These widgets all load their UIs into either the Task Pane or a popup window. As long as you can see their UIs, they should be considered active. These widgets are pretty much like Invoke URL widgets anyway: Self-managed and independent of the active widget state. 

Having their UIs open should not interfere with panning/zooming/selecting/etc. The above widgets have been modified to no longer take over or care about active state. In addition certain widgets on that list have been modified to be more self-contained, which are detailed below.

Redline

The Redline widget hasn't changed much since the last time I wrote about it. However, we did discover afterwards that SHP-based import/export was broken on Linux due to missing ZipArchive support in its bundled PHP. That has been fixed.

Measure

This widget was a prime offender in bad user interactions, the offence being leaving dangling digitizers behind. You could be panning or zooming, and it would still be measuring because the digitizers weren't deactivated and/or properly cleaned up. Other widgets on that list above shared some of the same problems with this widget, but the Measure widget was the worst of them all.

We've changed this widget in the following ways to ensure such a thing doesn't happen again.

The widget still auto-initiates measurement, but we've added manual controls to the UI to stop/start this process.

In addition, we've added an abort link to the information bar in case the Measure UI is easily hidden or obscured (eg. In the Aqua template)

Feature Information

The layers dropdown now has a refresh link, so you don't have to re-invoke the widget to refresh this list.

Query

To be consistent with every other widget that uses a digitizer, the digitizing actions in this widget now use the Information Bar to provide digitization prompts.

The widget also cleans up any active digitizers when unloaded. Part of the greater widget autonomy and self-management that I mentioned above.

Legend

The legend widget now properly displays layer nodes above the group nodes at any level in the tree, thus syncing up with the AJAX viewer and presenting the exact visual representation of your layer/group structure as shown in Maestro's Map Definition editor

Scalebar

We have a scalebar widget? Yes we did, it just didn't work until now. What you saw here is the functional scalebar widget.

ScalebarDual

We have this widget too? Yes we did. This is basically a wrapper around the OpenLayers.Control.ScaleLine control. You couldn't access and include this widget with your Flexible Layouts because it didn't have a widgetinfo XML file.

CTRLClick

This widget doesn't actually exist (hasn't for a long time), but its widgetinfo XML file was still there, thus having Maestro give you the false impression that this widget actually exists and can be added to your Flexible Layouts. Well this is definitely not the case, and the widgetinfo XML file has been removed meaning Maestro will no longer show this widget.

Center Selection

Here's another broken widget that's been fixed for this release.

Selection Panel

Did you know this widget is actually configurable with extension properties? Yeah, we didn't document them in the widgetinfo XML, that's why Maestro shows nothing for this widget. That's fixed now.

Did you also know this widget has a horizontal representation as well? Yeah, that was broken too, but fixed for this release as well.

Non-Fusion Miscellany

For this release, we've also officially deprecated Mapping Service APIs related to eMap DWF functionality. The front-end DWF map viewer was deprecated a long time ago, but nothing was official in terms of API documentation about the Web APIs that supported this viewer. Thanks to our SWIG enhancement work, you'll get nice C#/Java compiler warnings when using these APIs. 

We're doing this because eMap functionality support has been long since removed from the DWF Toolkit and MapGuide is still currently hamstrung on a super-ancient version of the DWF Toolkit due to the need to support eMap, which could also present interoperability problems with newer versions of AutoCAD and its verticals (that would be using newer versions of the DWF Toolkit). I've seen several DWF files plotted from MapGuide crash recent versions of Autodesk Design Review probably due to this reason.

Being stuck on an old DWF Toolkit was also one of the roadblocks in my failed 64-bit Linux experiment. And you know why MapGuide still doesn't support DWFX files? Same reason.

Not saying that this is what we're definitely going to be doing with a new DWF Toolkit, but it clearly shows what's stopping us from doing so (eMap support). So if we ever do upgrade our DWF Toolkit, we should at least give a one release-cycle warning. If you happen to still be using the DWF-based map viewer and/or the supporting Web APIs, this is your final boarding call to either migrate or seek alternative solutions.

I'm pencilling in a final release of 2.5 one week from now. What you see in this release will be pretty much be what's in the final release. Any issues filed against this release will be shelved to 2.5.1 or 2.6 unless those issues are of the really show-stopping nature.

Download

MapGuide tidbits: Fusion/AJAX Viewer similarities and differences

Disclaimer: Some of the Fusion examples here use a testing build of Fusion made after the release of MapGuide Open Source 2.5 RC1 and as such may not be reproducible on that and earlier releases of Fusion.

For this post, we're going to focus on the differences between the AJAX and Fusion viewers and their similarities.

Similarities

On a conceptual level, there are actually many similarities between the AJAX Viewer and Fusion.

• Both have a way of defining a discrete piece of application functionality. Fusion has Widgets. AJAX Viewer has Commands
• Both have to be defined within a master collection of functionality (WidgetSet in a Fusion Flexible Layout, CommandSet in a AJAX Viewer Web Layout)
• UI References to these widgets are defined in the viewer's menus and toolbars (Abstracted in Fusion Flexible Layouts as "containers". Menus and Toolbars are fixed in the AJAX Viewer Web Layout)
• Both Flexible and Web Layouts need a Map Definition specified, which all the Widgets/Commands will be interacting with.

These conceptual similarities are reflected in the similar editor workflows in Maestro.

Specifying a Map (AJAX Viewer)

Specifying a Map (Fusion)

Defining the master set of functionality (AJAX Viewer)

Defining the master set of functionality (Fusion)

Laying out menu/toolbar access to this functionality (AJAX Viewer)

Laying out menu/toolbar access to this functionality (Fusion)

This is where the similarities end

Differences (especially on widgets)

Each AJAX Viewer command type is unique with their own specialized set of configuration parameters (ie. Each command type is its own specialized XML data type in the Web Layout XML schema)

Each Fusion widget is unique, but is driven through arbitrary XML elements under the widget's "Extension" XML element. The valid XML content that can reside under the widget extension is defined by the widget's respective widgetinfo XML. Here's an example widgetinfo for the Task Pane widget. This widgetinfo XML is how Maestro is able to not only build the default XML for that widget, but also provide additional information/description about each Extension Property for that widget.

It is this arbitrary XML configuration nature of Fusion widgets that allows the ApplicationDefinition XML schema to stay the same (since the introduction of Fusion in MapGuide Open Source 2.0) and allows for individual widgets to be improved upon with additional features and properties without needing to do endless XML schema revisions (as is the case with the AJAX Viewer Web Layout)

Widget Types

In Fusion there is are two separate types of widgets

1. Dockable widgets
2. Non-dockable widgets

(NOTE: I'm not sure about the official terminology here, but this is the lingo I'm using for the Fusion Editor UI changes you'll see in the next release of Maestro 5.0, some of which I'm also previewing in this post)

Dockable widgets are widgets that can be housed within a Fusion "container" (ie. A menu or toolbar)

Non-dockable widgets cannot be docked within a Fusion "container". The Legend and TaskPane widgets are examples of such widgets.

The layout of such non-dockable widgets is generally handled by Fusion and its template. If such a widget is included in the Flexible Layout, Fusion will render the widget UI into the DOM element of the template with the same id. For the 5 templates that come with MapGuide, all the necessary DOM elements are set up for such widgets to be rendered into, so you generally do not have to concern yourself with such plumbing details.

The only time you need to be concerned with such details is:

1. You are creating your own Fusion template
2. You are using a non-standard non-dockable widget.

If you are creating your own Fusion template, you need to make sure that either declaratively or programmatically that your template provides a DOM element whose id matches the type of non-dockable widget that Fusion could render into. I won't go too much into this detailed topic, because this would most likely have to be a subject of a separate post.

If you are using a non-standard non-dockable widget (eg. Scalebar), it won't show if the template does not provide a DOM element with a matching ID, which is probably the case with the 5 standard templates. I'll show to get such widgets working later in this post.

Now the reason I want to emphasize this distinction between dockable and non-dockable widgets is because as of the latest beta of MapGuide Maestro 5.0, the Fusion editor failed to make this distinction, meaning it was possible to do illegal things like this:

And then have your Fusion template break down for the most cryptic of reasons. So we've fixed this up 2 ways.

Firstly, when you add a widget to a container, non-dockable widgets are filtered out, making it impossible to cause scenarios like the one above.

Secondly, we've tweaked the Widget Management dialog to show you which widgets are dockable and which ones are not.

Non-dockable widgets will auto-render into the template's DOM by Fusion just by existing in the Widget Set. There is no layout/placement work required on your part. That is all handled by Fusion and the template you're using. This gives a nice segway back into our Scalebar example.

The Scalebar is a non-dockable widget, and probably exists in any new Application Definition document you create in Maestro. So where is this scalebar when we load the template up with our Application Definition?

If you look at the HTML of the template (Slate). You'll come to find that there is no div in the markup or created programmatically in the template's JavaScript that has an id of "Scalebar". This is why our scalebar does not show, because Fusion could not find the matching DOM element in the template for the Scalebar widget to render into.

So to fix that, we need to put in a div with that id into the template's index.html.

(NOTE: I myself am not sure if there are any DOM placement rules we have to follow, I'm just going by a suggestion from the mapguide-users mailing list. This is a trial and error process at the moment)

If we reload the template now, you should finally see our mystery scale bar widget!

So for such non-dockable widgets (which the next release of Maestro 5.0 will help you distinguish), it's best to double-check your Fusion template's HTML/JS to make sure such widgets can be displayed.

Hopefully, this post sheds more light on how Fusion and AJAX viewers are similar, but also how they're different. But more importantly the ins and outs of widgets, the fundamental building blocks of a MapGuide Fusion application.