Le 11 mai 2006, à 15:39, Cyrille Leroux a écrit :
> On 5/11/06, Georges Racinet <[EMAIL PROTECTED]> 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.
