Changes between Version 3 and Version 4 of 60MigrationIssues


Ignore:
Timestamp:
Sep 1, 2010, 9:00:35 PM (14 years ago)
Author:
sdlime
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • 60MigrationIssues

    v3 v4  
    44'''Parser Overhaul Changes (RFC59)'''
    55
    6   - treating class TEXT expressions as true expressions instead of just doing substitutions. Allows advanced formatting options such as rounding, adding commas to numbers, case adjustments and so on. Totally changes meaning of this attribute.
    7   - drop support for trailing i's to denote case-insensitive searches. Instead use case-insensitive operators for string (=*) and regex (~*). Simplifies expression syntax and lexer code significantly. Case insensitive regex has never worked.
    8   - drop //'s for right-hand portion of regex comparisons in logical expressions. Again, simplifies parser and is more inline with RDBMS SQL (PostgreSQL and MySQL do this). Users would just mark the expression with quotes. This would be consistent with regex use elsewhere in mapfiles and would leave regex expressions (e.g. EXPRESSION /foo/) as the only time the //'s are used.
     6- treating class TEXT expressions as true expressions instead of just doing substitutions. Allows advanced formatting options such as rounding, adding commas to numbers, case adjustments and so on. Totally changes meaning of this attribute.
     7- drop support for trailing i's to denote case-insensitive searches. Instead use case-insensitive operators for string (=*) and regex (~*). Simplifies expression syntax and lexer code significantly. Case insensitive regex has never worked.
     8- drop //'s for right-hand portion of regex comparisons in logical expressions. Again, simplifies parser and is more inline with RDBMS SQL (PostgreSQL and MySQL do this). Users would just mark the expression with quotes. This would be consistent with regex use elsewhere in mapfiles and would leave regex expressions (e.g. EXPRESSION /foo/) as the only time the //'s are used.
    99
    1010'''Template Tag Changes'''
    1111
    12   - see [wiki:60RemoveTemplateTags] for a complete list. This simplifies the code (and security) through the use of common presentation functions (e.g. processExtentTag(...)).
     12- see [wiki:60RemoveTemplateTags] for a complete list. This simplifies the code (and security) through the use of common presentation functions (e.g. processExtentTag(...)).
    1313
    1414'''CGI Query Mode Changes'''
    1515
    16   - remove all ...MAP modes (e.g. ITEMQUERYMAP). They just bloat the code and documentation. A suitable alternative has existed since 5.4, that is, use a base query mode coupled with an image query format (e.g. ...&mode=itemquery&qformat=png24&...).
     16- remove all ...MAP modes (e.g. ITEMQUERYMAP). They just bloat the code and documentation. A suitable alternative has existed since 5.4, that is, use a base query mode coupled with an image query format (e.g. ...&mode=itemquery&qformat=png24&...).
    1717
    1818
    1919'''Support for STYLEs in LABELs'''
    2020
    21   - this was added at the NYC code sprint. It allows you to define markers and label boxes using styles so you can do things like road shields and complex line work in one pass. This means all the attributes associated with label billboards and billboard shadows can be removed. This simplifies the labelObj and everything associated with it. Simply deprecating the parameters would add undue complexity to the label handling code.
     21- this was added at the NYC code sprint. It allows you to define markers and label boxes using styles so you can do things like road shields and complex line work in one pass. This means all the attributes associated with label billboards and billboard shadows can be removed. This simplifies the labelObj and everything associated with it. Simply deprecating the parameters would add undue complexity to the label handling code.
    2222
    2323'''One-pass Query Handling in MapScript'''
    2424
    25   - I screwed this up in 5.6 by introducing the resultsGetShape() method to layers. Only to find out later that the drivers didn't implement things the same way. I propose reverting to a single getShape() method and requiring both passed indexes (if the user wants performance). The first index would be the global shape index suitable for random access to a shape at any time. The second, tile index, would be interpret differently but only one of two ways:
     25- I screwed this up in 5.6 by introducing the resultsGetShape() method to layers. Only to find out later that the drivers didn't implement things the same way. I propose reverting to a single getShape() method and requiring both passed indexes (if the user wants performance). The first index would be the global shape index suitable for random access to a shape at any time. The second, tile index, would be interpret differently but only one of two ways:
    2626
    2727    1. If a driver supports tiling (basically only shapefiles) then it's truly a tile index and handled as such.
    … …  
    3232'''CGI Run-time Validations'''
    3333
    34   - Run-time substitutions are popular and powerful. They also can be used as a route to sql-injection if not used properly. We offer users a way to set default values and value validation but neither are required. I propose changing the latter and not performing substitutions unless a validation is explicitly defined. We do this now for URL-based parameter override.
     34- Run-time substitutions are popular and powerful. They also can be used as a route to sql-injection if not used properly. We offer users a way to set default values and value validation but neither are required. I propose changing the latter and not performing substitutions unless a validation is explicitly defined. We do this now for URL-based parameter override.