sdx-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [sdx-users] Pb d'indexation d'un document const ruit à partir d'un


From: Frédéric Glorieux
Subject: RE: [sdx-users] Pb d'indexation d'un document const ruit à partir d'un DOM
Date: Wed, 12 Feb 2003 21:26:26 +0100

Joli !

Bon c'est pas du propre dans la taglib de laisser faire ça, merci
de tester.

 > Je suis en train d'essayer de faire fonctionner une XSP
 > qui me construit un document DOM en java dans un bloc
 > <xsp:logic>...</xsp:logic>
 > puis essaie de l'indexer via les instructions suivantes :
 >
 > <sdx:uploadDocument domDocument="doc">
 >     <sdx:location base="fonds"/>
 > </sdx:uploadDocument>
 >
 > Actuellement, l'accès à la page XSP échoue et une
 > NullPointerException
 > m'est remonté...
 > (voir le fichier joint qui contient la stack trace).

java.lang.NullPointerException
        at
org.apache.cocoon.xml.dom.DOMStreamer.stream(DOMStreamer.java:145
)
        at
fr.gouv.culture.sdx.document.XMLDocument.openStream(XMLDocument.j
ava:103)
        at
fr.gouv.culture.sdx.document.AbstractDocument.getInputSource(Abst
ractDocument.java:187)
        at
fr.gouv.culture.sdx.document.XMLDocument.parse(XMLDocument.java:1
91)
        at
fr.gouv.culture.sdx.document.XMLDocument.startIndexing(XMLDocumen
t.java:172)
        at
fr.gouv.culture.sdx.documentbase.LuceneDocumentBase.index(LuceneD
ocumentBase.java:634)
        at
fr.gouv.culture.sdx.documentbase.LuceneDocumentBase.index(LuceneD
ocumentBase.java:771)
        at
fr.gouv.culture.sdx.documentbase.LuceneDocumentBase.index(LuceneD
ocumentBase.java:593)

Il semble bien que l'indexation veuille bien attraper du dom,
donc côté taglib ça a l'air de marcher.

Est-ce que vous avez essayé

<doc><xsp:expr>doc</xsp:expr></doc>

Je ne sais plus trop mais xsp:expr est parfois si intelligent
qu'il peut peut-être bien vous montrer si votre dom est correct.

Ici on a plus trop de quoi tester du DOM, j'espère que ça
suffira.

 > P.S. : XtoGen gère maintenant les documents complexes (on
 > peut préciser
 > dans la définition des champs, un chemin XPath, merci Frédéric
pour
 > l'idée
 > lors de la journée SDX). A ce propos, qu'en est-il de la
 > réflexion sur
 > ce que
 > pourrait contenir en + le fichier application.xconf  (et donc
en - le
 > fichier
 > structure.xml de XtoGen) ?

Moi je vois bien

            <sdx:fieldList xml:lang="fr-FR" variant=""
analyzerConf="/sdx/resources/conf/analysis/fr.xml">
                <sdx:field name="titre" type="field"
xpath="/html/head/title">
                    <sdx:name xml:lang="fr-FR">Titre</sdx:name>
                </sdx:field>
                ...
            </sdx:fieldList>

De toute façon vous pouvez le mettre là, ça ne devrais pas
bloquer la configuration. Pour ce qui est de l'ajouter dans le
schéma, j'y vois d'autres utilités (index xml:db déjà). Les
développeurs à l'écoute jugeront.

Sinon, j'avais commencé une idée en pensant à xtogen, je vous
livre le texte un peu brut, voyez vous-mêmes
------------------------

        Est-ce que xtogen est toujours en environnement ant ?

        Si c'est une appli SDX, on aurait tout Cocoon (ex:navigateur de
fichier avec un générateur de directory
http://xml.apache.org/cocoon/userdocs/generators/directory-genera
tor.html), les dernières ressources SDX sous la main, et s'il le
fallait, ant resterait disponible
(http://ant.apache.org/manual/antexternal.html).

    Cela permettrait de garder la communication avec l'appli
générée.

        Exemple, la xsl d'une page d'accueil n'a pas la bonne couleur,
il faut un dépannage en urgence, on n'a pas d'accès ftp, un
énorme textarea s'ouvre sur le code. Sous navigateur DOM type moz
ou IE, on peut vérifier si le document reste bien formé,  (ex:
http://www.ajlsm.com/projets/sdapa/demos/monographie.html,
appuyez sur source, modifier un champ de formulaire, voyez le
xml, modifier le xml qui bouge, ou bien essayez de casser le
XML). Avec IE et msxml4, on peut même valider contre un schéma.

        xtogen peut à faible coût se donner les fonctions de déboguage
genre sdxworld (2xsp, 2sdx, 2xsl ...), sans affecter le sitemap
de l'application déboguée.

    Autre fonctionalité, l'export de l'application générée. En
contexte SDX, on a toutes les ressources pour générer un .war
(une installation sdx allégée), avec cette seule application, et
la certitude d'avoir les .jar(s) qu'il faut pour qu'elle marche.

    Si des développeurs d'applis utilisent xtogen, (comme une
boîte à outils en plus de ses objectifs propres),  c'est
peut-être une manière d'attirer les contributions ?
---------------------





reply via email to

[Prev in Thread] Current Thread [Next in Thread]