439
edits
Module CustomFields Dev: Difference between revisions
Jump to navigation
Jump to search
→JSON extension for extra options
(→To Do) |
|||
| Line 74: | Line 74: | ||
Nevertheless, these missing cleanup functionalities won't be seen by your users because they will never be accessible: on deletion of an object, the custom fields won't ever be accessible again from Dolibarr's interface, and object's ids are never changed since Dolibarr also relies on this. Thus in compatibility mode, CustomFields will act just like normally, but your database will be a bit less clean. | Nevertheless, these missing cleanup functionalities won't be seen by your users because they will never be accessible: on deletion of an object, the custom fields won't ever be accessible again from Dolibarr's interface, and object's ids are never changed since Dolibarr also relies on this. Thus in compatibility mode, CustomFields will act just like normally, but your database will be a bit less clean. | ||
= JSON extension for extra options = | |||
== Introduction to JSON in CustomFields == | |||
The relational model is very great to store and fetch data with a declarative language, and this is very powerful, but this model also imposes a few limitations, for example the relations must be well formatted and predefined. | |||
That's why we finally implemented a '''JSON extension''' to manage '''extra options''' and associate them with custom fields. This allows to add many properties (or columns if you are more used to the relational model) on-the-fly without having to predefine them prior to storing and using them. | |||
This allows to add an undefined number of columns/properties/extra options that will help manage special behaviours for custom fields. For example, it is currently used to allow to change the order of appearance of custom fields, and to store and manage remote table and columns datas for constrained fields on DBMS that do not support Foreign Keys checks. | |||
We chose JSON over XML because the library are simpler and the data footprint smaller, and because CustomFields does not need advanced features of XML like XQuery, data typing and meta structures (at least not for now). | |||
The other advantage is that php objects can directly be encoded into JSON without any preprocessing, and can then as straightly be decoded from JSON back into a php object. | |||
A simple mean to encode and decode back an object into and from a storage place was the main requirement, and JSON (+ JSON libraries for PHP) meet this criteria. | |||
== Implementation of JSON == | |||
The implementation is very simple: a table called '''llx_customfields_extraoptions''' is created when you enable the CustomFields module, and this table only contains three columns: | |||
* table_name (varchar) | |||
* column_name (varchar) | |||
* extraoptions (blob) | |||
(table_name, column_name) both forms the primary key of the table, and links to columns (custom fields) of other customfields tables. | |||
extraoptions is a blob, which allows to store the data as binary (as-is) without encoding (which solves a big problem of JSON which is encoding special and foreign characters, here there is no problem at all). | |||
== CustomFields JSON API == | |||
To continue... | |||
= Architecture = | = Architecture = | ||