Projet : MagicSite
URL de présentation : http://magicsite.manga-torii.com
Objet : Site générique indépendant de la base de données et même du type de site. La création d'un nouveau site se résume à écrire les requêtes SQL et les pages de rendu XSL. Pour le reste (mise à jour, contrôles e cohérence, etc.) tout se fait automatiquement à partir de la structure de la base de données.
 
18/07/2006 : Le projet, même s'il a encore quelques lacunes passe en release. L'application a démontré qu'elle était capable de gérer des contraintes complexes et gérer "proprement" les erreurs de saisie.
 
**************
 
Alors voilà.
 
En début de mois, je suis parti en formation (aussi inutile qu'inintéressante, comme d'hab ).
Le seul point intéressant de cette formation, c'est que j'ai découvert un outil propriétaire d'un ERP, qui permet, sans développement (uniquement XSL et SQL) de créer une interface web pour consulter/administrer les données de l'application.
 
En gros, c'est une grosse usine à gaz écrite en Java, qui bouffe 500 Mo par session (rien que ça ), d'une lenteur abominable, et pas super au point niveau conception (on s'en serait doutés )
 
Mais le principe de fonctionnement m'a bien plus, et je me suis mis en tête de refaire la même chose en certes, plus limité, mais :
- léger
- plus simple
- non dépendant de la base (pas même du SGBD)
 
Pour le moment, je pense avoir reproduit les fonction "essencielles", même si ces dernières demandent pas mal de boulot pour être améliorées (certainement au niveau optimisation)
 
En gros, le fonctionnement :
- Des fichiers XML décrivant une page, c'est à dire, quelles vues sont éxécutée, leur hiérachie, etc
- Des fichiers XML décrivant les requêtes dans la base, avec des critères pré-définis de tri et de filtre
- Des fichiers XSL, qui sont appelés au moment du rendu.
- Une unique page, qui ne contient rien (ça fallait déjà l'imaginer !), qui lit la description de la page demandée, exécute les vues, puis applique le XSL qui va bien dessus
 
Mise à part que j'ai codé en dur dans mon code (C#) des appels au client SQL Server, par souci d'optimisation, le code ne demande que quelques lignes de modification pour utiliser n'importe quel connecteur OLEDB. Et vu que les requêtes sont stockées dans des fichiers XML, on voit tout de suite qu'on n'est pas du tout liés à un modèle de données figé.
 
Un peu plus de détail :
 
Un fichier "page" ressemble à ça :

 
Dans le détail :

• Un titre (ouais, trop fort)
• Un template (le nom du XSL à appliquer, sans l'extension
• Une liste de vues

Dans cette liste de vue, on trouve, pour chaque vue :

• Son nom
• Le nom de la node XML qui va contenir le résultat
• Une configuration contenant :
• Le nom du filtre utilisé
• La liste des paramètres utilisés pour ce filtre (si existants) avec comme "type" : input = Querystring, POST d'un forumlaire, Variable serveur, Cookie / parent = Valeur d'un champ dans la vue "parente" / value = valeur en dur
• Le nom du critère de tri utilisé

 
Une fichier de vue, quand à lui, se présente de la façon suivante :

 
Dans le détail :

• Une requête SQL sans filtre, ni clause de tri
• Une liste de filtres prédéfinis, avec, pour chacun, le cas échéant un bout de code SQL qui sera mis dans la clause "where"
• Une liste de paramètres, avec leur type
• Une liste de critères de tri prédéfinis, avec, pour chacun, la liste des champs utilisés pour le tri

Voici aussi un exemple de fichier XSL, qui permet ensuite le rendu de la page :

 
On se balade simplement dans l'arboressence du flux XML généré. On peut aussi indiquer des champs qui, selon leur nom, seront utilisés pour la sélection, la mise à jour, la suppression ou l'insertion de données.
 
Actuellement, le source complet est... petit, et assez rapide (ceci dit, je suis sous Vista, alors ça pourrait être largement mieux ) :
Un seul fichier de 604 lignes.
 
Alors maintenant, les questions sont (cf. sondage) :
- Est-ce que ça intéresse des gens ?
- Est-ce que des gens sont près à m'aider ?

Je garderai un oeil sur ton projet (ya mon boulot et en plus j'élabore la version 2 de mon CMS, pas le temps de faire quoi que ce soit d'autre)

Je trouve sympa l'idée. Est ce que tu as regardé les autres CMS en .net qui existait déjà (on me glisse à l'oreille DotNetNuke), histoire de savoir si ça n'existe pas sous une forme ou une autre ?
 
Sinon j'ai déjà bossé sur ce type de projet où on extrait les données via XML et parsing XSL. Ca marche bien pour peut que le coding XSL soit propre et performant (utilisation de template pour générer des mises en pages complexes, des tableaux avec des entêtes, factorisation de bcp d'aspects graphique).
 
Et en .net, ca peut etre sympa (c'est un 'je participe si j'ai le temps de m'y consacrer')

Salut,
 
Merci pour ces deux réponses positives
 
Pour ce qui est des questions :
- Non, je n'ai pas regardé ce qui se faisait. En fait, à la base j'ai fait ça par "pari" avec moi-même : durant la formation, je me disais "mais c'est pas possible de faire une usine à gaz pareille pour un truc aussi simple", et j'ai donc avant tout voulu "clôner" la chose, de façon simple et légère. Je n'ai aucun besoin spécifique par contre, donc je n'ai pas regardé ce qui se faisait déjà.
- Sinon, je pense que l'intérêt de mon truc, c'est surtout de ne pas être figé au niveau du modèle des données, et la possibilité d'appeler ses propres traîtements PL/SQL. Par conséquent, actuellement, sans faire la moindre modification, je pense que dans l'état actuel, mon truc permet de faire aussi bien un CMS qu'une petite boutique en ligne. C'était d'ailleurs le but recherché par la projet initial : "j'ai une base de données, je veux l'ouvrir sur le net pour offrir MES services, comment je fais ?"
 
Maintenant, il reste un peu la face nord de l'Everest à escalader : corriger mon code pour que les mises à jour dans la base se fassent proprement Là je dois recharger toute la requête, et modifier les données la position dans la datatable. Ainsi, si j'ajoute une ligne, elle se retrouve à la fin, et si je la modifie, elle risque de se retrouver à une autre ligne car re-triée, et du coup on va mettre à jour la mauvaise ligne. Je ne parle même pas du cas où j'ai des modifications concurrentes Il faut que je trouve un moyen de récupérer la clé du DT, et m'en servir lors de mes modifs.
A côté de ça, je dois trouver un moyen simple de faire de la pagination pour chaque view d'une même page, en indiquant quelle view doit changer de page. La méthode utilisée par le projet original est intéressante, mais à la fois lourde et vague : les limites sont vites atteintes.
Reste ensuite à mettre en place des librairies d'objets métiers, les plus génériques possible (upload de fichiers, validation de données, etc.). Voir peut-être aussi la possibilité de liée dynamiquement des traîtements externes, à la façon des "mod" d'Apache.
 
Enfin pour le moment, j'en suis pas là.
J'ai ouvert le port 80 sur mon routeur, et ce con ne laisse pas passer les requêtes http

Bon, ça y est.
J'ai passé la nuit à remettre en état mon serveur, et maintenant ça tourne tout bien comme il faut sur un vrai serveur, qui répond et tout

Bon, ben ça avant pas trop mal.
 
"visuellement", y'a pas de changement pour l'instant.
 
Mais grande nouvelle, ça plante plus !

Re-grande nouvelle : non seulement ça plante plus, mais en plus ça marche !
 
Plus rapide, et possibilité de faire énormément plus de choses.
 
Bref, la panade

Bon, j'ai bossé jusqu'à tard ce soir dessus.
 
Mise à part quelques corrections de bugs mineurs, je n'ai pas changé grand chose, ce qui promet pas mal pour l'outil.
 
En effet, j'ai passé la majeure partie de la soirée à mettre en place, avec uniquement du paramétrage, des contraintes plus ou moins complexe, du genre "un auteur ne peut pas être auteur et coauteur d'un même livre".
 
Voir la section "Test Fred", puisque c'est lui qui m'a proposé ces contraintes.
 
Reste une contrainte à la con à rajouter, mais je ferai ça demain, ça demande une gestion propre des erreurs d'intégrité (là ça plante avec un beau message à la dtc.com )

Et voilà.
 
Avec la gestion des erreurs, et la mise en place de la dernière contrainte "de test".
 
Tout fonctionne bien comme escompté.
 
Finalement, le code fait 604 lignes, et offre des performances tout à fait honorables.
Si des personnes sont intéressées pour l'améliorer ou l'utiliser, qu'elles me fassent signe (je me sentirai moins seul dans ce topic )

 
Si tu utilisais des trucs un peu plus libre aussi, tu te sentirais moins seul.

Désolé , le C# fait pas parti des langages que je vise Parcontre belle initiative quand même

Il tourne sous Mono sans aucun problème mon truc.
Ou alors c'est que Mono est une pure merde.
Parceque j'utilise rien d'hétéroclyte dans mon code...
 

 
Et ta BDD c'est quoi ?    

Et la BDD, comme c'est stipulé dans le post initial, ça peut aussi bien être un fichier plain text, une base SQL Server, DB2, Oracle, PostGre, Oracle, n'importe quoi, du moment qu'il existe un connecteur compatible .NET
 
Seule contrainte (et encore, ça n'est utile que si on modifie les données depuis le site), il faut que le SGBD support les contraintes et sâche les transporter à traver son lien à .NET (schema accessible)
 
Actuellement, j'ai juste figé une limitation dans le code, pour SQL Server, mais c'est shootable en 10 secondes chrono (le temps de changer la chaîne de connection et le nom des objets qui font les requêtes (les méthodes étant les mêmes). Là c'est juste pour une raison de perfs, c'est toujours mieux de passer par du natif qu'un pont OLEDB

Histoire de moins donner l'impression que c'est tout pourrave moche et tout, j'ai fait une refonte de l'interface (de toute façon, tout ce qui est présentation est 100% indépendant de l'appli elle-même).
J'espère que vous la trouverez plus sexy
 
A noter que j'ai ajouté comme exemples d'utiliation un change log et un bug report (même qu'il me sert bien )

Salut,
 
Petit up pour la forme.
 
Je viens de me servir de mon truc pour écrire en un temps reccord (4 heures) une application de gestion de planning. Mon truc arrive donc à la hauteur de mes espérance : il permet effectivement de faire des projets plus ou moins complexe sans devoir écrire une ligne de code.
 
Y'a juste un hic : vu qu'il se base sur un fichier XML pour traîter les données (données en entrée pour les modifs, et en sortie pour l'affichage), les données traîtées sont rapidement énorme pour pas grand chose.
 
Genre j'ai une belle page avec un forumlaire de la mort qui tue : un tableau avec la liste de toutes les affectations de tous les employés d'une société pour un mois donné. Ca donne, dans mon cas, pour 11 employés et 21 jours ouvrés en septembre : 21 * 11 * 4 = 1155 champs
 
A ça, on ajoute que quand on poste on soumet tous les champs... Et ça fait à gérer en mémoire un fichier XML quelque peut énorme... Si j'active la trace debug, je me retrouve avec un superbe fichier de 200 Mo
 
Du coup, c'est pas super rapide pour le coup
M'enfin bon, au vue de la quantité d'informations, ça reste limite correct : 20 secondes pour enregistrer toutes les modifications et recharger l'écran... sur ma config serveur vieillissante (bi pro Piii 933 avec 2 Go SDRAM 133 et 6 disques SCSI U3W)
 
C'est ballo
 
Va falloir que je convainque le client de bien vouloir faire les modifications par jour ou par salarié, sinon il va avoir du mal à utiliser son truc en exploitation. Pour la consultation par contre, ça a l'air d'aller par contre.
Y'a moitié moins d'informations à traîter (pas de données postées par formulaire) et surtout, pas 210 * 11 = 231 requêtes update à faire
 
En tout cas, je me suis bien pris la tête pour faire le XSL de rendu du formulaire en question :
(c'est pas beau ça ?)

http://azp.manga-torii.com/xsl/home.xsl
 
Par contre, la création de pages servant de squelette pour générer le fichier xml, c'est trop du bonheur
Page : http://azp.manga-torii.com/pages/p_home.xml
Vue : http://azp.manga-torii.com/views/v_planning.xml