Need to automatically add space in Canadian postal code input

[CodeZombie]

I'm having trouble finding this fix.

In the postal code form field I need it to automatically add the space between the postal code entered.

So when typed into the form field it will automatically add the space (A1A 1A1)

<input type="text" placeholder="XXX XXX" pattern="/^{([a-zA-Z]\d[a-zA-Z])\} {0,1}(\d[a-zA-Z]\d)$/" title="Required format XXX XXX" class="form-control" name="<?php echo $profile_address; ?>[postalcode]" style="text-transform:uppercase" value="<?php echo getFieldArrayValue($formElements[$profile_address], 'postalcode') ?>" />

[laserlight]

So the postal codes are always 6 characters?

[cluelessPHP]

Maybe something like this?

<?php
$postcode = "A1A1A1";
echo chunk_split($postcode, 3, ' ');
?>

[dalecosp]

cluelessPHP;11058097 wrote:

Maybe something like this?

<?php
$postcode = "A1A1A1";
echo chunk_split($postcode, 3, ' ');
?>

+1 for remembering the 3rd param 🙂

For extra credit, write JavaScript that splits the input at onSubmit ... :p

[CodeZombie]

laserlight;11058093 wrote:

So the postal codes are always 6 characters?

Yes only 6 Characters

[NogDog]

And then back on the server side you need to make sure it's being stored without any space (yet still meets the 6-character requirement) so that you are consistent in format DB-wise. 🙂

[cluelessPHP]

Not to high-jack the OP's thread BUT...

Do client side validation then insert a a six digit varchar into a database? Or did I miss read that? :p

[NogDog]

cluelessPHP;11058119 wrote:

Not to high-jack the OP's thread BUT...

Do client side validation then insert a a six digit varchar into a database? Or did I miss read that? :p

I just meant that it at least appears the intent is to take a 6-character value in PHP and put a space in the middle when outputting it in the HTML form as a field value. Since this seems to at least imply that on the server it just has a 6-character string with no space, you'll want to convert the incoming value from the form that has a space into one that does not, before storing it in the DB (or wherever). What you don't want is to end up with some 6-character and 7-character codes in the same DB column (or wherever).

Or I'm confused and making things worse. ¯_(&#12484😉_/¯

[dalecosp]

NogDog;11058123 wrote:

What you don't want is to end up with some 6-character and 7-character codes in the same DB column (or wherever).

Is there an actual technical reason for this, or is it a personal preference based on some OCD behavior?

I suppose I can think of one reason ... so you don't have to write a check to see if you need to format it or not, I suppose....

[cluelessPHP]

NogDog;11058123 wrote:

Or I'm confused and making things worse. ¯_(&#12484😉_/¯

Sounds like me on a daily basis 😃

[Derokorian]

dalecosp;11058135 wrote:

Is there an actual technical reason for this, or is it a personal preference based on some OCD behavior?

I suppose I can think of one reason ... so you don't have to write a check to see if you need to format it or not, I suppose....

Makes searching more efficient, because you don't end up looking for code = 'ABC123' OR code = 'ABC 123' ... that's my attempt at a technical reason 🙂

[cluelessPHP]

Derokorian;11058139 wrote:

Makes searching more efficient, because you don't end up looking for code = 'ABC123' OR code = 'ABC 123' ... that's my attempt at a technical reason 🙂

Couldn't you do something like?

SELECT * FROM Customers
WHERE postCode LIKE '%bc %2%';

[NogDog]

Using LIKE can be problematic for performance reasons, as depending on where the '%' characters are, the DB may not be able to optimally make use of an index on that column, as it effectively has to "manually" look at values to determine which ones match. This is especially true if you have to use the '%' at the start of the string. Therefore, to avoid having to worry about that and having to even just do the simple OR comparison, seems simpler and ultimately more normalized to me to make sure a consistent format is used in the DB, both with regards to the space or no space, and upper or lower case letters.

[dalecosp]

I can certainly see normalization of text fields like that to be advantageous; although I don't know how much code I've written to deal with things like that, just think about the difference between writing one function to normalize a postcode and stick it in the DB vs. having several places to put a function (or functions) that check the format before standardizing it for output ...

In the case of my work, phone numbers come to mind immediately.