Announcing: MapGuide Open Source 3.1 Beta 2

Here's the 2nd beta of MapGuide Open Source 3.1

The main change in this release is the "emergency" upgrade of the bundled PHP from 5.5 to 5.6.

This was done because the 5.5 series of PHP went end of life on July 10th. It wouldn't look good to ship the new version of MapGuide with a bundled version of PHP that is no longer supported. If you work with PHP in your MapGuide application, please observe any changes between 5.5 and 5.6 and migrate your application code accordingly (note that the MapGuide API is still the same here, the migration refers to any surrounding PHP code/libraries you may be using on top).

Besides the bundled PHP change, this beta includes the following changes:

• Fix MgGeometry API instability on Linux
• Fix instability of QUERYMAPFEATURES under high load
• Fix OK/Cancel buttons sometimes not being clickable on performance profiler map viewer
• Use full explicit property lists for feature queries in AJAX viewer
• Fusion: Fix query widget breaking on FDO property names with certain characters
• Fusion: Use full explicit property lists for feature queries

The explicit property list changes are to allow tools like buffer/query/etc to better work against certain relational FDO providers where a "select * from table" query may "leak" out column types that the FDO provider may not properly handle (and would normally be hidden in any class definitions returned by the provider)

Download

500,000 pageviews!

Hey! It's another blog milestone!

Thanks for the continued eyeball patronage!

React-ing to the need for a modern MapGuide viewer (Part 2): The baseline

I've decided that cataloging my adventure in developing this viewer is enough to warrant its own blog mini-series. So here's part 2 of my adventure. I have no idea how many parts this will take :)

So to continue where we left off, we had a basic map viewer component built on the main pillars of

• React
• OpenLayers 3

And it is all written in glorious TypeScript. I've mentioned once on a previous post that writing web frontend code in a language with static typing and a compilation phase (gasp!), with a clean and simple-to-understand component model offered by React is just heavenly! If I could go back in time, I'd have written the Fusion framework in TypeScript, but sadly it didn't exist around 2008 (when Fusion made its debut in MapGuide) and my involvement in the MapGuide project was nowhere near the level it is now.

So before I continue, I should also probably mention what I aim to achieve with this viewer:

• It will be built on modern, best-of-breed web front-end technologies (React, OpenLayers 3, etc)
• I will not be shackled with the burden of supporting legacy browsers. This viewer will demand a modern web browser. If one has to use Internet Explorer, it must be IE11
• It will require MapGuide Open Source 3.0 as the minimal version as this viewer will leverage capabilities present in this particular version onwards.
• It will at least have some level of feature parity with the AJAX/Fusion viewer offerings, that is to say:
• It will have a Legend component for toggling layer visibility and comprehending layer symbology/thematics.
• It will have a Task Pane component that functions as a generic container for content and/or contextual UI
• It will have a Map Selection component for easy viewing of selected features
• It will include a stock set of commands, with extension points for developers to add their own.
• It will have opt-in integration with external base layers (OpenStreetMap, etc), provided your Map Definition meets the requirements (ie. It is in EPSG:3857/WGS84.PseudoMercator).
• I will not at this time consider any kind of integration with Google Maps as their APIs are not only a constantly moving target, but a TOS minefield I just do not want to wander in at this point in time.
• I do hope to allow for some level of free-form component layout (ala. templates) so one is not tied to a layout I choose by default.

So with that being said, for this post I want to focus on the last major bullet point: Getting to parity with our current viewer offerings.

So let's introduce our new Legend component.

Implementing this component wasn't difficult, I mainly copypasta'd most of the presentation logic from the existing feature-complete legend used in my various mapguide-rest sample applications.

The difference here is that because this is now a React component, there is zero jQuery or DOM manipulation. Instead, we are just render Group/Layer child components for each layer and group we encounter in our runtime map. It is all pure UI as a function of props and state, and letting React's virtual DOM figure out how to actually update the DOM in the most efficient manner. What this means is that our component model cleanly matches how our layers and groups are conceptually structured.

As for the other components, I'm still working on them (currently focused on the Task Pane) so we'll leave that for another post. But visually speaking, when you put these 3 items together:

It's already starting to look like our existing AJAX viewer!

And before I close out this post, In terms of our current JS bundle size, here's the results of the current weigh-in (using our current Fusion production bundle for comparison).

We've got plenty of breathing room.

React-ing to the need for a modern MapGuide viewer

A few months ago, I mused about a hypothetical future map viewer for MapGuide.

Having a good solid 6 months of working with React and TypeScript (and dealing with Webpack in anger) under my belt, I felt confident enough to give this idea a crack.

This is what the consumption story looks like so far:

The HTML is just:

• One script tag (to the webpack bundle, containing the map viewer component and all of its dependencies
• Making an instance of the entry point class (currently called MapGuide.Application)
• Mounting the class (using React terminology here) at the desired DOM element with properties to pass into the root React component

And voila! Instant OpenLayers3-powered map viewer. Pretty simple stuff.

When we look at the current React component composition:

It's one root component (I'm intending for this to be something conceptually similar to the ApplicationDefinition/WebLayout for our existing viewers), and a child component that is wrapped by a react-dimensions higher-order component to automatically resize the map viewer according to parent element/window size changes (so we can hook in and call updateSize on the internal ol.Map to prevent image distortion)

The major deviation from my original thoughts is that in the above HTML code, there is no references to React or having to mount the viewer component using the React APIs. I've come to realize that this would be cumbersome as your ultimate entry point will always be HTML/JavaScript, way outside the zone of React/TypeScript/(T|J)SX, and although this is a "component", our final bundle is ultimately more an application instead of a library. So having a wrapper (which is what MapGuide.Application does) to do all of this leg work simplifies the whole setup process.

That's not to say we can't componentize this map viewer (as a library/package you can npm install), but my primary goal is to have an experience similar to our existing viewer offerings, which are applications whose features and behaviour is driven by configuration files. So in that respect, including a script tag and writing some JavaScript to point to your configuration and kickstart the application is much more easier to comprehend than installing node, npm, Webpack and messing with frontend development stacks.

So far so good. We're just beginning to scratch the surface.