Le 12 mai 2006, à 16:37, Cyrille Leroux a écrit : > On 5/12/06, Georges Racinet <gracinet at nuxeo.com> wrote: >> >> Le 11 mai 2006, à 15:39, Cyrille Leroux a écrit : >> >> > On 5/11/06, Georges Racinet <gracinet at nuxeo.com> wrote: >> >> >> >> Le 11 mai 2006, à 14:59, Cyrille Leroux a écrit : >> >> >> >> > Bonjour, >> >> > Avec CPS 3.4.0-1, j'essaie -désespérément- de >> >> lister/ajouter/supprimer >> >> > les informations indexées dans portal_catalog, ceci à partir du >> code >> >> > d'un widget customisé. >> >> > >> >> > L'idéal ce serait d'avoir un code qui ressemble à : >> >> > tool = getToolByName(self, 'portal_catalog') >> >> > tool.ajouterValeur(leDocument,unIndex,leMotQueJeVeuxIndexer) >> >> > tool.supprimerValeur(...) >> >> >> >> Je ne suis pas sûr que ce soit souhaitable de faire comme ça. Entre >> >> autres parce que les indexations sont gérées en fin de transaction >> et >> >> que vous risquez peut-être de provoquer des conflits durs à >> résoudre >> >> (je m'avance un peu). >> >> >> >> Il vaut mieux laisser faire l'indexation automatique et stocker >> votre >> >> valeur dans un champ du doc en faisant pointer un index dessus >> >> (utiliser un Field Index paramétré avec le nom du champ). >> >> >> >> Pour l'invalidation, simplement vider le champ. Est-ce que ça vous >> >> suffirait ? >> > >> > >> > Merci Georges de t'interesser à mon problème. >> >> J'ai eu pas mal à faire avec les index récemment :-) >> >> > >> > A vrai dire, j'en suis arrivé à essayer ça, parceque je ne m'en sort >> > pas avec une méthode plus "propre". >> > >> > Ce que j'essais de faire, c'est indexer la valeur selectionnée, dans >> > un widget hérité de CPSSelectWidget (alimenté par une base de >> données >> > et non par un vocabulaire). Le problème, c'est que l'indexation >> > automatique n'indexe que la clef et pas la valeur. >> > >> > J'ai donc utilisé typemaker pour faire un type avec mon widget >> > customisé et un autre "caché" (en esperant que les champs cachés >> > soient indexés), mais je ne trouve pas comment les faire communiquer >> > >> > - Je ne trouve pas le moyen de lire le contenu de mon select >> customisé >> > à partir de mon widget caché; >> > - Je ne trouve pas non plus le moyen de lire le contenu du document >> > directement dans portal_catalog (toujours à partir du widget caché) >> > - En cherchant de le code, je suis tombé sur la méthode >> SearchableText >> > dans CPSDocument/CPSDocument.py qui pourrait m'interesser, mais >> > apparement, elle n'est jamais invoquée (j'ai introduis des logs et >> des >> > erreurs pour voir) >> > >> > Par ailleurs, j'ai aussi ajouté un Field Index paramétré avec le nom >> > du champ, mais c'est toujours le même problème : ça indexe la clef, >> > pas la valeur. >> >> Pour ce qui est de l'indexation de la clef, c'est une conséquence du >> principe même de séparation champ/widget. >> >> Quelques rappels: >> >> Le champ vit au niveau du stockage*, alors que le widget s'occupe de >> l'interface utilisateur html et le fait en manipulant un ou des >> champs. >> Par exemple, le Select Widget fait stocker des clefs de vocabulaires >> au >> champ qu'il manipule, et les convertit en valeurs pour l'utilisateur. >> La clef est un identifiant technique plus utile que la valeur, car >> réutilisable. Par exemple il y a un vocabulaire pour les états de >> workflow, dont les clefs sont les identifiants des états eux-mêmes. La >> classe CSS qui correspond pour les listings vaut également cet >> identifiant, mais elle pourrait être gouvernée par un autre >> vocabulaire, etc. >> >> Fort logiquement, ce sont les valeurs des champs qui sont indexées, >> puisque ce sont les seules données stockées. Normalement, une >> recherche >> sur cet index sera elle-même contrôlée par un Select Widget sur la >> page >> de recherche avancée donc c'est bon. >> Si tu as vraiment besoin d'indexer la valeur (par exemple pour pouvoir >> trier un listing alphabétiquement par états de workflow exprimés en >> français), alors il faut que tu rajoutes un champ calculé pour ça, >> avec >> une write_process_expr qui fait la conversion. > > > En effet, Olivier Grisel, m'avait signalé ce type de champ mais je > n'arrive pas à m'en servir comme je veux : > - J'ai mon widget de type select, > - J'ai un champ caché de type liste (ou autre chose), > -> il faudrait que je puisse accéder à l'élément stocké dans le champ > select à partir du write_process_expr de la liste pour pouvoir en > déduire la valeur correspondante (via une requête sql) ... Il ne me > reste plus qu'à trouver comment lire ce champ ... je pensais utiliser > le portal_catalog, mais je ne trouve pas encore la bonne méthode pour > faire ça. tu devrais lire Products/CPSSchemas/doc/fields.txt et Products/CPSSchemas/FieldNameSpace.py > > >> Je ne suis pas familier avec TypeMaker, mais si tu veux faire un >> connecteur avec une base de donnée, il faut faire beaucoup plus que >> rajouter des widgets. As-tu essayé les annuaires de type SQLDirectory >> (pas moi). > > > J'ai déjà mon widget qui fonctionne : il surcharge le _getVocabulary() > pour retourner des données d'une BDD à la place de celles d'un > vocabulary (pour info, j'ai utilisé le connecteur déjà présent dans > Zope pour Gadfly, puisqu'il s'agit d'une petite base sans prétention) > > > En tout cas, merci beaucoup pour ces longues explications! > > Cyrille
Hébergement: Nuxeo: Zope service provider