suzanne.soy/2010-moteur-site-simple
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Encore des réflexions sur la nouvelle architecture.

Browse Source
This commit is contained in:
Georges Dupéron 2010-10-03 03:40:29 +02:00
parent 73282aa93a
commit 86c94d030d
2 changed files with 230 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

203
__cms__/code/classes.txt Normal file
View File

@ -0,0 +1,203 @@
/******\
| TODO |
\******/
Comment pseudo-insérer des images dans la BDD ? Est-ce la classe de la page qui décide de les déplacer dans /data et de mettre juste le nom dans la BDD ?
(Et c'est à ce moment-là que la miniature est faite). Ou bien, un "trigger" (get et set) pour faire la même chose ?
=== Page ===
->rendu() -> Document
->parent
->url // toute l'url
->urlComponent // juste la fin (le composant de l'url qui désigne cette page).
->select(requête) -> CollectionPages
->set_prop() {
s'il y a un setter (trigger), on l'appelle, sinon on appelle set_prop_direct();
le setter fait ce qu'il veut, puis appelle set_prop_direct();
}
// TODO : gestion du renomage (pseudo-réécriture d'URL).
=== CollectionPages ===
__construct()
__call() // appelle la fonction sur tous les objets, et renvoie les résultats dans un tableau. si les résultats sont des CollectionPages, ils sont concaténés dans la même collection.
__get() // renvoie un tableau contenant le champ pour chaque objet.
__set() // affecte la valeur sur chaque objet.
=== Document ===
->header -> HTMLElement
->footer -> HTMLElement
->nav -> HTMLElement
->article[] -> HTMLElement // ?
->titre
->url
->xhtml5()
->html5()
=== HTMLElement ===
// Chaque type d'élément est une sous-classe de HTMLElement, et impléménte uniquement les méthodes de création qui respectent les règles d'imbrication des éléments.
// Pour les éléments dont les enfants possibles dépendent du parent (par ex. <a>), on restreindra les enfants et (parents) possibles à quelque chose de sensé.
// Plutôt que d'avoir plein de sous-classes, HTMLElement a une méthode __call(), qui vérifie ce qu'on peut appeller en fonction du type de l'élément.
->_type
->espace_CSS($class) // définit l'espace CSS de cet élément et de ses descendants.
->div()
->ul()
->li()
->p()
...
->_titre($select) // renvoie un <h2> ou un <input> selon les droits
->_richText($select) // similaire
->_field($select) // ...
// Peut-être que _field peut détecter automatiquement s'il faut traiter un champ de la BDD (par ex. pour le richText) en fonction d'une info "type" dans la classe correspondant à la page de ce champ ?
->_list($select, function_formattage_elements)
=== GeleriePériode extends Page ===
// TODO : nommer différemment les ressources de type HTML et les autres. Cela permer de ne pas appeller les méthodes ->header etc. sur une image !
// Par ex res_h_defaut, res_h_miniature, res_i_image, res_i_miniature (h = html, i=image, c=css, j=javascript, ...)
class GaleriePériode extends Page {
ressources_statiques = ["icône_nouvelle_page:image/jpeg", "css:text/css"];
ressources_dynamiques = ["page:Document", "miniature:Document", "mini_miniature:Document"];
defauts = [
"titre" => "Galerie",
"description" => ""
];
enfants = "GalerieÉvènement"; // Pour SiteIndex, c'est "*" (ou true ou un truc du genre).
ressource_icône_nouvelle_page() {
return ...;
}
ressource_css() {
}
ressource_page() {
$d = new Document();
$d->heading->standard();
$l = $d->article(1)->append->liste(select(...), function($e) {...});
$l->append->...
}
ressource_miniature() {
return $this->miniature_image() . "blabla";
}
ressource_miniature_image() {
// Prendre le 1er par ordre décroissant sur la date, ou bien :
// TODO : prendre l'élément ayant la propriété "aperçu" à true (s'il y en a un, sinon date).
return this->select("./*", order=date desc, limit=1)->mini_miniature;
}
}
register_css(GaleriePériode); // Insère la ressource "ressource_c_css" dans le CSS principal
register_js(GaleriePériode); // Ajoute le script "ressource_j_js" au <head> de la page.
// Ou bien, lors de l'inclusion des pages, les scripts de chacune sont remontés tout en haut. (meilleure solution).
// Dans tous les cas, les deux devraient être faits par :
type_page(GaleriePériode, "galerie-periode");
// Fin GaleriePériode
class CSS extends Page {
ressources_dynamiques = ["css:text/css"];
ressource_css() {
mettre bout à bout tous les CSS ?
}
}
class Document {
function ul() {}
function li() {}
function title() {}
...
function standard() {
$d = new Document();
$d->append->titre($this->select("titre"));
$d->append->description($this->select("description"));
return $d;
}
function liste($elts, $format) {
$d = new Document();
$ul = $d->append->ul();
foreach ($elts as $k => $e) {
$ul->append($format($e));
}
return $d;
}
function bouton($texte, $page_callback, $action_callback) {
// afficher un input
// lors du clic, appeller $action_callback sur $page_callback ?
}
}
abstract class elementDocument() {
private _espaceCss = null;
function espaceCss($class) {
$this->_espaceCss = $class;
}
}
class ul extends elementDocument() {
}
=== Base de données ===
table page (id autoincrement primary key, nomSysteme, composantUrl, parent)
Racine : (?,'racine','',NULL)
NomSysteme -> dans propriétés ?
composantUrl -> dnas propriétés ?
table propriétés(id auto pk, bool système, nom, valeur)
(?,true,dateCréation,?)
(?,true,dateModification,?)
(?,true(false?),publier,?)
TODO : lors d'une requête, ne renvoyer que les éléments que l'utilisateur a
le droit de voir. Filtrage après la requête (attention au LIMIT et OFFSET !) ?
ou y a-t-il moyen d'exprimer ça directement dans la requête ?
class DB extends Selectable {
function connect(){
}
}
class Selectable {
// TODO : comment faire un select sur la table page ?
// TODO : comment créer une nouvelle page ?
function select(qw champs, qw ordre, int limit, int offset) {
// Retourne un selectable, qui a une méthode run() (la méthode run renvoie la liste d'éléments. Chaque élément a une méthode set()).
}
function set(valeur, qw champs, qw ordre, int limit, int offset) {
// Appelle set(valeur) sur chaque élément de $this->select(champs, ordre, limit, offset)->run()
}
function set(valeur, uid) {
// Appelle set(valeur) sur la ligne de la base de données avec cet uid.
// Les <form> des pages ont des champ <input type="hidden" name"_uid_"> et un bouton submit.
// Lorsqu'on active ce submit, les lignes correspondant aux _uid_ dans la base de données reçoivent la bonne valeur.
}
function sql() {
}
function add_setter(condition, fonction_setter) {
// Si on fait un set qui remplit la condition, la fonction_setter est appellée au lieu de modifier directement la bdd.
// Condition peut être :
// true // toujours appellé (pour les permissions, les dates de modification etc.).
// type de page parente // lorsqu'on récupère la liste des enfants d'une page de ce type.
// type de page, nom attribut // lorsqu'on récupère cet attribut d'une page de ce type.
}
function add_getter(condition, fonction_getter) {
// Comme add_setter().
}
}

34
__cms__/code/modules/galerie/galerie-index.php
View File

@ -55,7 +55,7 @@
(<span> :class titre
(get "titre" rendu)))))))
La fonction rendu pren en paramètre une "page" renvoie un fragment html.
La fonction rendu prend en paramètre une "page" renvoie un fragment html.
Tous les fragments html ont 3 parties :
- le titre
- le head (scripts, css etc.)
@ -65,8 +65,11 @@ Tous les fragments html ont 3 parties :
- et l'url ?
Dans la base de données, chaque "page" a :
- un identifiant unique
- un identifiant unique. Chaque élément de la base de données a un identifiant unique construit à partir de
son autoincrement, et du nom de la table.
- un systemName (optionnel) : pour les "pages" Permissions, Utilisateurs, etc. Permet d'accéder en chemin absolu sans connaître l'uid / le nom.
- des propriétés accessibles via @nom-propriété.
+ des propriétés "système" (dates, permissions, composantUrl) avec des droits potentiellement différents.
- des groupes de pages enfant (?) :
Pour la page galerie :
./periodes/2009-2010
@ -82,8 +85,21 @@ Langage de requêtes :
- Limiter le nombre de résultats (LIMIT et OFFSET).
- Ne renvoie que les éléments que l'utilisateur a la permission de voir.
Un module peut déclarer des ressources statiques (par ex. un fragment de less/css).
Un module peut déclarer des ressources statiques (par ex. un fragment de less/css) et dynamiques (p. ex. image).
Les ressources statiques ont une url qui ne dépend pas du chemin de la page en cours, les dynamiques si
(en général).
Les ressources doivent pouvoir être accédées via une certaine url.
=> "Espaces de nommage" : dès la réception de l'url, on s'empresse de trouver son espace de nommage,
et on appelle la fonction correspondante. Par ex. : dans /css, on appelle directement la fonction
qui renverra le fichier CSS. Ou bien, système de "liens" : /css est un lien vers /admin/style:css
(ressource css de /admin/style). La solution "fonction" est plus générale. Par ex. /css/blabla peut
appeller la fonction en question avec "blabla" en paramètre (pour récupérer la bonne feuille de style).
ATTENTION : éviter les conflits de nommage, vu que les espaces de nommage se recouvrent partiellement.
TODO : méthode "shorturl" qui renvoie l'url d'une ressource via son raccourci s'il en existe un, sinon
via le chemin normal.
TODO : Comment les modules indiquent-ils qu'ils ont une feuille css à mettre dans l'espace de nommage
"CSS" ?
NOTE : ça sent le truc bien compliqué avec plein de bugs ça... :( .
Notes en vrac :
===============
@ -101,6 +117,9 @@ Dans les actions de chaque module, il y a :
- créer_enfant (souvent)
Problème des class css.
Solution : chaque classe PHP de création d'élément (Document->ul(), Document->div(), ...) a un méthode
->espaceCSS($class). Lorsqu'on l'appelle, tous les éléments enfants qui ne sont pas déjà dans un espace CSS
reçoivent la classe $class. (ceci est effectué lors de la conversion Document->(x)html5().)
Pour les aperçus dans la galerie : prendre le 1er enfant (ou l'enfant marqué 'aperçu').
@ -112,16 +131,17 @@ Il faut trouver comment générer automatiquement une url / titre / je-ne-sais-q
le titre n'est pas renseigné (par ex. pour les 250 photos de la galerie, pour que les utilisateurs
n'aient pas à indiquer le titre à chaque fois.
Totues les pages ont une date de création et de modification automatiquement.
Toutes les pages ont une date de création et de modification automatiquement.
TODO : pouvoir accéder l'attribut @image directement depuis l'extérieur.
Abstractions :
- Valeur avec binding
- Action (créer page, supprimer)
- Valeur avec binding (+ callbacks ?).
- Action (créer page, supprimer, ... (générer mot de passe)).
- Getter et setter optionnels sur les valeurs.
Ex: getter de titre : Renvoie "Photo [date]" si le titre est indéfini, sinon le titre.
- Vue vs ressource (chaque ressource a une vue, une page "photo" est une ressource (celle par défaut), l'image elle-même est une autre ressource).
- Vue vs ressource (chaque ressource a une ou plusieurs(?) vue(s?), une page "photo" est une ressource (celle par défaut), l'image elle-même est une autre ressource).
Ou bien pas de vue, que des ressources (la "vue miniature" est une autre ressource).
Valeurs par défaut pour les @attributs, définies dans le module lui-même.