formatting strategies

[Berryl Hesh]

Requirements for a field that represents an EmployeeNumber:

· The field is always 6 characters long, and is stored as a 'string'
in the db

o All characters must be digits

§ Regex pattern?

o If the number of digits in the EmployeeNumber is less than 6
characters, pad the number with leading 0's (i.e., 12 == '000012', 6728 ==
'0006728').

§ String.Format({"06", empNumber) ?

o The non-padded number should be easily extractable

§ empNbrString.Substring(_firstCharGreaterThanZero(empNbrString))
(ie, '006728' == 6728, '000012' == 12)



Each requirement sounds relatively easy to do by brute force, but I'm sure
there is a more elegant approach some of you experts have used before.



Would you use a custom format provider? That may be overkill for the
employee, but I have similar formatting requirements for projectNumbers
which are complicated by the fact that different formats may apply to the
same project, depending on the organizational point of view.



Thanks for the Guidance

 

[Jon Skeet [C# MVP]]

Requirements for a field that represents an EmployeeNumber:

· The field is always 6 characters long, and is stored as a 'string'
in the db

Why is it stored as a string in the database if it's always an integer?

o All characters must be digits

§ Regex pattern?

That would certainly be pretty simple. Or just check the length and
that each character is in the range 0-9, which is easy by brute force.
It depends on how regex-savvy the maintainers will be.

o If the number of digits in the EmployeeNumber is less than 6
characters, pad the number with leading 0's (i.e., 12 == '000012', 6728 ==
'0006728').

I thought you said it *was* always 6 characters?

§ String.Format({"06", empNumber) ?

That will only work if empNumber is an integer rather than a string.

o The non-padded number should be easily extractable

§ empNbrString.Substring(_firstCharGreaterThanZero(empNbrString))
(ie, '006728' == 6728, '000012' == 12)

Just use int.Parse.

Each requirement sounds relatively easy to do by brute force, but I'm sure
there is a more elegant approach some of you experts have used before.

Would you use a custom format provider? That may be overkill for the
employee, but I have similar formatting requirements for projectNumbers
which are complicated by the fact that different formats may apply to the
same project, depending on the organizational point of view.

I don't see any particular call for a custom format provider here, but
it depends on what you want to do. For data binding that *may* be
useful - I'm not terribly hot on data binding.

 

[Berryl Hesh]

Requirements for a field that represents an EmployeeNumber:

· The field is always 6 characters long, and is stored as a
'string'
in the db

Good point. I was guessing that PSoft displayed it that way because it
stored it that way. Truthfully I have no idea why they even display it this
way, but they've been fairly successful so there must be something behind
that.

o All characters must be digits

§ Regex pattern?

I'm not very savvy with that myself - could you show me what the Regex check
would look like??

o If the number of digits in the EmployeeNumber is less than 6
characters, pad the number with leading 0's (i.e., 12 == '000012', 6728 ==
'0006728').

As a convenience to data input.

§ String.Format({"06", empNumber) ?

That will only work if empNumber is an integer rather than a string.

o The non-padded number should be easily extractable

§ empNbrString.Substring(_firstCharGreaterThanZero(empNbrString))
(ie, '006728' == 6728, '000012' == 12)

Yup - Thank you

Each requirement sounds relatively easy to do by brute force, but I'm sure
there is a more elegant approach some of you experts have used before.

Would you use a custom format provider? That may be overkill for the
employee, but I have similar formatting requirements for projectNumbers
which are complicated by the fact that different formats may apply to the
same project, depending on the organizational point of view.

I was thinking about a different formatting scenario with project numbers
that may be formatted differently for different systems. The number is
always based on the year the project is assigned and the next available
number. A legacy accounting system, for example, requires that number to
look like 008-00132 (assuming 132 is the next number available for a project
assigned in 2008). Project managers just use 08-132 because its easier to
work with.

Thanks for the response.

 

[Jon Skeet [C# MVP]]

Good point. I was guessing that PSoft displayed it that way because it
stored it that way. Truthfully I have no idea why they even display it this
way, but they've been fairly successful so there must be something behind
that.

So that's a "given" - you don't have control over it?

I'm not very savvy with that myself - could you show me what the Regex check
would look like??

Here's some code which uses the pattern and tests it:

using System;
using System.Text.RegularExpressions;

class EmployeeNumber
{
static readonly Regex Pattern = new Regex("^[0-9]{6}$",
RegexOptions.Compiled);

static void Main()
{
Test("123456");
Test("1234567");
Test("12345");
Test("12AA56");
Test("AA123456BB");
}


static void Test(string candidate)
{
Console.WriteLine("{0}: {1}",
candidate,
Pattern.IsMatch(candidate));
}
}

As a convenience to data input.

Okay, I see what you mean. In that case I'd parse it to an integer,
then pad it as you showed below.

I was thinking about a different formatting scenario with project numbers
that may be formatted differently for different systems. The number is
always based on the year the project is assigned and the next available
number. A legacy accounting system, for example, requires that number to
look like 008-00132 (assuming 132 is the next number available for a project
assigned in 2008). Project managers just use 08-132 because its easier to
work with.

I think you can still do that reasonably easily with just a custom
format string (but not a custom provider). Not sure how feasible the
parsing would be, but the formatting would be easy.

 

[Berryl Hesh]

Thanks for the info!

RE: data binding.
I've seen another experienced programmer that I respected also knock data
binding, awhile ago (I think it was Jeremy Miller), yet I see other
programmers, not to mention MS, continue to spend what seems like
considerable effort on it - do you have any links on the topic you
particularly like?

- Berryl Hesh

 

[Jon Skeet [C# MVP]]

RE: data binding.
I've seen another experienced programmer that I respected also knock data
binding, awhile ago (I think it was Jeremy Miller), yet I see other
programmers, not to mention MS, continue to spend what seems like
considerable effort on it - do you have any links on the topic you
particularly like?

It's not that I particularly dislike it - although I have had problems
on the rare occasions when I've used it - but I just don't do much
client side coding, so I haven't had much experience with it.