Produits Entr'ouvert » w.c.s.

J'ai un peu peur d'avoir ici du code tout à fait indépendant de celui qui est utilisé dans l'action "workflow externe", je me demande dans quelle mesure ce code peut être partagé, pour être sûr d'afficher dans /inspect à coup sûr ce que l'action trouverait.

Les tests sur not is_using_postgresql, il y a moyen de les placer plus stratégiquement pour juste ne pas vérifier le petit bout qui ne peut pas être vérifié, plutôt que zapper l'ensemble ?

if not objectdef or parent_identifier == slug:

J'ajouterais un commentaire rappel ici, pour dire qu'on lève le parent de manière systématique quand on est dans l'inspect; ou peut-être séparer davantage, genre :

        parent = self.get_parent()
        if parent and slug:
            # looking for a parent of a specific type (workflow action)
            parent_identifier = '%s:%s' % (parent.formdef.xml_root_node, parent.formdef.url_name)
            if parent_identifier == slug:
                yield parent
        elif parent:
            # looking for any parent (inspect page)
            yield parent

mais c'est peut-être lourd à répéter ensuite pour les autres moments de découverte.

Peut-être que ça gagnerait alors plutôt à appeler "slug" différemment, genre "object_type" ?

Mais fondamentalement c'est surtout je pense que je ne capte pas trop les paramétres attendus dans iter_target_datas, ni avant le patch ni après, genre self.filled.iter_target_datas() dans le cas de l'inspect mais ça veut dire un moment avec ni objectdef ni slug mais alors le @if objectdef: / else: de la fin, il y a une référence à slug dedans comment est-ce possible, ah c'est parce qu'au milieu de l'affaire for (slug, target_id) in data_ids slug c'est désormais plus le paramètre.

Bref je dirais vraiment renommer le paramètre slug, et peut-être dans le commentaire de la fonction décrire le contenu des trois paramètres (si de ton côté tu en as capté le sens)