Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="info"><ac:parameter ac:name="title">Zend_Validate_Barcode_UPC - Andries Seutens</ac:parameter></ac:macro>

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Validate_Barcode_UPC Component Proposal

Proposed Component Name Zend_Validate_Barcode_UPC
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Validate_Barcode_UPC
Proposers Andries Seutens
Darby Felton, Zend liaison
Revision 1.0 - Initial draft: 3 july 2007 (wiki revision: 8)

Table of Contents

1. Overview

Zend_Validate_Barcode_UPC is a simple component that validates the validity of an UPC barcode.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will validate the validity of an UPC barcode.
  • This component will calculate the proper checksums.
  • This component will not validate a barcode from an image.

4. Dependencies on Other Framework Components

  • Zend_Exception
  • Zend_Validate_Abstract

5. Theory of Operation

The component is instantiated with a mind-link that ... it will rock the planet.

6. Milestones / Tasks

  • Milestone 1: [DONE] write proposal
  • Milestone 2: get the proposal approved
  • Milestone 3: working prototype checked into the incubator
  • Milestone 4: write unit test, and check into SVN
  • Milestone 5: write documentation for this validator.
  • Milestone 5: introduce "component" to core.

7. Class Index

  • Zend_Validate_Barcode_UPC

8. Use Cases

UC-01: validating barcode
UC-02: retrieving invalid barcode message

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

11 Comments

comments.show.hide

  1. Jul 13, 2007

    Darby Felton

    <p>It seems like the STRING_EMPTY state is a special case of INVALID_LENGTH... is there a reason to have these separate? That is, if an input string is not 12 characters in length, then does it really matter whether it had 2, 1, or 0 characters?</p>

    <p>Whatever the decision, it would apply to the other bar code proposals as well:</p>

    <ul>
    <li><a href="http://framework.zend.com/wiki/x/W4g">Zend_Validate_Barcode_ISBN13</a></li>
    <li><a href="http://framework.zend.com/wiki/x/Uog">Zend_Validate_Barcode_EAN13</a></li>
    </ul>

    1. Jul 16, 2007

      Andries Seutens

      <p>I see a null length and an invalid length as two seperate things. Other components, such as Zend_Feed seem to also apply this case, wheras an empty string results in a seperate error message.</p>

      1. Aug 03, 2007

        Darby Felton

        <p>I agree that zero length and invalid length are different things, but they are related. The relationship is that having zero length input is a <em>special case of</em> having input with invalid length. Put another way, input of invalid length <em>includes</em> the situation where it happens to be of zero length.</p>

        <p>It would be simpler to not distinguish between the two situations, allowing the "parent" state of invalid length to be reached any time the length is invalid, including when the length is zero. The resulting validation failure message should include the invalid length, which could be zero or some value other than 12.</p>

        <p>That way, it is readily apparent to the user what string length was received when it is invalid, regardless of what the value may be.</p>

        1. Aug 06, 2007

          Andries Seutens

          <p>okay, fine with me. I will update the proposal asap.</p>

  2. Aug 03, 2007

    Darby Felton

    <p>This seems to be a validation for UPC-A. Is this encoding used almost exclusively when compared with other encodings, such as UPC-E?</p>

    <p>Some explanation of this may help us to make sure the classes are named appropriately, in case we may need to add other encodings if the demand should arise.</p>

    1. Aug 06, 2007

      Andries Seutens

      <p>Yes, that is correct, this validator is exclusively for UPC-A validation, but there are other variants as well, such as UPC-E UPC-2 digit, UPC-5 digit.</p>

      <p>Some, but not all UPC-A barcodes can be converted to the UPC-E varient, so I think we should agree on a consensus about what we shall do with this:</p>

      <ul class="alternate">
      <li>A new validator for each barcode variant?</li>
      <li>Wrap common variants in a single class?</li>
      </ul>

      <p>What do you/others suggest?</p>

      <p>This is also the case for the EAN13 validator, although those variants (EAN-2, EAN-3, EAN-8) are basicly history, which is not the case for the UPC-* barcodes.</p>

      1. Aug 07, 2007

        Darby Felton

        <p>I hope to hear others' opinions, as well, but I'll offer mine:</p>

        <p>I think that it makes sense to offer variants of a particular barcode type as a configurable option. For example, UPC-A and UPC-E could be exposed by a single class quite appropriately.</p>

        <p>It is less clear to me whether it makes sense to support all barcode types with a single class having the types and variants as options.</p>

        <p>Here is an idea - <code>Zend_Validate_Barcode</code>, a class not yet proposed, could support the popular barcode types you have proposed (UPC-A, EAN-13, ISBN-13). Perhaps "under the hood", <code>Zend_Validate_Barcode</code> is making use of classes available in <code>Zend/Validate/Barcode/</code>, such as <code>Zend_Validate_Barcode_Upc</code> and <code>Zend_Validate_Barcode_Isbn</code>, each of which supports its own variants/encodings. A sample use case:</p>

        <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
        require_once 'Zend/Validate/Barcode.php';
        $barcodeValidator = new Zend_Validate_Barcode('UPC-A');
        if ($barcodeValidator->isValid($someBarcode)) {
        // ...
        ]]></ac:plain-text-body></ac:macro>

        <p>Alternative usage of the specific class:</p>

        <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
        require_once 'Zend/Validate/Barcode/Upc.php';
        $barcodeUpcValidator = new Zend_Validate_Barcode_Upc(); // defaults to UPC-A?
        $barcodeUpcValidator->setEncoding('E');
        if ($barcodeUpcValidator->isValid($someBarcode)) {
        // ...
        ]]></ac:plain-text-body></ac:macro>

        1. Aug 07, 2007

          Darby Felton

          <p>One more code snippet to illustrate how to change barcode types:</p>

          <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
          require_once 'Zend/Validate/Barcode.php';
          $barcodeValidator = new Zend_Validate_Barcode('UPC-A');
          $barcodeValidator->setType('ISBN-13');
          if ($barcodeValidator->isValid($someBarcode)) {
          // ...
          ]]></ac:plain-text-body></ac:macro>

  3. Aug 03, 2007

    Darby Felton

    <p>The <code>INVALID</code> state may be better named <code>CHECKSUM_FAILED</code> or something similar.</p>

    1. Aug 06, 2007

      Andries Seutens

      <p>I agree.</p>

  4. Oct 03, 2007

    Matthew Ratzloff

    <p>Hi Andries,</p>

    <p>Be sure to make the component names conform to naming conventions.</p>

    <p><code>Zend_Validate_Barcode_ISBN13</code> to <code>Zend_Validate_Barcode_Isbn13</code><br />
    <code>Zend_Validate_Barcode_EAN13</code> to <code>Zend_Validate_Barcode_Ean13</code><br />
    <code>Zend_Validate_Barcode_UPC</code> to <code>Zend_Validate_Barcode_Upc</code></p>

    <p><ac:emoticon ac:name="smile" /></p>