| 1 |
4 |
bd |
=====================
|
| 2 |
|
|
QR Code data handlers
|
| 3 |
|
|
=====================
|
| 4 |
|
|
|
| 5 |
|
|
QR codes by themselves require strings as input. These strings may vary a *lot*. For instance, URLs can be provided with
|
| 6 |
|
|
at least three different syntax.
|
| 7 |
|
|
|
| 8 |
|
|
The main point of this extension is that it should be easy and quick to transfer CMS content to a QR code.
|
| 9 |
|
|
|
| 10 |
|
|
This is why handlers are required for datatypes, content classes...
|
| 11 |
|
|
|
| 12 |
|
|
Datatype handlers
|
| 13 |
|
|
=================
|
| 14 |
|
|
|
| 15 |
|
|
Datatype handlers are easy. Given one content object attribute, a handler will return a string that can be interpreted
|
| 16 |
|
|
by QR aware devices.
|
| 17 |
|
|
|
| 18 |
|
|
This is made possible by QRDatatype handlers.
|
| 19 |
|
|
|
| 20 |
|
|
Base, abstract class: eZQRDatatype
|
| 21 |
|
|
----------------------------------
|
| 22 |
|
|
|
| 23 |
|
|
This class is the base item when it comes to implementing a handler. It has to implement at least one method::
|
| 24 |
|
|
|
| 25 |
|
|
public function data();
|
| 26 |
|
|
|
| 27 |
|
|
This method returns a string that will be the data for the QR code. The class makes available a member variable named
|
| 28 |
|
|
``contentObjectAttribute``, that contains the currently handled content object attribute.
|
| 29 |
|
|
|
| 30 |
|
|
Settings: qrcode.ini
|
| 31 |
|
|
--------------------
|
| 32 |
|
|
|
| 33 |
|
|
This handler then needs to be mapped to a datatype. This is done in a very standard way, using an array in qrcode.ini.
|
| 34 |
|
|
|
| 35 |
|
|
This code example, in qrcode.ini, would map the eZQRDatatypeStuff handler to the ezstuff datatype::
|
| 36 |
|
|
|
| 37 |
|
|
[Datatypes]
|
| 38 |
|
|
Mapping[ezstuff]=eZQRDatatypeStuff
|
| 39 |
|
|
|
| 40 |
|
|
Content classes
|
| 41 |
|
|
===============
|
| 42 |
|
|
|
| 43 |
|
|
To be determined :)
|