#activemodel

TL;DR l'ensemble du code de cet article a été compilé en une Rubygem disponible sur Github.

Serialize

Avec un peu de chance, cette méthode macro de ActiveRecord ne vous aura pas échappé :

client.rb

Vous n'êtres probablement pas sans savoir qu'elle prend un deuxième paramètre qui détermine le seul type de donnée qui peut être sérialisé. Sans quoi, tout ce que vous passez à contact sera sérialisé en règle.

client.rb

En deuxième paramètre, elle peut prendre n'importe quelle classe pour peu que vous passez à instance.contact= des instances de cette même classe.

client.rb

Dans vos formulaires, vous pouvez utiliser .fields_for comme vous l'utiliseriez pour une association

new.html.erb

Cette méthode rend énormément service, mais a l'inconvénient d'être malgré tout peu structurée. Que vous lui passiez un Hash ou un Struct ou une classe toute faite avec accesseurs, ses données ne bénéficieront ni de validation ni de cast (forçage de typage), ni de valeurs par défauts.

Nous allons donc élaborer une solution qui répond à ces besoins tout en reposant sur les mêmes mécanismes utilisés par ActiveRecord.

client.rb

Surcharger serialize

La première chose à faire est de permettre à serialize de prendre un bloc comme paramètre. Nous faisons cela en mettant une nouvelle méthode serialize devant celle qui se trouve dans ActiveRecord::AttributeMethods::Serialization::ClassMethods.

CODE : VirtualAttributes::Serialization::ClassMethods CODE : VirtualAttributes

La nouvelle méthode serialize prend un bloc optionnel. Si ce bloc est absent, c'est la méthode serialize "classique" qui est appelée, autrement nous déclenchons la procédure de construction de notre sous-modèle.

Construite notre sous-modèle 

Nous avons donc un block que nous pouvons maintenant utiliser pour construire notre sous-modèle. Ce dernier est une classe qui sera dynamiquement créée et placée sous le namespace du model principal. 

CODE : VirtualAttributes::Serialization v2 CODE : VirtualAttributes::Base CODE : client.rb

La classe hérite de VirtualAttributes::Base qui contiendra la logique nécessaire pour créer les attributs. const_set est ensuite utilisée pour placer cette classe dans le namespace adéquat. Yield permet d'appeler des méthodes de classe pour ajouter les colonnes qu'on veut. Nous faisons enfin un appel à la version originale de `serialize` (via super) en spécifiant cette fois notre nouvelle classe comme type de sérialisation.

L'ajout des attributs se fera via la méthode de classe `column` que nous allons implémenter dans un module séparé :

CODE : VirtualAttributes::Base::Attributes CODE : VirtualAttributes::Base avec un simple `include`

Nous pouvons déjà ajouter des colonnes mais elles ne seront pas typées :

CODE : client.rb

Place aux types maintenant :

Ajouter des attributs typés

Nous allons tenter d'implémenter une interface similaire à celle des migrations de Ruby on Rails. Pour cela, il nous faut une méthode pour chaque type disponible : nous allons utiliser la liste des types disponibles par le SGBD en cours d'utilisation, exception faite du type :primary_key pour des raisons évidentes.

CODE : VirtualAttributes::Base::Casts CODE : VirtualAttributes::Base avec un simple `include`

Toujours dans une approche modulaire, VirtualAttributes::Base::Casts surchargera et utilisera certaines méthodes de module Attributes. Il s'agit de la méthode de classe `column` et de la méthode d'instance `write_attribute`. 

Lorsque le module Casts est inclu, il modifie la liste des arguments de la méthode column de Attributes (en ajoutant le paramètre type) mais continuer d'utiliser cette "version" qui ne prend que deux paramètres. C'est une sorte de limitation de responsabilité verticale, qui traverse la chaine.

La nouvelle version de write_attribute fait la même chose, sauf qu'elle ne modifie pas la liste des paramètres, elle altère la valeur de l'un d'entre eux (!), pour effectuer la conversion de type (type cast).

Cette conversion se fait via le flambant neuf module ActiveRecord::Type, qui a profondément remodelé la conversion de type sur Rails 4.2. Ce module est utilisé par les différents adaptateurs de SGBD (mysql, postgres, sqlite, etc...) afin de gommer les différences qui existent entre leurs types natives de données.

Dans notre cas, puisque les données seront sérialisées et stockées dans un champ texte tout bête, nous n'avons pas besoin d'utiliser un adaptateur spécifique. Les classes génériques présentes dans ce module suffiront.

En fonction du type de la colonne, notre code instancie la bonne classe (ActiveRecord::Type::Float, Decimal, String, Binary...) et la met à la disposition de la méthode cast_type.

Nous créons par la suite une méthode de classe correspondant à chaque type. Ces méthodes délèguent toutes à `column` en lui passant le type adéquat (lignes 27-35).

Utiliser des valeurs par défaut

Passer des valeurs par défaut était déjà prévue dans le paramètre "options" de column.

Le module Defaults surcharge read_attribute pour intervenir dans le cas où read_attribute du module Attributes, appelé avec `super` retourne `nil`.

CODE : VirtualAttributes::Base::Defaults CODE : VirtualAttributes::Base avec un simple `include`

Toujours suivant les méthodes des migrations, nous ajoutons des valeurs par défaut. Et ça marche !

CODE : client.rb

Des valeurs par défaut exécutables

Vous avez probablement déjà fait face à une situation qui nécessite une valeur par défaut dynamique. Le constat est vite fait conclu que ce n'est pas faisable via la valeur par défaut des migrations. Une solution est de n'attribuer aucune valeur par défaut à votre champ et contourner cela dans after_initialize.

Mais nous ne sommes pas confrontés à cette limitation ici. La valeur par défaut est stockée en mémoire, dans l'attribut de classe `columns`.

Autorisons alors que ce paramètre soit un bloc exécutable : 

CODE : VirtualAttributes::Base::Defaults CODE : client.rb Et enfin, les validations !

Nous continuons sur la lancée modulaire en ajoutant le module Validations. Pourtant, celui là ne fait qu'inclure le module ActiveModel::Validations. 

CODE : VirtualAttributes::Base::Validations CODE : VirtualAttributes::Base avec un simple `include`

Sa présence est tout de même importante dans ce qui suit. Nous devons ajouter une validation à chaque champ sérialisé avec notre solution.

CODE : VirtualAttributes::Serialization avec validates attr_name, virtual_attributes: true et VirtualAttributesValidator

La validation se fait via un custom validator de type EachValidator. La logique de validation ne s'exécute que si la classe utilisée inclut le module VirtualAttributes::Base::Validations.

L'ensemble des erreurs éventuelles présentes dans les instances de la classe dynamique sera regroupée dans une même erreur.

Utiliser les champs virtuels dans les formulaires

Les champs peuvent être utilisés dans vos views à l'aide de `.fields_for`. Ainsi, de manière identique aux formulaires classiques

CODE : new.html.erb

Mais au moment de l'envoi du formulaire, le champ serialisé reçoit une instance de ActionController::Parameters et non une descendante de VirtualAttributes::Base. Cette instance sera rejetée, car le type a été strictement spécifié au moment de la génération.

Nous devons intervenir à cet endroit précis pour convertir le paramètre reçu en une instance de la bonne classe !

CODE VirtualAttributes::Serialization

Nous avons défini le attr_writer de notre champ. Mais avant de le passer à super, nous appelons Wrap du nouveau module Conversions

CODE VirtualAttributes::Base::Conversions CODE VirtualAttributes::Base include conversions

Si la valeur reçue est une instance de Hash, nous l'utiliserons pour créer une nouvelle instance du bon type : 

CODE VirtualAttributes::Base::Attributes (initialize)

Bingo !

Et le tour est joué. Les formulaires de création et d'édition gèrent très bien la lecture et l'écriture dans nos champs virtuels, qui bénéficient de la conversion de type et de la validation tout en supportant des valeurs par défaut statiques et dynamiques.

Conclusion

Nous avons passé en revue l'ensemble des composants qui peuvent entrer en jeux pour élaborer des solutions robustes et extensibles d'ajouts de champs virtuels à vos tables.

Dans bien des cas, le besoin de déclarer des callbacks au niveau de l’instance se fait sentir. Prenons l’exemple d’une application qui interagit avec un webservice pour l’un de ses modules. Un appel d’API à ce service doit être lancé pour inscrire ou désinscrire l’application quand le module est activé / désactivé

Pour notre exemple, l’action se déroule autour du model Configuration qui contient les réglages de chacun des clients qui utilisent votre application multitenant.

Vous mettez à disposition de chaque client un formulaire qui permet de sélectionner les modules activés, dont celui qui nécessite un appel d’API.

Vous pouvez accomplir cela de plusieurs manières, plus ou moins perfectibles

Tout faire dans le contrôleur

CODE 1

Inutile de rappeler que toute logique ajoutée au contrôleur devrait être vue d’un mauvais œil. D’autant qu’il s’agit là d’une action spécifique au modèle que nous interceptons au moment du changement de ce dernier.

Utiliser un callback au niveau du modèle

CODE 1

CODE 1

Ça va tout de suite mieux, l’activation/désactivation du module est interceptée après l’enregistrement. Notons au passage le “true” à la fin du callback. Comme les méthodes subscribe/unsubscribe sont susceptibles de renvoyer false au cas où l’appel d’API échoue, il devient nécessaire de spécifier la valeur de retour de la méthode. Rappelons que le moindre false comme valeur de retour d’un callback halte toute la chaine d’exécution et foire silencieusement l’action qui l’a déclenche. On ne le rappellera jamais assez !

Faire mieux ?

Mais comme expliqué dans l’introduction, cela encombre la chaine des callbacks et pollue la déclaration du modèle avec des appels de macros pourtant très contextuels.

Une solution est d’intercepter l’activation/désactivation au moment même de l’écriture de cette information, de cette manière :

CODE 1

C’est plus satisfaisant, la logique se fait au niveau du writter accessor et ce code ne s’exécute que lorsqu’une valeur est effectivement passée. Si vous avez un autre formulaire dédié qu’aux informations du client sans les modules, ce code ne s’exécutera pas. Mais il a un défaut très handicapant : l’appel d’API se fait sans être certain que l’enregistrement se fera. Si l’action échoue à la validation ou à un autre callback qui renvoi false, on aura inscrit la plateforme alors que le module reste désactivé !

Cette méthode peut pourtant servir, dans l’état, sans callbacks, pour exécuter du code SQL réversible. update_attributes (qui repose sur .save) s’exécute et exécute tous les callbacks dans une transaction. Si le moindre pépin arrive, un rollback est effectué.

Des callbacks à l’exécution

Alors, pour les actions irréversibles, comme l’appel d’une API externe ou l’envoi des emails, sommes-nous condamnés à suivre la piste des callbacks classiques ?

Oui à moins de créer une alternative qui nous permettrait de faire ceci :

CODE 1

Pour y arriver, essayons de comprendre le fonctionnement des callbacks. Qui ne relève d’aucune magie.

Comprendre les callbacks

Les callbacks tels qu’on les connaît sont un module de ActiveModel extrait historiquement de ActiveRecord. Ils peuvent être utilisés par n’importe quelle class pour exécuter du code avant, après ou autour des appels de certaines méthodes.

Leur utilisation commence (et se termine) par la simple inclusion du module ActiveModel::Callbacks dans vos classes et la déclaration de là où les méthodes auxquelles vous voudriez adjoindre des callbacks et une petite modification de celles-ci.

CODE

> talkin = Talking.new > talkin.sentence = "I talk to the wind" > talkin.talk > "I talk to the wind"

CODE

> talkin = WiseTalking.new > talkin.sentence = "I talk to the wind" > talkin.talk > "***Thinking*** ***meditate***" > "I talk to the wind" > "But I do not hold the truth"

Réalisation

Nous utiliserons ce même mécanisme pour réaliser les callbacks au runtime. Cette capacité sera conférée à vos modèles par l’inclusion d’un module, qui permettra à chaque instance de créer sa propre chaine de callbacks.

CODE

Étant donné que les callbacks ne peuvent être définis que sur des classes. Nous allons créer pour chaque instance qui appelle #callbacks une classe qui hérite de ChainBase. En Ruby, les classes ne sont que des instances de la classe Class. Ce qui explique la syntaxe Class.new(ChainBase). Passer une classe existante en paramètre au constructeur de Class en fait la classe parente (d’où hérite la classe en cours de création). Notons que cette syntaxe crée une classe anonyme, qui prendra le nom de la première constante à laquelle elle se verra attribuée. Nous pouvons dors et déjà créer des callbacks

class Message < ActiveRecord::Base include RuntimeCallbacks end > m = Message.new > m.callbacks.after_save :do_something > m.callbacks._save_callbacks 1 => [#<ActiveSupport::Callbacks::Callback:0x007fc08db46338 @klass=#<Class:0x007fc08db4dd90>, @kind=:after, @chain=[...], @per_key={:if=>[], :unless=>[]}, @options={:prepend=>true, :if=>["!halted && value != false"], :unless=>[]}, @raw_filter=:do_something, @filter=:do_something, @compiled_options="true && (!halted && value != false)", @callback_id=25753>]

Cependant, les callbacks sont définis au niveau des classes, mais toujours exécutés sur des instances. Il nous faut donc également une instance de notre classe qui descend de ChainBase.

CODE

Nous allons faire en sorte que cette chaine de callbacks soit exécutée. Pour ce faire, il faudra qu’on ajoute à la classe originelle un callback unique par type de callback qui déclenche la chaine de callbacks au runtime, si cette chaine existe.

CODE

Verbeux certes, mais facile à refactoriser et surtout fonctionnel :

class Message < ActiveRecord::Base include RuntimeCallbacks end > message = Message.new > message.callbacks.after_validation{ puts "Runtime callback works !" } > message.save => "Runtime callback works !"

Mais il existe un gros problème. L’instance où sont exécutés ces callbacks n’a aucune connexion avec le modèle. Ce qui empêche de lancer des callbacks sur des méthodes comme message.callbacks.after_validation :some_method

Nous pouvons y résoudre de manière extrêmement simple en faisant de cette instance un décorateur de l’instance première.

CODE

Les instances des sous-classes de ChainBase délégueront ainsi tous les appels qu’elles ne savent pas interpréter à l’instance originale.

Premières améliorations

Commençons par soigner l’interface. Cachons `.callbacks` et exposons à sa place les différents callbacks (after_save, before_validation...). C’est d’ailleurs le moment d’isoler leur liste :

CODE

Nous utilisons ici le module Forwardable pour transférer les appels aux méthodes after_* / before_* au produit de la méthode callbacks, qui devient privée.

Au runtime, vraiment ?

Notons que l’usage du mot runtime ou dire à l’exécution manque de précision, car même les callbacks définis dans la déclaration de la classe sont dynamiquement créés lors du chargement du fichier de code du modèle.

Conclusion

Tant d’améliorations peuvent être discutées et apportées à notre solution, mais l’idée est là : alléger vos modèles et placer la logique à l’endroit exact où s’effectue la modification des données qui en dépend.