vu sur spip@rezo
+1 
Yannick
En réponse à Yannick Patois <patois@calvix.org>:
> Nicolas R : il me semble que l'on rejoint le besoin de disposer de
quelques
> champs supplémentaires librement définissables/manipulables/éditables
dans
> au moins les boucles articles, rubriques, et auteurs
> à charge apres a chacun de creer ses fonctions perso php (à mettre
dans les
> squelettes) pour les utiliser
+1Yannick
+1
Jean-Marc
From nhoizey@php.net Tue Nov 5 17:25:22 2002
Return-Path: <nhoizey@php.net>
Received: from lautre.net (estelle.lautre.net [80.67.164.8])
by miel.brainstorm.fr (Postfix) with SMTP id 6B6921D331
for <spip-dev@rezo.net>; Tue, 5 Nov 2002 17:25:22 +0100 (CET)
Received: (qmail 30064 invoked by alias); 5 Nov 2002 16:25:20 -0000
Received: from unknown (HELO nhoizey) (81.49.92.130)
by estelle.lautre.net with SMTP; 5 Nov 2002 16:25:20 -0000
X-Mailer: The Bat! (v1.61)
X-Priority: 3 (Normal)
Message-ID: <17533349063.20021105172516@phpheaven.net>
In-Reply-To: <AAF5025C-F0CC-11D6-8450-0030657E82B6@resaction.com>
References: <AAF5025C-F0CC-11D6-8450-0030657E82B6@resaction.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-BeenThere: spip-dev@rezo.net
X-Mailman-Version: 2.1b3+
Precedence: list
List-Help: <mailto:spip-dev-request@rezo.net?subject=help>
List-Archive: <Discuter chez rezo.net;
List-Unsubscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
<mailto:spip-dev-request@rezo.net?subject=unsubscribe>
List-Subscribe: <http://listes.rezo.net/mailman/listinfo/spip-dev>,
<mailto:spip-dev-request@rezo.net?subject=subscribe>
List-Post: <mailto:spip-dev@rezo.net>
List-Id: SPIP : developpement <spip-dev.rezo.net>
X-List-Received-Date: Tue, 05 Nov 2002 16:25:22 -0000
Status: O
Content-Length: 823
Lines: 23
Il existe des bases de données qui stockent directement du XML, et
non pas des tables en colonnes et s'interrogent dans d'autres
langages que le SQL.
Oui.
Le débat n'est pas de savoir si ces bases (natives, semi natives,
mixtes relationnel / xml / objet etc.) sont des bonnes solutions,
mais plutôt d'imaginer garder une compatibilité dans la couche
sémantique avec tout type de stockage et d'accès.
Si on arrive à sortir le SQL de SPIP en le déplaçant dans des
librairies spécifiques à chaque SGBD, rien n'empêchera ensuite de le
faire aussi pour d'autres types de stockage, en effet, qu'il s'agisse
de XML ou d'autres ...
-Nicolas
Oui je te rejoins tout à fait. Je voulais faire un site sous SPIP, mais malheureusement impossible, à cause de quelques champs manquants. Et je dois me remettre au PHP. C’est-y pas un scandale, ça ?
Bernard Martin-Rabaud
martinrabo@wanadoo.fr
Idem,
En réponse à Yannick Patois <patois@calvix.org>:
> > Nicolas R : il me semble que l'on rejoint le besoin de disposer de
> quelques
> > champs supplémentaires librement définissables/manipulables/éditables
> dans
> > au moins les boucles articles, rubriques, et auteurs
> > à charge apres a chacun de creer ses fonctions perso php (à mettre
> dans les
> > squelettes) pour les utiliser
> +1
>
> Yannick
+1
+1
__________________________________________________________
(...)
Post-scriptum : X Oui O Non
Date de publication antérieure : O Oui X Non
Champs 1 : [_texte english________] X Oui O Non
Champs 2 : [______________________] O Oui X Non
Champs 3 : [______________________] O Oui X Non
Champs 4 : [______________________] O Oui X Non
Champs 5 : [______________________] O Oui X Non
__________________________________________________________
on pourrait nommer ces champs pour que DANS l'ADMIN, nos rédacteurs ait
quelque chose de lisible/repérable/explicite (+ que champ X)
par contre coté squelettes les balises seraient du genre (pas
renommable) : #CHAMP1 #CHAMP2 #CHAMP3 ...
Oui, c'est tentant... mais il faut bien voir que, si on ne veut pas
bouleverser la structure de la base, on va mettre tout ça en serialize()
dans un champ texte/blob unique. Du coup on n'aura pas de sélection possible
sur le contenu de ces champs (pas de critère du type {champ1==^t[oia]t[oia]$})
... on parle bien d'un petit hack, là, pas d'un bouleversement façon spip2.0
Problèmes à évoquer :
- nomenclature : ces extensions seraient récupérable via #EXTENSIONS pour la
totale encore serializée, et #EXTENSION1, 2, 3...
- risques pour la compatibilité ascendante dans un éventuel spip2.0 (je
crois qu'il sera facile de prévoir un convertisseur pour les données... et
les squelettes, il faut voir...)
- types : on proposerait, dans un menu popup en plus du schéma ci-dessus,
de choisir si le champ est "une ligne" (façon surtitre), "texte" (façon
chapo), "date" (??), quoi d'autre ?
- stockage : est-ce qu'on met ça dans un inc_extensions.php3 à créer
soi-même, ou via une interface web comme sugéré ci-dessus ; dans ce cas, où
stocker cette info, et sous quelle représentation ? (un spip_meta, je
suppose)
- quels objets peut-on étendre ? tous ? seulement les articles ?
- ???
-- Fil
Il faut voir aussi une chose, c'est que si on met effectivement en place
l'abstraction de SGBD, la structure de la base on s'en contrefout. Puisqu'au
niveau fonctionnel le SGBD et sa structure seraient invisibles.
Est-ce que rajouter une table dans la base est un boulversement total ??
Une table du genre spip_articles_extensions avec comme tête :
uid ... de base
article_id ... l'article auquel on ajoute l'extension
type ... le type d'extension (que l'on va retrouver plus loin)
nom ... tout est dans le titre
contenu ... pareil
Avec ça, une table spip_meta_extensions (heu .... je suis pas fort pour
les noms)
uid
type ... oh ... le revoilà
active ... l'extension est active ...
Bref, quelque chose dans ce gout là ...
Arnaud