Skip to end of metadata
Go to start of metadata

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: 20)

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

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

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

    Take a look at the backside of some books.

    • I would propose to name this component Zend_Validate_Isbn
    • I would propose to have an accessor to change/select the used isbn type... "auto" "10" "13" for example.
    • 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)
    • 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.

    1. May 06, 2009

      Renan de Lima

      nice Thomas,

      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

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

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

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

      1. May 07, 2009

        Thomas Weidner

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

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

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

        Code:
        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.

        1. May 08, 2009

          Renan de Lima

          Thanks Thomas for your help,

          yes, you are right, why should we look into barcode?

          i've changed API as you've suggested, options can be changed by initiation

          code, if you look at that, we can see there are some differences:

          • the length
          • sum value (ISBN-10 uses a desc sequence, ISBN-13 uses an alternate sequence [1,3] )
          • checksum value (it's different just because length, so it could be calculated using input length)

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

          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 quotemeta 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

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

          1. May 08, 2009

            Thomas Weidner

            Always a pleasure... looks good now.

            Just one note again
            When you provide a setXXX method, then you should also provide a getXXX method.

            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.

  2. Jun 05, 2009

    Thomas Weidner

    Renan,

    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".

    1. Jun 11, 2009

      Renan de Lima

      i sent a message to fw-general list last month

      http://www.nabble.com/Zend_Validate_Isbn---Proposal-tp23622649p23622649.html

      so there is no reply there, this proposal is now waiting for recommendation

  3. Jul 14, 2009

    Matthew Weier O'Phinney

    Zend Framework Approval
    This proposal is accepted for immediate development in the Standard Incubator, as-is.

  4. Jul 24, 2009

    Renan de Lima

    i realized that current validators don't use $options in __construct()

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

    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

    1. Jul 24, 2009

      Thomas Weidner

      @Renan:
      Old validators do not use them, new validators do.

      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).

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

      Note:
      You should not change accepted proposals

      Hint:
      You "could" accept both notations, but this can be problematic.

      1. Jul 25, 2009

        Renan de Lima

        good to know that this will be changed for 2.0

        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

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

        thanks

        1. Jul 25, 2009

          Thomas Weidner

          Your Zend liaison should be Matthew or Ralph.

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

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

          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.

          1. Jul 26, 2009

            Renan de Lima

            perfect,
            i'm gonna change it right now!

            Thomas, thanks a lot