Show quoted text> Your module (which I think is a *very* good idea) has the problem of
> not being very useable for non-english speakers.
> Eg. the genders 'male' and 'female' are not meaningfull in danish -
> they should be 'mand' and 'kvinde', likewise for yes/no...
With my shortbrainness I believed that type like varchar(80)/email etc
are international. But since you point me to localization, i realized
that some aren't. I will keep my eyes on that in future and try to use
strict localization support. So at least international contributers
have a tool of localization features, since i have only command over 3-
4.
Show quoted text> The texts are embedded deeply in the code, and are not configureable -
> they should possibly use as much of the locale setting as possible
> (there is a setting for the local yes/no values) - or perhaps
> not.... I dunno whats the right thing to do.
Todays release (CPAN) made a step towards that. Now the localization is
somehow configurable via object oriented techniques (see the Changes
file for example). I introduced DK::YESNO (but mixed that danish words
for male/female;)). Skim through Types.pm to Type::yesno vs
Type::dk_yesno how that is particularly implemented.
Show quoted text> The date tests are very mysql-centric, and could perhaps use the
> Date::Parse module to allow a braoder range of dates.
Took that (see Changes too). Now available via DATE( 'DATEPARSE' ). One
of the initial intentions for this module was to provide some pre-
database type checking. Since i am very used to mysql, i decided to
start with that.
Show quoted text> Again it would be nice to be able to specify what the currrent view of
> allowable date-formats are, eg. we allow 'yymmdd', 'yy.mm.dd'
> 'yyyy.mm.dd' as out Ingres database system supports these formats
> (in our configuration).
Could you send me a link or some general describtion how the Ingres
builtin types. I could add that to INGRES::DATE or better DATE
( 'INGRES' ).
Show quoted text> If you go all the way, then the errormessages should also be
> configurable - but thas probably too much :)
Hmmm.. i think this is just a matter of sedulity. I will try to start
putting all msgs to a central hash where, or look for something more
generic (i think i saw a tpj article about localization).
Show quoted text> A small suggestion for further addition: make it possible add your own
> datatypes (preferably both at runtime and install/configuration
> time) giving at least Name and Verification regexp.
This is easy, but not documented yet (todo). In general do that:
BEGIN
{
package Type::your_type;
sub info
{
}
sub test
{
}
}
use Data::Type qw(:all);
look into Type.pm at Type::yesno to see a 'simple' template how to add
a type. Then your_type will be available via YOUR_TYPE.
Show quoted text> That could even be used to tell me to go and make my own danish types
> for gender and yes/no!
i am looking forward to have one
use Data::DK::Type;
in future (as far as i can assist you).
Show quoted text> Otherwise I really like the idea, and could put it to good use in or
> systems.
Good luck with that. Because this is alpha-stuff you shouldn't use that
to control an atomic power plant. Especially the CREDITCARD stuff needs
to be verified by sceptic users.
Thanks for your interest,
Murat
