This is a quick release to fix the viewer so that it can load maps that contain raster layers.
Download
Posts
Upcoming Changes to InfraWorks Services
6 years ago
Wednesday, 19 October 2016
Monday, 17 October 2016
Announcing: mapguide-react-layout 0.6
Previously, I mentioned a series of blocking issues (in the process of porting over the Aqua Fusion template) that I needed to clear before I can safely put out a new release of mapguide-react-layout. Well, those roadblocks have been cleared, so here's a new release.
Here's a summary of the cool stuff since the first official release.
Aqua Template
The first of 5 fusion templates have been ported across.
Here's how the road blocks were cleared
1. Task Pane / Selection Panel / Legend does not play nice with Modal Dialogs
It turns out that all we really needed to do was have each modal dialog containee component support the notion of a maximum height and overflow:scroll its inner content if that height is exceeded. As these modal dialogs are of a known height, we know what max height that will have to be applied to each top-level component that is to be housed inside a modal dialog
2. We sort of need InvokeScript support as that is what the original templates use to show the Task Pane / Selection Panel / Legend / etc.
I've decided to nip this one in the bud and just hard code into the template 3 toggling buttons that you can see on the top-right hand corner of the screenshot. If you close any of the affected modals, you can hit the respective button to bring it back.
3. Flyout menus don't play nice either
This one looked to be hard, but thankfully the react-flyout component I've chosen allowed for my workaround to (ahem) work with minimal amount of legwork.
The key was to introduce a new top-level FlyoutRegion component which all flyout menus render into (regardless of what toolbar they come from). As this FlyoutRegion component is top-level, the flyout menus rendered inside do not have a direct parent-child relationship with the toggling button (from whatever toolbar it may originate from), therefore it is not subject to being caught up in any toolbar CSS overflow shenanigans.
The only catch with this is that all the flyout menus will always render to the top left corner (I'm guessing this wasn't a usage scenario envisioned by the react-flyout author). So as a minor hack I've introduced new redux actions to dispatch the opening/closing of flyout menus, which the FlyoutRegion listens on, and the flyout menu buttons dispatch such actions when clicked, also flowing back DOM element dimensions (of the toggling button), so the listening FlyoutRegion component knows exactly where to position the flyout menu to be rendered.
This isn't perfect, as this animation shows
But it's a small (and acceptable) price to pay for what is now mostly functional flyout menus.
Application Definition (aka. Flexible Layout) support
As porting across the Aqua template would imply, the viewer now accepts Application Definition resource ids in addition to Web Layout resource ids. Please note that currently only certain templates can accept Web Layouts and others only accept Application Definitions. You can find out which template supports what in this document.
This support is not 100% yet, and so you will invariably find error placeholders for un-implemented widgets strewn across various toolbars and menus like so.
If you hover your mouse over these items, you can see what the viewer currently doesn't support or map across yet.
So when you encounter such buttons, the only practical thing to do at the moment is to remove such buttons from your Application Definition. The error placeholder mechanism is a nice and easy way to identify such unsupported elements.
If your Application Definition has external base layers defined, this release will recognize the following base layer types:
Better Startup
The initial release of mapguide-react-layout wasn't really graceful about any errors that occur during the process of initialization. All you had was a white screen of nothingness to tell you that something went wrong. So naturally in the interest of providing a good out-of-the-box experience, this was something that needed to be rectified.
If there's a problem on startup, we'll show it to you now. For example, the MapGuide Server isn't running or reachable.
Another common silent error is loading a map with an EPSG code not known to proj4js (ie. Anything not EPSG:4326 or EPSG:3857). Now for such EPSG codes that aren't known to proj4js on startup, we'll automatically fetch the appropriate proj4js definition from https://epsg.io, register it with proj4js and continue on our merry way.
More OpenLayers goodies baked in
The base map viewer component now has these extra OL controls baked in.
An overview map
A rotation reset button that's shown when you rotate the map. You can rotate the map by holding ALT+SHIFT and dragging the map to rotate it.
And lots more!
All is covered in the associated release notes for this release.
Download
Here's a summary of the cool stuff since the first official release.
Aqua Template
The first of 5 fusion templates have been ported across.
Here's how the road blocks were cleared
1. Task Pane / Selection Panel / Legend does not play nice with Modal Dialogs
It turns out that all we really needed to do was have each modal dialog containee component support the notion of a maximum height and overflow:scroll its inner content if that height is exceeded. As these modal dialogs are of a known height, we know what max height that will have to be applied to each top-level component that is to be housed inside a modal dialog
2. We sort of need InvokeScript support as that is what the original templates use to show the Task Pane / Selection Panel / Legend / etc.
I've decided to nip this one in the bud and just hard code into the template 3 toggling buttons that you can see on the top-right hand corner of the screenshot. If you close any of the affected modals, you can hit the respective button to bring it back.
3. Flyout menus don't play nice either
This one looked to be hard, but thankfully the react-flyout component I've chosen allowed for my workaround to (ahem) work with minimal amount of legwork.
The key was to introduce a new top-level FlyoutRegion component which all flyout menus render into (regardless of what toolbar they come from). As this FlyoutRegion component is top-level, the flyout menus rendered inside do not have a direct parent-child relationship with the toggling button (from whatever toolbar it may originate from), therefore it is not subject to being caught up in any toolbar CSS overflow shenanigans.
The only catch with this is that all the flyout menus will always render to the top left corner (I'm guessing this wasn't a usage scenario envisioned by the react-flyout author). So as a minor hack I've introduced new redux actions to dispatch the opening/closing of flyout menus, which the FlyoutRegion listens on, and the flyout menu buttons dispatch such actions when clicked, also flowing back DOM element dimensions (of the toggling button), so the listening FlyoutRegion component knows exactly where to position the flyout menu to be rendered.
This isn't perfect, as this animation shows
But it's a small (and acceptable) price to pay for what is now mostly functional flyout menus.
Application Definition (aka. Flexible Layout) support
As porting across the Aqua template would imply, the viewer now accepts Application Definition resource ids in addition to Web Layout resource ids. Please note that currently only certain templates can accept Web Layouts and others only accept Application Definitions. You can find out which template supports what in this document.
This support is not 100% yet, and so you will invariably find error placeholders for un-implemented widgets strewn across various toolbars and menus like so.
If you hover your mouse over these items, you can see what the viewer currently doesn't support or map across yet.
So when you encounter such buttons, the only practical thing to do at the moment is to remove such buttons from your Application Definition. The error placeholder mechanism is a nice and easy way to identify such unsupported elements.
If your Application Definition has external base layers defined, this release will recognize the following base layer types:
- OpenStreetMap: Mapnik/CycleMap/TransportMap
- Stamen: Toner/Terrain/Watercolor
Better Startup
The initial release of mapguide-react-layout wasn't really graceful about any errors that occur during the process of initialization. All you had was a white screen of nothingness to tell you that something went wrong. So naturally in the interest of providing a good out-of-the-box experience, this was something that needed to be rectified.
If there's a problem on startup, we'll show it to you now. For example, the MapGuide Server isn't running or reachable.
Another common silent error is loading a map with an EPSG code not known to proj4js (ie. Anything not EPSG:4326 or EPSG:3857). Now for such EPSG codes that aren't known to proj4js on startup, we'll automatically fetch the appropriate proj4js definition from https://epsg.io, register it with proj4js and continue on our merry way.
More OpenLayers goodies baked in
The base map viewer component now has these extra OL controls baked in.
An overview map
A rotation reset button that's shown when you rotate the map. You can rotate the map by holding ALT+SHIFT and dragging the map to rotate it.
And lots more!
All is covered in the associated release notes for this release.
Download
Tuesday, 11 October 2016
Announcing: MapGuide Open Source 3.1 and mg-desktop/nuget packages
The wait is over. MapGuide Open Source 3.1 has arrived.
The only change from RC1 is a fix to the QUERYMAPFEATURES operation and its consuming map viewers (both AJAX and Fusion) to respect the display order of attributes in Layer Definitions.
Along with this release are updated mg-desktop binaries and nuget packages. Just a friendly reminder about nuget packages: Install the version of the nuget package for the version of MapGuide you are intending to be running your application against.
Download MapGuide
Download mg-desktop
The only change from RC1 is a fix to the QUERYMAPFEATURES operation and its consuming map viewers (both AJAX and Fusion) to respect the display order of attributes in Layer Definitions.
Along with this release are updated mg-desktop binaries and nuget packages. Just a friendly reminder about nuget packages: Install the version of the nuget package for the version of MapGuide you are intending to be running your application against.
Download MapGuide
Download mg-desktop
Thursday, 6 October 2016
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:
Unfortunately, the process of porting across the Aqua template has revealed some teething issues.
- 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.
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:
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
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.
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.
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.
Subscribe to:
Posts (Atom)
