MapGuide RFC 100 - Web Tier support for testing expressions and filters

This page contains an change request (RFC) for the MapGuide Open Source project. More MapGuide RFCs can be found on the RFCs page.

Status

RFC Template Version	(1.0)
Submission Date	25 June 2010
Last Modified	Jackie Ng, 3 September 2010
Author	Jackie Ng
RFC Status	draft
Implementation Status	pending
Proposed Milestone	2.3
Assigned PSC guide(s)	Jackie Ng
Voting History
+1
+0
-0
-1
no vote

Overview

This RFC proposes the Web tier APIs be extended to support the testing of FDO expressions.

Motivation

The expression editor in MapGuide Maestro lacks the ability to test the entered FDO expression/filter for validity. While the simple solution would be to have Maestro use FDO directly (which provides services for testing/parsing expressions), this breaks portability (Maestro is a .net application. FDO's .net wrapper is not portable). Having this functionality available at the web tier level is a more convenient and portable solution.

Proposed Solution

Add two new mapagent operations:

• Name: TESTEXPRESSION
• Parameters:
  • VERSION: 1.0.0
  • LOCALE: en
  • EXPRESSION: (the FDO expression to test)

• Name: TESTFILTER
• Parameters:
  • VERSION: 1.0.0
  • LOCALE: en
  • EXPRESSION: (the FDO filter to test)

Add the supporting native APIs to MgFeatureService (exported to SWIG with PUBLISHED_API)

class MgFeatureService
{
...
PUBLISHED_API:
    virtual bool TestExpression(CREFSTRING fdoExpr);
    virtual bool TestFilter(CREFSTRING fdoFilter);
...
};

Maestro's wrapper API will be updated to support these new mapagent commands.

Implications

This is an API addition. Existing APIs are unaffected. As this is an addition to a PlatformBase API, other implementations of MgFeatureService (eg. AutoCAD Map3D Geospatial API) will have to implement these APIs as well.

These APIs follow the same pattern as the TestConnection API in that only a return value of true will indicate validity. Anything else will result in a thrown FDO exception that gets bubbled up. Thus like the TestConnection API, callers should be testing filter/expression validity by testing for a return value of true

Test Plan

Test the http and web tier APIs with a series of valid and invalid FDO expressions. Use test data from existing FDO filter/expression unit tests. Verify a return value of true for all valid filters/expressions and verify a thrown MgFdoException for all invalid filters/expressions

Funding/Resources

Community based