Gen liquid templates #16

StevenWatremez · 2017-04-20T17:03:27Z

Decodable template is under tests and discussions.
Java template was not implemented. It will be for a next PR. So you can still use Java generation like before.

This will fix both #3 and #8

…el objects from json

This reverts commit 6704dd8.

…inary

AliSoftware · 2017-04-20T17:12:31Z

lib/gyro/utils/file_utils.rb

+        Gyro::Error::exit_with_error('You need to specify right template directory using --template option (see --help for more info)')
+      end
+    else
+      template_dir_to_test = Pathname.new("data/templates/") + template_dir_to_test


Du coup ce qu'on avait vite-fait vu avec DataDir ça marche pas ?

Alors pour ce point j'ai creusé un peu sur DataDir et je n'arrive pas à l'utiliser.
Cela s'utilise comme ça Gem.datadir('gem_name'). L'utilité de ce répertoire est de fournir de la data en public. Pour que par exemple d'autres scripts ruby puisse piocher dans le datadir. Parfait sauf que je n'ai pas réussi à l'utiliser en interne dans gyro.

Ah mince. Que retourne Gem.datadir('gyro'), ça retourne Nil? Peut être que c'est parce qu'il va chercher dans le dossier système où la gem est installée (plutôt que le répertoire local où tu es en train de bosser sur 'gyro') et que c'est pour ça qu'il ne le trouve pas ? Ou bien peut être faut il déclarer son chemin relatif quelque-part genre dans la gemspec pour qu'il sache où le chercher (et que le nom "./data" pour ce répertoire n'est alors pas automatiquement inféré)?

Je vais encore investiguer. J'avais pas pensé au gemspec. Merci du conseil.

Bon de ce que je lis de l'implémentation (https://apidock.com/ruby/Gem/datadir/class), la méthode Gem.datadir(gem_name) fait ceci:

def self.datadir(gem_name) spec = @loaded_specs[gem_name] return nil if spec.nil? File.join spec.full_gem_path, "data", gem_name end

Autrement dit ça prend le chemin où est installé la gem (du coup quand tu testes en local je sais pas ce que ça donne, mais je pense que ça marche quand même puisque tu as mis "./lib" dans le LOAD_PATH et que tu as "require 'gyro'" ainsi…? Mais bon j'en suis pas complètement sûr), et ça concatène ça avec "data/#{gem_name}". Donc on serait sensé faire un dossier "gyro/data/gyro/template" pour le faire fonctionner? Bon en plus j'ai un peu l'impression que c'est déprécié, du coup pas sûr que ça vaille le coup de se prendre la tête là dessus.

Le principal c'est de vérifier que ça continuera de marcher une fois installé sous forme de gem, en particulier si on fait gem install gyro est-ce que ça installe aussi le dossier data/templates et est-ce que le code pour trouver son chemin marche toujours comme il marchait lors des tests en local.

AliSoftware · 2017-04-20T17:14:11Z

lib/gyro/xcdatamodel/parser/relationship.rb

@@ -41,6 +41,14 @@ def initialize(relationship_xml, entity_name)
          search_for_error
        end

+        def to_h
+          return { 'entity_name' => entity_name, 'name' => name, 'type' => "#{type}", 


Pourquoi faire une interpolation avec "#{type}" plutôt que d'utiliser type directement comme pour les autres (ou type.to_s au pire si ce n'est pas une string mais que tu veux en faire une string)?

My bad. J'ai dû oublié de virer ça. Je me rappelle plus pourquoi mais je pense pas que ça soit utile. Erreur de débutant. :)

AliSoftware · 2017-04-20T17:17:52Z

spec/fixtures/swift/enum/Type.swift

-    case TypeOne = "type_one"
-    case TypeTwo = "type_two"
-    case TypeThree = "type_three"
+  case typeOne = "TypeOne"


C'est normal que maintenant ça soit bindé à la rawValue "TypeOne" (pour quand tu parseras en JSON), plutôt que "type_one" comme c'était le cas pour la fixture avant? C'est le comportement du template qui a changé?

Dans mon template la génération de la rawValue des enums est faite avec la JSONKey si il y en a une sinon on prend la nameValue. Dans le enum.xcdatamodel il n'y a pas de JSONKey associée pour l'enum type, donc mon template n'a pas pu en générer. Je me rappelle d'une chose un peu bizarre dans l'ancien code qui construisant quand même une rawValue en snake_to_camel_case. Est ce utile ? Je peux le faire si besoin.

Tu veux dire que le type_one qu'il y avait avant était totalement calculé par code via un snake_to_camel_case?
Bizarre qu'on ait fait ça je vois pas trop la raison… (à part si c'est parce que c'était la convention utilisée sur le projet monoprix pour lequel dbgen a été créé et que du coup on a hardcodé ça à l'époque…?)

Faudrait que je recherche mais en tout cas ça ne vient pas du .xcdatamodel car il ne contient pas la clé type_one mais une nameValue TypeOne.

Normalement ça ça ne viendrait pas tant de la clé JSONKeyPath (qui donne le nom de la clé JSON pour l'attribut que tu cherches à décider, pour la clé dans le JSON quoi) mais plutôt de la clé JSONValues (qu'il faut renseigner quand tu mets aussi la clé enumValues), qui est sensé lister toutes les valeurs possibles qu'on peut rencontrer pour cet attribut et les faire correspondre avec la liste des enumValues. Cf README

https://github.com/NijiDigital/gyro/blob/master/spec/fixtures/xcdatamodel/enum.xcdatamodel/contents
Dans le contents on voit bien qu'il n'y a même pas de JSONKeyPath. Il y a juste enumType et enumValues. Moi en tout cas j'ai fait les templates avec un fallback sur les enumValues au cas où il n'y aurait pas de JSONValues.

Et donc on voit que la transformation a pu se faire que part code. Faudrait que je cherche la fonction. Mais je ne sais pas pourquoi cette transformation.

Ça vient apparemment de ce code: https://github.com/NijiDigital/gyro/blob/master/lib/gyro/realm/swift/enum_generator.rb#L58-L62

Si on n'a pas en JSONValues on les construit à partir des enumValues qu'on underscore.
Je ne sais pas d'où ça vient et pourquoi on a fait ça (surtout, pourquoi on les underscores, c'est un peu un choix arbitraire…). A la limite si on a pas de JSONValues on pourrait alors prendre les enumValues directement, ça aurait du sens, mais pourquoi prendre les enumValues et les passer en underscore, ça… je pense que c'est un reliquat des conventions Monoprix et qu'on peut s'en débarrasser, pour utiliser les enumValues telles quelles si pas de JSONValues effectivement du coup, un peu comme tu as l'air d'avoir fait vu le nouveau résultat dans la fixture donc.

Ok moi ça me va aussi. Je pense que ça sera plus simple de compréhension pour l'utilisateur. S'il veut faire un traitement spécifique il pourra le faire dans un template custom.

Tout à fait. Ou bien lister explicitement tous les cas dans son xcdatamodel en précisant explicitement le JSONValues si elles sont différentes des enumValues.

AliSoftware · 2017-04-20T17:24:18Z

data/templates/decodable/root.liquid

+      {% assign attributeKey = attribute.name -%}
+      {%- if attribute.transformer.empty == false -%}
+        {%- assign attributeKey = attribute.json_key_path -%}
+      {%- endif -%}


Je ne suis pas sûr de bien comprendre la logique ici. La variable attributeKey est affectée à json_key_path… seulement s'il y a un transformer? Quel rapport ? Pourquoi s'il n'y a pas de transformer on ne prend pas la valeur de l'attribut JSONKeyPath mais le nom de l'entité? C'est nouveau comme comportement…

Je ne sais plus ce qu'on avait décidé comme comportement pour dbgenerator, s'il n'y a pas la clé JSONKeyPath est-ce qu'on décide alors d'ignorer la propriété lors du parsing JSON, et on ne va même pas essayer de la lire du JSON… ou est-ce qu'on disait qu'on supposait alors que la clé du JSON état dans ces cas là sensée avoir le même nom que l'attribut ? (mais dans ce cas pouvait-on indiquer pour un attribut donné qu'on ne souhaitait pas du tout l'include dans le décodage JSON, au cas où ce genre de cas se présentait sur un projet?)

En tout cas il faut garder le même comportement, et utiliser la clé JSONKeyPath si elle est présente… qu'il y ait un transformer custom ou non

C'est un oublie de correction. Normalement c'est if attribute.json_key_path.size > 0. Je vais corriger ce souci.

StevenWatremez · 2017-04-24T12:16:44Z

Il y a un problème. Liquid requiert ruby >= 2.1.0, par chance moi j'avais la 2.3.0 avec rvm mais ceux avec qui j'ai testé à Niji ont de base la 2.0.0 avec macOS Sierra si je dis pas de bêtise. J'ai testé des version plus ancienne de la gem Liquid mais y a des fonctionnalitées qui sautent comme les include. Le problème c'est que l'on va pas demander à chacun de toucher aux versions de ruby. Enfin je te log ça pour voir si tu aurais une idée. @AliSoftware

StevenWatremez · 2017-04-26T15:52:47Z

Je reviens sur une remarque que tu as fait au sujet du "#{type}". Le truc dont je me suis encore cassé les dents aujourd'hui en bossant sur le template Java. C'est qu'au lieu de m'envoyer la string "integer_16" pour un type il me renvoie le symbole :integer_16 ce qui pose un souci dans le template. Donc maintenant j'ai fait un .to_s pour que ça soit plus clean.

AliSoftware · 2017-05-07T20:21:57Z

lib/gyro/utils/file_utils.rb

@@ -26,4 +28,44 @@ def self.write_file_with_name(dir, name_file, content)
    file_path = File.expand_path(name_file, dir)
    File.write(file_path, content)
  end
+
+  def self.templates_dir
+    Pathname.new(File.dirname(__FILE__)) + '../../'


Either:

include the /templates part in that path if you name that method templates_dir, so that it actually indeed ponts to the templates directory

or name that method self.lib_dir if you're not pointing to the actual template dir but the lib dir

(I personally prefer the first solution, keeping that name and pointing to lib/templates)

AliSoftware

Renaming suggestions

AliSoftware · 2017-05-07T20:24:17Z