Mapping dolibarr <-> react

So that the front end “knows” what type of data is being sent by the back end, dolibarr objects are “exposed” to the front end. As certain types of data on the dolibarr side do not exist identically on the front side, we have set up “mapping” mechanisms, the details of which you will find below.

To optimise exchanges between the back end (php) and the front end (react), we have chosen to allow data to be modified on the back end before being sent to the front end.

You can limit the list of fields that will be sent to the react application on the back end by simply reading the fields you want to export in the listOfPublishedFields variable, for example

the key is the name of the field in the dolibarr object and the value is the name you want to give on the react side:

	//corresponding fields left dolibarr right front app
	protected $listOfPublishedFields = [
		'rowid'=> 'rowid',
		'name'=> 'name',
		'address'=> 'address',
		'zip'=> 'zip',
		'town'=> 'city',
		'fk_departement'=> 'departement',
		'fk_pays'=> 'country',
		'phone'=> 'phone',
		'url'=> 'url',
		'email'=> 'email',
		'note_public'=> 'note_public',
		'note_private'=> 'note_private',
		'logo'=> 'logo'
	];

Then, when the data is formatted to be sent to react, a number of mechanisms will be implemented:

Imagine that you want to make the logo of the Company object accessible to the react application: the dolibarr object contains the name of the logo file and the react application expects to have a logo in the form of an encoded base64 field …

You can simply implement the fieldFilterValueXXXX function by replacing XXXX with the name of the field whose content you want to filter (with the 1st letter in uppercase). In our example, this would be fieldFilterValueLogo in your dmSociety mapping class.

	public function fieldFilterValueLogo($societe)
	{
		global $conf;
		// dol_syslog("##### dmHelper : call for fieldFilterValueLogo for " . $societe->logo);
		$dir = $conf->societe->multidir_output[$societe->entity] . "/" . $societe->id . "/logos";
		$logo = $dir . /' . $societe->logo;
		$logoBase64 = "";
		if (file_exists($logo)) {
			$type = pathinfo($logo, PATHINFO_EXTENSION);
		} else {
			$logo = dol_buildpath("/smartlivraisons/img/logo.png", 0);
			$type = pathinfo($logo, PATHINFO_EXTENSION);
		}
		$logoBase64 = 'data:image/' . $type . ';base64,' . base64_encode(file_get_contents($logo));
		// dol_syslog("##### dmHelper : returns " . strlen($logoBase64));
		return $logoBase64;
	}

Some Dolibarr objects are made up of lines (e.g. an invoice, a quote, an order form, etc.), so you need to

a) send a description of the lines to the front-end to find out what components need to be displayed to show the data (for example 4 columns: number id, text description, unit price, quantity, total) b) send the content of the rows

Unfortunately, not all Dolibarr objects are designed in exactly the same way (some have a Line prefix and others a Line prefix, for example FichinterLine and OrderLine), so we implemented the following solution:

On the other hand, Dolibarr objects all have a “fields” variable that describes the object, but the same does not apply to the description of the object lines, which makes it impossible to manage generic code on the front end.

DoliMobile provides a solution to this double problem: in the mapping description class of your object (example dmSmartinter) you can use

• a) parentClassNameForLines to indicate the name of the Dolibarr class which implements the object's lines.
• b) listOfPublishedFieldsForLines to indicate the list of fields you want to export and under what name (mapping dolibarr → application)
• c) parentLabelForLines to indicate the title (which will be translated) that you want to display above the list of lines on the application (for example “Details of invoice lines”)