Skip to end of metadata
Go to start of metadata

<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_Isbn Component Proposal

Proposed Component Name Zend_Validate_Isbn
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Validate_Isbn
Proposers Renan de Lima
Zend Liaison TBD
Revision 0.1 - 4 May 2009: Initial Release.
0.2 - 26 July 2009: Implementation, tests and documentation. (wiki revision: 21)

Table of Contents

1. Overview

Zend_Validate_Isbn is a component to check both ISBN-10 and ISBN-13 barcode formats.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • this will validate IBSN entries

4. Dependencies on Other Framework Components

  • Zend_Validate

5. Theory of Operation

This component classes implements Zend_Validate_Abstract, so it looks like others Zend_Validate classes.

6. Milestones / Tasks

  • Milestone 1: [DONE] proposal finished
  • Milestone 2: [DONE] proposal accepted
  • Milestone 3: [DONE] implementation, tests and documentation
  • Milestone 4: [DONE] moved to core

7. Class Index

  • Zend_Validate_Isbn

8. Use Cases

9. Class Skeletons

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

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

Labels:
proposals proposals Delete
validate validate Delete
barcode barcode Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

13 Comments

comments.show.hide

  1. May 05, 2009

    Thomas Weidner

    <p>ISBN Numbers are not related to Barcodes.<br />
    Of course they are used in relation with them, but they are also often used without barcodes.</p>

    <p>Take a look at the backside of some books.</p>

    <ul>
    <li>I would propose to name this component Zend_Validate_Isbn</li>
    </ul>

    <ul>
    <li>I would propose to have an accessor to change/select the used isbn type... "auto" "10" "13" for example.</li>
    <li>I would propose to use only 3 error messages... there is no need to differ between 10/13 within the messageId as you can do this simpler with a second parameter (selected by accessor described above)</li>
    </ul>

    <ul>
    <li>I would also propose to make only one isValid method... 10 and 13 use a closely related validation algorithm... there is no need to duplicate it... this would also simplify the code.</li>
    </ul>

    1. May 06, 2009

      Renan de Lima

      <p>nice Thomas,</p>

      <p>topic 1: i've called this as Barcode_Isbn just because we don't need worry about non-numeric (and X for ISBN-10) character. Anyway if this component can't belong to barcode it must be able to read inputs that contain hyphen and space</p>

      <p>topic 2: you propose about type "changing" looks good, this could be easier to use. Something like:<br />
      $validator = new Zend_Validator_Isbn();<br />
      $validator->setType( Zend_Validator_Isbn::TYPE_AUTO )->isValid('...');<br />
      $validator->setType( Zend_Validator_Isbn::TYPE_10 )->isValid('...');<br />
      $validator->setType( Zend_Validator_Isbn::TYPE_13 )->isValid('...');</p>

      <p>topic 3: if your second topic is accepted we would use 3 error message as you said</p>

      <p>topic 4: actually the validation algorithm is not so complex, but they have different rules. Due that i propose two methods</p>

      1. May 07, 2009

        Thomas Weidner

        <p>The reason is that barcodes are stripes of white and black used for product notations in the industry.</p>

        <p>ISBN Numbers are related to books and you can find many ISBN numbers written without barcodes.<br />
        So when I want to check for a ISBN number, why should I look into barcode ?<br />
        For the user this would be irritating.</p>

        <p>Also keep in mind that options are also set by initiation:<br />
        $validator = new Zend_Validate_Isbn(array('type' => Zend_Validate_Isbn::ISBN13));</p>

        <p>Code:<br />
        Both isValid methods use 80% of same code.... I see only 2 differences: The used regex and the length. But those 2 changes should not be the reason to write 2 times the same code. 40 lines reduction without loss of readability are no problem. As there are no other ISBN standards available it's no problem.</p>

        1. May 08, 2009

          Renan de Lima

          <p>Thanks Thomas for your help,</p>

          <p>yes, you are right, why should we look into barcode?</p>

          <p>i've changed API as you've suggested, options can be changed by initiation</p>

          <p>code, if you look at that, we can see there are some differences:</p>
          <ul>
          <li>the length</li>
          <li>sum value (ISBN-10 uses a desc sequence, ISBN-13 uses an alternate sequence <ac:link><ri:page ri:content-title="1,3" /></ac:link> )</li>
          <li>checksum value (it's different just because length, so it could be calculated using input length)</li>
          </ul>

          <p>i've grouped both validation methods in isValid(), it looks clean now</p>

          <p>I tried to make easer the usage. Users may use hyphen or another separator. I've put as a operation setSeparator(), i think this method can receive a string with none, one or unlimited characters. Internal code can use <a href="http://php.net/quotemeta">quotemeta</a> to make REs, some separators can't be used, as X for ISBN-10 and numbers. I thought we can use an array as well, but i can't allow separator greater than one character</p>

          <p>we can know witch one format is in use looking at "separator" and "allowed type"</p>

          1. May 08, 2009

            Thomas Weidner

            <p>Always a pleasure... looks good now.</p>

            <p>Just one note again <ac:emoticon ac:name="smile" /><br />
            When you provide a setXXX method, then you should also provide a getXXX method.</p>

            <p>When you think that you're ready, move your proposal to the next proposal step and inform the community so they can do a review.</p>

  2. Jun 05, 2009

    Thomas Weidner

    <p>Renan,</p>

    <p>you should write a information mail on the zf-mailing list and when done and there is no more reply, move your proposal into "request for recommendation".</p>

    1. Jun 11, 2009

      Renan de Lima

      <p>i sent a message to fw-general list last month</p>

      <p><a class="external-link" href="http://www.nabble.com/Zend_Validate_Isbn---Proposal-tp23622649p23622649.html">http://www.nabble.com/Zend_Validate_Isbn---Proposal-tp23622649p23622649.html</a></p>

      <p>so there is no reply there, this proposal is now waiting for recommendation</p>

  3. Jul 14, 2009

    Matthew Weier O'Phinney

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Framework Approval</ac:parameter><ac:rich-text-body>
    <p>This proposal is accepted for immediate development in the Standard Incubator, as-is.</p></ac:rich-text-body></ac:macro>

  4. Jul 24, 2009

    Renan de Lima

    <p>i realized that current validators don't use $options in __construct()</p>

    <p>so, i'll change the current signature<br />
    <strong>public function __construct(array $options = array());</strong><br />
    to<br />
    <strong>public function __construct($type = self::AUTO, $separator = '');</strong></p>

    <p>i was suppose to propose that every Zend_Validate_* class should use $option (assoc array) or Zend_Config in __construct, but i think it's not necessary, it's simpler use named arguments for that</p>

    1. Jul 24, 2009

      Thomas Weidner

      <p>@Renan:<br />
      Old validators do not use them, new validators do.</p>

      <p>Actually all validator and also filter must be rewritten to use a options array as they otherwise can not be used with Zend_Config nor with Zend_Form (problem when parameters are switched by the user).</p>

      <p>Your change of the already accepted proposal reintroduces the old behaviour which will be erased with 2.0.</p>

      <p>Note:<br />
      You should not change accepted proposals <ac:emoticon ac:name="wink" /></p>

      <p>Hint:<br />
      You "could" accept both notations, but this can be problematic.</p>

      1. Jul 25, 2009

        Renan de Lima

        <p>good to know that this will be changed for 2.0</p>

        <p>but current version is not 2.0, anyway this proposal does not have a zend liasion... so do i have to answer for every decision about this class? i know this is a small class, it's not so important, but i'm trying this one just to get the community clockwork</p>

        <p>i agree with what you said, but i'll wait a bit more<br />
        if someone else doesn't say anything i will change it back</p>

        <p>thanks <ac:emoticon ac:name="wink" /></p>

        1. Jul 25, 2009

          Thomas Weidner

          <p>Your Zend liaison should be Matthew or Ralph.</p>

          <p>But actually I am supporting all validation and filter components.<br />
          This was also the reason why I helped you in getting this class ready in a way it should look and work.</p>

          <p>Yes, you should answer all questions for your component / proposal.<br />
          And there is no "small" class... eighter it's part of ZF or it's not.</p>

          <p>What I say is: Your component was accepted "as-is"... this means without changes... Matthew had already the changes for 2.0 in mind which I am working on for all validators as he approved this component. <ac:emoticon ac:name="smile" /></p>

          1. Jul 26, 2009

            Renan de Lima

            <p>perfect,<br />
            i'm gonna change it right now!</p>

            <p>Thomas, thanks a lot <ac:emoticon ac:name="smile" /></p>