[mapserver-dev] Show of hands for ticket 3522

[Perry Nacionales]

+1
-Perry
On Mar 17, 2011 3:59 PM, "Lime, Steve D (DNR)" <Steve.Lime at state.mn.us>
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
>
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20110317/6eb6a1f3/attachment-0001.html