[mapserver-dev] Show of hands for ticket 3522

[Lime, Steve D (DNR)]

This will be in the 6.0 beta 2 release. I committed the change and tests this morning. Please take a peek
if you can before the release.

Steve
________________________________________
From: Stephen Woodbridge [woodbri at swoodbridge.com]
Sent: Thursday, March 17, 2011 6:19 PM
To: Lime, Steve D (DNR)
Cc: mapserver-dev
Subject: Re: [mapserver-dev] Show of hands for ticket 3522

Steve,

OK, that all makes sense and sounds good. I'm still +1 on the change.

-Steve W

On 3/17/2011 4:58 PM, Lime, Steve D (DNR) wrote:
> 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
>
>