Porltet en base

[Benjamin Lepeigneul]

Je souhaite discuter d'un problème auquel je suis confronté. Le but de
cet e-mail est de poser mon problème et de proposer des solutions pour
le résoudre.
Les idées sont les bienvenues.

Description du problème :
Actuellement, il est possible de mettre en base la configuration des
portlets sur le portail OpenBlueLab. Le problème est qu'OpenBlueLab
utilise par défault la configuration Système de Fichier.

C'est à dire que la configuration en base sera utilisée uniquement si
celle sur le système de fichier n'existe pas.

Je ne souhaite évidemment pas supprimer certaines portlets (Misc_Admin
par exemple) qui sont utilisées par plusieurs profiles ce qui risquerait
d'entraîner de lourds problèmes si je les supprimait.

L'idée est donc à l'inverse de ce qui est fait actuellement, de charger
ce qui est en base par défaut.


La difficulté n'est pas dans la théorie mais dans la pratique puisque on
utilise pour l'instant un selecteur de type resources-exist qui va
d'abord tester l'existence d'éventuelles configurations sur le système
de fichier puis dans le cas otherwise charger la configuration en base.

Le chargement de la configuration en base se fait via une xquery qui
renvoie dans tous les cas un fichiers XML.

Le sélecteur resources-exist renvoie toujours true dans le cas d'un
chargement en base même si la configuration n'existe pas.

Solutions proposées :
Dans tous les cas, il faut s'arranger pour charger par défaut la
configuration en base. Voici les solutions proposées :

        1) On effectue un <map:aggregate> sur la base et le système de
fichiers. Une feuille de styles va se charger de récupérer la première
configuration qui apparaît. La xquery renvoie un document XML qui peut
être facilement interprété si la configuration n'existe pas en base.
(estimation de temps 1h)

        2) On implémente un sélecteur qui va être plus souple que le
resources-exist (estimation du temps 2h)

        3) On créé les configurations en base lors de la génération du portail.
On n'utilise donc plus du tout les systèmes de fichier. (estimation 1
journée)


Y a-t-il des propositions ou des remarques concernant ce point ?

Merci.
Benjamin.

[bl.vcf]

---

begin:vcard
fn:Benjamin LEPEIGNEUL
n:LEPEIGNEUL;Benjamin
org:BlueXML
adr:;;40 boulevard Jean Ingres;Nantes;;44100;France
email;internet:bl@...
title;quoted-printable:D=C3=A9veloppeur
tel;work:02 40 46 62 78
x-mozilla-html:TRUE
url:http://www.bluexml.com
version:2.1
end:vcard

---

[Madola Gérard Constantin]

Benjamin Lepeigneul a écrit :

> Je souhaite discuter d'un problème auquel je suis confronté. Le but de
> cet e-mail est de poser mon problème et de proposer des solutions pour
> le résoudre.
> Les idées sont les bienvenues.
>
> Description du problème :
> Actuellement, il est possible de mettre en base la configuration des
> portlets sur le portail OpenBlueLab. Le problème est qu'OpenBlueLab
> utilise par défault la configuration Système de Fichier.
>
> C'est à dire que la configuration en base sera utilisée uniquement si
> celle sur le système de fichier n'existe pas.
>
> Je ne souhaite évidemment pas supprimer certaines portlets (Misc_Admin
> par exemple) qui sont utilisées par plusieurs profiles ce qui
> risquerait d'entraîner de lourds problèmes si je les supprimait.
>
> L'idée est donc à l'inverse de ce qui est fait actuellement, de
> charger ce qui est en base par défaut.
>
>
> La difficulté n'est pas dans la théorie mais dans la pratique puisque
> on utilise pour l'instant un selecteur de type resources-exist qui va
> d'abord tester l'existence d'éventuelles configurations sur le système
> de fichier puis dans le cas otherwise charger la configuration en base.
>
> Le chargement de la configuration en base se fait via une xquery qui
> renvoie dans tous les cas un fichiers XML.
>
> Le sélecteur resources-exist renvoie toujours true dans le cas d'un
> chargement en base même si la configuration n'existe pas.
>
> Solutions proposées :
> Dans tous les cas, il faut s'arranger pour charger par défaut la
> configuration en base. Voici les solutions proposées :
>
>     1) On effectue un <map:aggregate> sur la base et le système de
> fichiers. Une feuille de styles va se charger de récupérer la première
> configuration qui apparaît. La xquery renvoie un document XML qui peut
> être facilement interprété si la configuration n'existe pas en base.
> (estimation de temps 1h)
>

* je ne comprend pas trop cette solution ^_^
>     2) On implémente un sélecteur qui va être plus souple que le
> resources-exist (estimation du temps 2h)
>

*de ces trois propositions, celle si me semble la meilleure, ton
selceteur, sera réutilsable, on pourait tombé un jour sur un problème de
même type.
>     3) On créé les configurations en base lors de la génération du
> portail. On n'utilise donc plus du tout les systèmes de fichier.
> (estimation 1 journée)
*cette solution (la 3)  rendrait toute modificationde la la
configuration trop lourdes (en temps surtout), et vu que l'on poura
bient s'affranchir de exist pour une base sql, je ne pense pas que ce
soit une bonne idée.

**4), c'est une solution assez simpliste, : si il y a moyen de faire des
"triggers" sous exist comme dans une abse de données sql, on pourait
imaginer que lors d'une configuration dans la base, on crée un fichier
dans le sytème de fichier. il suffira ensuite de tester si ce fichier
existe, et  de suprimer ce fichier si jamais, on decide de ne plus
utiliser la configurationde la base , mais celle du système de fichier.
 
> Y a-t-il des propositions ou des remarques concernant ce point ?
>
> Merci.
> Benjamin.


[gerard.madola.vcf]

---

begin:vcard
fn;quoted-printable:G=C3=A9rard Constantin Madola
n;quoted-printable:Madola;G=C3=A9rard Constantin
email;internet:gerard.madola@...
version:2.1
end:vcard

---

[Benjamin Lepeigneul]

Madola Gérard Constantin a écrit :

> Benjamin Lepeigneul a écrit :
>> Je souhaite discuter d'un problème auquel je suis confronté. Le but de
>> cet e-mail est de poser mon problème et de proposer des solutions pour
>> le résoudre.
>> Les idées sont les bienvenues.
>>
>> Description du problème :
>> Actuellement, il est possible de mettre en base la configuration des
>> portlets sur le portail OpenBlueLab. Le problème est qu'OpenBlueLab
>> utilise par défault la configuration Système de Fichier.
>>
>> C'est à dire que la configuration en base sera utilisée uniquement si
>> celle sur le système de fichier n'existe pas.
>>
>> Je ne souhaite évidemment pas supprimer certaines portlets (Misc_Admin
>> par exemple) qui sont utilisées par plusieurs profiles ce qui
>> risquerait d'entraîner de lourds problèmes si je les supprimait.
>>
>> L'idée est donc à l'inverse de ce qui est fait actuellement, de
>> charger ce qui est en base par défaut.
>>
>>
>> La difficulté n'est pas dans la théorie mais dans la pratique puisque
>> on utilise pour l'instant un selecteur de type resources-exist qui va
>> d'abord tester l'existence d'éventuelles configurations sur le système
>> de fichier puis dans le cas otherwise charger la configuration en base.
>>
>> Le chargement de la configuration en base se fait via une xquery qui
>> renvoie dans tous les cas un fichiers XML.
>>
>> Le sélecteur resources-exist renvoie toujours true dans le cas d'un
>> chargement en base même si la configuration n'existe pas.
>>
>> Solutions proposées :
>> Dans tous les cas, il faut s'arranger pour charger par défaut la
>> configuration en base. Voici les solutions proposées :
>>
>>     1) On effectue un <map:aggregate> sur la base et le système de
>> fichiers. Une feuille de styles va se charger de récupérer la première
>> configuration qui apparaît. La xquery renvoie un document XML qui peut
>> être facilement interprété si la configuration n'existe pas en base.
>> (estimation de temps 1h)
>>
> * je ne comprend pas trop cette solution ^_^

On peut utiliser des map:select déjà définis (voir le site de apache

cocoon). On peut aussi en créer (c'est du java ==> API).
L'idée est donc de créer un map:selector capable de savoir si la
ressource existe en base.

>>     2) On implémente un sélecteur qui va être plus souple que le
>> resources-exist (estimation du temps 2h)
>>
> *de ces trois propositions, celle si me semble la meilleure, ton
> selceteur, sera réutilsable, on pourait tombé un jour sur un problème de
> même type.
>>     3) On créé les configurations en base lors de la génération du
>> portail. On n'utilise donc plus du tout les systèmes de fichier.
>> (estimation 1 journée)
> *cette solution (la 3)  rendrait toute modificationde la la
> configuration trop lourdes (en temps surtout), et vu que l'on poura
> bient s'affranchir de exist pour une base sql, je ne pense pas que ce
> soit une bonne idée.

Oui, en effet. Il faudrait dans ce cas ecrire en base mais de manière

transparente au type de base de données. Il est clair que ces
modifications ne doivent pas dépendre du type de base. Bien vu ;-).

>
> **4), c'est une solution assez simpliste, : si il y a moyen de faire des
> "triggers" sous exist comme dans une abse de données sql, on pourait
> imaginer que lors d'une configuration dans la base, on crée un fichier
> dans le sytème de fichier. il suffira ensuite de tester si ce fichier
> existe, et  de suprimer ce fichier si jamais, on decide de ne plus
> utiliser la configurationde la base , mais celle du système de fichier.
>
>> Y a-t-il des propositions ou des remarques concernant ce point ?
>>
>> Merci.
>> Benjamin.
>

[bl.vcf]

---

begin:vcard
fn:Benjamin LEPEIGNEUL
n:LEPEIGNEUL;Benjamin
org:BlueXML
adr:;;40 boulevard Jean Ingres;Nantes;;44100;France
email;internet:bl@...
title;quoted-printable:D=C3=A9veloppeur
tel;work:02 40 46 62 78
x-mozilla-html:TRUE
url:http://www.bluexml.com
version:2.1
end:vcard

---

[Jean-Christophe Kermagoret-4]

Bonjour,
La solution 1 me paraît intéressante, simple et rapide à mettre en place.
La solution 3 est inadaptée car la configuration des portlets peut avoir
été modifiée par l'utilisateur. L'effacer lors d'une réécriture me
paraît faire désordre :-(
La solution 2 serait plus intéressante mais un peu plus longue à mettre
en place.

JC

Benjamin Lepeigneul a écrit :

> Madola Gérard Constantin a écrit :
>> Benjamin Lepeigneul a écrit :
>>> Je souhaite discuter d'un problème auquel je suis confronté. Le but
>>> de cet e-mail est de poser mon problème et de proposer des solutions
>>> pour le résoudre.
>>> Les idées sont les bienvenues.
>>>
>>> Description du problème :
>>> Actuellement, il est possible de mettre en base la configuration des
>>> portlets sur le portail OpenBlueLab. Le problème est qu'OpenBlueLab
>>> utilise par défault la configuration Système de Fichier.
>>>
>>> C'est à dire que la configuration en base sera utilisée uniquement
>>> si celle sur le système de fichier n'existe pas.
>>>
>>> Je ne souhaite évidemment pas supprimer certaines portlets
>>> (Misc_Admin par exemple) qui sont utilisées par plusieurs profiles
>>> ce qui risquerait d'entraîner de lourds problèmes si je les supprimait.
>>>
>>> L'idée est donc à l'inverse de ce qui est fait actuellement, de
>>> charger ce qui est en base par défaut.
>>>
>>>
>>> La difficulté n'est pas dans la théorie mais dans la pratique
>>> puisque on utilise pour l'instant un selecteur de type
>>> resources-exist qui va d'abord tester l'existence d'éventuelles
>>> configurations sur le système de fichier puis dans le cas otherwise
>>> charger la configuration en base.
>>>
>>> Le chargement de la configuration en base se fait via une xquery qui
>>> renvoie dans tous les cas un fichiers XML.
>>>
>>> Le sélecteur resources-exist renvoie toujours true dans le cas d'un
>>> chargement en base même si la configuration n'existe pas.
>>>
>>> Solutions proposées :
>>> Dans tous les cas, il faut s'arranger pour charger par défaut la
>>> configuration en base. Voici les solutions proposées :
>>>
>>>     1) On effectue un <map:aggregate> sur la base et le système de
>>> fichiers. Une feuille de styles va se charger de récupérer la
>>> première configuration qui apparaît. La xquery renvoie un document
>>> XML qui peut être facilement interprété si la configuration n'existe
>>> pas en base. (estimation de temps 1h)
>>>
>> * je ne comprend pas trop cette solution ^_^
> On peut utiliser des map:select déjà définis (voir le site de apache
> cocoon). On peut aussi en créer (c'est du java ==> API).
> L'idée est donc de créer un map:selector capable de savoir si la
> ressource existe en base.
>>>     2) On implémente un sélecteur qui va être plus souple que le
>>> resources-exist (estimation du temps 2h)
>>>
>> *de ces trois propositions, celle si me semble la meilleure, ton
>> selceteur, sera réutilsable, on pourait tombé un jour sur un problème
>> de même type.
>>>     3) On créé les configurations en base lors de la génération du
>>> portail. On n'utilise donc plus du tout les systèmes de fichier.
>>> (estimation 1 journée)
>> *cette solution (la 3)  rendrait toute modificationde la la
>> configuration trop lourdes (en temps surtout), et vu que l'on poura
>> bient s'affranchir de exist pour une base sql, je ne pense pas que ce
>> soit une bonne idée.
> Oui, en effet. Il faudrait dans ce cas ecrire en base mais de manière
> transparente au type de base de données. Il est clair que ces
> modifications ne doivent pas dépendre du type de base. Bien vu ;-).
>>
>> **4), c'est une solution assez simpliste, : si il y a moyen de faire
>> des "triggers" sous exist comme dans une abse de données sql, on
>> pourait imaginer que lors d'une configuration dans la base, on crée
>> un fichier dans le sytème de fichier. il suffira ensuite de tester si
>> ce fichier existe, et  de suprimer ce fichier si jamais, on decide de
>> ne plus utiliser la configurationde la base , mais celle du système
>> de fichier.
>>
>>> Y a-t-il des propositions ou des remarques concernant ce point ?
>>>
>>> Merci.
>>> Benjamin.
>>
>

--
Jean-Christophe Kermagoret
Technological leader
OpenBlueLab : http://www.openbluelab.org