[mapserver-dev] Show of hands for ticket 3522

[Lime, Steve D (DNR)]

This is the method used to validate the URL modification of certain map file properties. So it's already in place. Actually controlling a value domain for a parameter at the layer level is quite useful. It allows for a common interface from the client-side with, plus that's how it's done now albeit with layer-level metadata. Not supporting that would be a regression... Doing the validation at the web level is the new feature...

Yes, this does handle the defaults.

Anyway, the problem I have is that you don't know which CGI parameters are candidates for substitution so you have to at least consider all of them. You could skip some that are MapServer CGI params, e.g. map or layer, but who wants to maintain that plus there might actually be a need for referencing the map file somehow. I just need to be smarter with deciding to even consider looking at a layer...

Steve
________________________________________
From: mapserver-dev-bounces at lists.osgeo.org [mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Stephen Woodbridge [woodbri at swoodbridge.com]
Sent: Thursday, March 17, 2011 12:13 PM
To: Lime, Steve D (DNR); mapserver-dev
Subject: Re: [mapserver-dev] Show of hands for ticket 3522

Steve,

This only came to me, assume it should also go to the list. and cc'ing
the list.

Anyway, if you only have a validation block at the WEB, then there
should be only one check right? If a user has a need for more checks
then it costs them more for the need to do more checking.

I'm still stuck on what is the use case for all this complexity?

The best I can imagine so far is the need for different default values
in different layers if the pattern does not validate. And the simple
work around for this is to make different parameters for different
needs. It is also cleaner and more logical from an application point of
view.

Not that I want to break stuff but I think going forward we should have
a clean simple implementation and if we need to grow it for additional
use cases then fine. Which I said before.

Are you handling default values also?

I would just force moving all validation up to a single web validation
block. If you think this might be too restrictive, you could state that
we plan to do this on the user list and ask if it breaks existing use
cases and what those cases are. But this takes time for responses.

My 2 cents,
   -Steve W

On 3/17/2011 12:18 PM, Lime, Steve D (DNR) wrote:
> I have it working like so:
>
>    - validation block for layer (e.g. 'foo' 'regex')
>    - old-style metadata (e.g. 'foo_validation_pattern' 'regex')
>    - validation block for web (same syntax as above)
>
> I'm worried it's expensive since for each parameter passed in you have to check up to 3 expressions for each layer before you know if it's cool to do the substitutions. I've not committed yet...
>
> Steve
>
> ________________________________________
> From: mapserver-dev-bounces at lists.osgeo.org [mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Stephen Woodbridge [woodbri at swoodbridge.com]
> Sent: Wednesday, March 16, 2011 11:50 AM
> To: mapserver-dev at lists.osgeo.org
> Subject: Re: [mapserver-dev] Show of hands for ticket 3522
>
> On 3/16/2011 12:38 PM, Lime, Steve D (DNR) wrote:
>> Hi everyone: Working through tickets and this one's sitting out there:
>>
>>     http://trac.osgeo.org/mapserver/ticket/3522
>>
>> Basically its about requiring a validation pattern (given as a regex) for any value used for runtime substitution. It's currently optional. I think it would be a proactive move to keep folks from themselves. Currently we allows subs in:
>>
>> - layer: data, tileindex, connection, filter
>> - class: expression
>>
>> 6.0 is the right time if we wanted to do this.
>
> I'm +1 for 6.0 and I think this should be made simple in that all
> validation patterns are defined once in the MAP ->  VALIDATION object and
> are applied globally.
>
> If you define %foo% and use it in multiple places, I can't see what it
> would mean to validate in one place and not in another.  If people want
> separate validations than they can use separate variables. Maybe if
> someone is getting very tricky and they want it to fail so it defaults
> to a different value based on having multiple defaults that are location
> specific.
>
> My take is, rationalize it and make it simple and if we need more in the
> future then add new features in the new framework.
>
> -Steve W
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
>

_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev