| Zend_Validate_Barcode_ISBN13 - Andries Seutens |
Zend Framework: Zend_Validate_Barcode_ISBN13 Component Proposal
| Proposed Component Name | Zend_Validate_Barcode_ISBN13 |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Validate_Barcode_ISBN13 |
| 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_ISBN13 is a simple component that validates the validity of an ISBN13 barcode.
2. References
- ISBN-13 Wikipedia Entry
- Jira issue (I personally dislike having ISBN-10 and ISBN-13 wrapped in one class....
3. Component Requirements, Constraints, and Acceptance Criteria
- This component will validate the validity of an ISBN13 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_ISBN13
8. Use Cases
| UC-01: validating barcode |
|---|
| UC-02: retrieving invalid barcode message |
|---|
9. Class Skeletons
I agree, but we have to set some rules on how we define a valid ISBN13 barcode then. Eg:
- are dashes obligated for a valid isbn? eg "99921-58-10-7" or "9992158107", or both?
- what shall we do with the ISBN prefix? eg "ISBN 99921-58-10-7" Consider it valid, or not?
These are good questions, since it is likely that some applications would want to allow input of dashes to be valid, for example.
I think we should focus on the validation of the barcode number itself, since they are the only characters relevant to the checksum algorithm that the validator performs.
Let's assume a simple situation where an application accepts some input string to be used as an IBSN barcode for searching a book catalog. The first thing to do is to filter the string of all but digit characters, because only the digit characters matter for the checksum algorithm. The digits are verifed using a validator before tasking the database with a more expensive search operation on the input. This can be achieved by running Zend_Filter_Digits on the input before validating it (e.g., Zend_Filter_Input supports this nicely). If the database stores the ISBN as all digits, then we have no problems. But let's now assume that the database stores the ISBN as a string with dashes in appropriate places (e.g., "99921-58-10-7"). Another [escaping] filter is needed to transform the data from Zend_Filter_Digits (i.e., "9992158107" needs to become "99921-58-10-7"). A custom filter can be written for this purpose rather easily.
In short:
- dashes are not allowed for input ISBN; they should have been stripped by the time the string is input to the validator
- prefix of "IBSN" is not allowed; any prefixes and suffixes should have been filtered out by the time that the input string reaches the validator
| Zend Comments This component is approved for incubator development, during which the issues above may be addressed. Also to consider:
|
ZF Home Page
Code Browser
Wiki Dashboard
Generally, I subscribe to the idea of being flexible with respect to allowed input and being careful with output. This validator filters all characters of the input that are not digits, which meets the first goal - being flexible with input to the validator. But such automatic filtering may also have unintended consequences for users that break the second goal - being careful with output from the validator. Consider the the following:
In this scenario, the user mistakenly believes that because the input value validates successfully, it is safe to enter it into the database. If, for example, the column type is CHAR(13), then we have a problem.
I suggest removing the automatic digit filtering; users can use this validator in combination with Zend_Filter_Digits and Zend_Filter_Input as needed.