Hi,
looking into an issue reported by a user (http://jira.codehaus.org/browse/GEOS-1735) I noticed that
data store and coverage store names are subjected to the
validation of the following regular expression:
Pattern.matches("^[a-zA-Z](\\w|\\.)*$")
that is, the full name must start with a letter and continue with
a sequence of word char (letter, number or _) or a dot
(from start to end, no partial match).
Now, I'm trying to figure out why this is so... the name is
actually used on the file system, so not allowing stuff like column,
semicolumn, quotes and the like seems sensible, but I cannot figure
out why numbers are excluded as the first char, or why the name
cannot start (or be) just an underscore.
What is preventing us from using a pattern like: ^\w(\w|\.)*$
Cheers
Andrea
I fully agree with you Andrea, I never understood why this pattern was applied.
Actually I don’t see any issue preventing us using names starting with numbers or underscores.
On Tue, Feb 26, 2008 at 3:15 PM, Andrea Aime <aaime@anonymised.com> wrote:
Hi,
looking into an issue reported by a user
(http://jira.codehaus.org/browse/GEOS-1735) I noticed that
data store and coverage store names are subjected to the
validation of the following regular expression:
Pattern.matches(“(\w|\.)*$”)
that is, the full name must start with a letter and continue with
a sequence of word char (letter, number or _) or a dot
(from start to end, no partial match).
Now, I’m trying to figure out why this is so… the name is
actually used on the file system, so not allowing stuff like column,
semicolumn, quotes and the like seems sensible, but I cannot figure
out why numbers are excluded as the first char, or why the name
cannot start (or be) just an underscore.
What is preventing us from using a pattern like: ^\w(\w|.)*$
Cheers
Andrea
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000
http://www.geo-solutions.it
Hmmm... I know there are restrictions on feature type names... but data store names? Indeed i don't see any reason off the top of my head. Could it be that it somehow ends up in the capabilities document somewhere and that dictates the regex?
Andrea Aime wrote:
Hi,
looking into an issue reported by a user (http://jira.codehaus.org/browse/GEOS-1735) I noticed that
data store and coverage store names are subjected to the
validation of the following regular expression:
Pattern.matches("^[a-zA-Z](\\w|\\.)*$")
that is, the full name must start with a letter and continue with
a sequence of word char (letter, number or _) or a dot
(from start to end, no partial match).
Now, I'm trying to figure out why this is so... the name is
actually used on the file system, so not allowing stuff like column,
semicolumn, quotes and the like seems sensible, but I cannot figure
out why numbers are excluded as the first char, or why the name
cannot start (or be) just an underscore.
What is preventing us from using a pattern like: ^\w(\w|\.)*$
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
!DSPAM:4007,47c41f2c187275219720167!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira ha scritto:
Hmmm... I know there are restrictions on feature type names... but data store names? Indeed i don't see any reason off the top of my head. Could it be that it somehow ends up in the capabilities document somewhere and that dictates the regex?
Hum, no, it does not... it's not part of the official document, it's not
part of the comments either.
I'll relax the regexp and let's see what comes out
Cheers
Andrea