= !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 [wiki:MapGuideRfcs 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