Programmation PHP/Exemples/MiniCMS/Développement

Programmation PHP/Exemples/MiniCMS/Rétrospective

Si l'envie vous prend d'intégrer ce CMS, c'est à dire de le coder localement chez vous ou de l'adapter à votre environnement ou solution. Je vous conseille de toujours travailler avec l'API approprié, c'est à dire ici : php.net. Cette solution est suffisamment légère pour pouvoir être traduite à loisir en Ruby, Java, Python ou autre.
L'inconvénient majeur actuel étant que l'utilisateur ou le webmaster qui l'utilisera devra avoir des notions d'HTML, la vue ajaxifiée étant ouverte pour une saisie directe au plus au niveau, càd la vue elle même offrant le rendu de ce qui va être encodé. 
Les différentes couches ou composantes sous forme de scripts, snippets, classes, functions peuvent être revues, surchargés, améliorées ou étendues. Celles-ci devenant des incréments que vous jugerez utiles de placer à la suite dans ces pages.

Programmation PHP/Exemples/MiniCMS/Conclusion

Développer un collectionneur et publicateur de données comme typo3 ou joomla est plus une affaire d'organisation modulaire que d'approche en terme de service à fournir. Ce dernier n'étant que la collecte et la diffusion, avec quelques options quant au versionning et la mise à jour du contenu. Les règles sont simples, mais à développer...

Programmation PHP/Exemples/MiniCMS/Les couches choisies

Il y aura peu de métier et beaucoup de service dans cette version, l'essentiel du travail reposant sur la modélisation, la sérialisation et la modularisation à faible granularité. 
Avec l'expérience, en développant de manière modulaire, l'écriture du code se fait sans difficulté, hormis les problèmes liés aux limitations de la solution. Il faut s'efforcer de rester le moins limitatif possible (sauf développements business).

Programmation PHP/Exemples/MiniCMS/Code de service vs Code métier

Le choix de l'orientation est déterminé par le fait de coder pour soi-même ou pour un client. À moins de devoir développer un code polyvalent au client, il est déconseillé de délivrer du code de service pour la simple et bonne raison, qu'il peut s'approprier le code et le faire devenir propriétaire. 
En effet, le code de service, libéré des contraintes business, doit être "déposé et protégé", en particulier quand il propose un service considérable. Au mieux il doit être sous licence d'utilisation.

Programmation PHP/Exemples/MiniCMS/Modélisation

La modélisation se veut simple et polyvalente.
Champs de données.
[champs contenus]
Sous customer1/contents, les champs ou "espaces de données" sont organisés en paquets d'enregistrements. D'autres modèles sont possibles.
<?xml version="1.0" encoding="UTF-8"?>
<!-- content dataChunk model -->
<crop id="" number="" scope="" links="">
 <topic/>
 <assert>
 <!-- HERE COMES FRONT END CODE -->
 </assert>
 <!-- Content records -->
 <fields>
 <field id="" number="" subject="">
 <topic/>
 <assert/>
 <content></content>
 </field>
 </fields>
</crop>
Distribués ou non, les paquets s'accèdent par du service pour ne pas dépendre d'un développement purement métier. 
On peut opérer la distinction service / métier, en disant que le service est moins spécialisé.
La méthode d'accession aux données sera par exemple un :
L'id permettant une extraction directe de contenu.
[champs utilisateurs]
Même logique de service :
<?xml version="1.0" encoding="UTF-8"?>
<!-- users dataChunk model -->
<users id="" number="" links="">
 <!-- u:usr / m:mod / a:adm --> 
 <user login="" pass="" lastname="" forname="" rights="u|m|a" />
</users>
Mêmes accès que pour le modèle précédent.
[Champs page.xml]
L'indexation des pages pointeront sur des données data ou layout
<?xml version="1.0" encoding="UTF-8"?>
<pages count="4">
 <page number="1" id="standard" entry="data:1|1|rootEntry"/>
 <page number="2" id="vaisseau" entry="data:1|2|information_2"/>
 <page number="3" id="espace" entry="data:1|3|doorEntry"/>
 <page number="4" id="admin" entry="data:1|1|Error"/>
 <page number="6" id="potiron" entry="data:1|1|content" num="5"/>
 <page number="7" id="er" entry="e"/>
 <page number="8" id="terere" entry="re"/>
</pages>
[Champs templates]
La version suivante a une complétion par points d'ancrages. Cette version va orienter le projet.
L'autorisation de snippets php exécutables rendra possible l'intégration côté client ("customer").
L'adjonction du contenu à l'output se faisant par injection aux points d'ancrage par la méthode servant à compléter le flux avant sa sortie, comme :
Le contenu peut être sorti côté php ou ajaxifié comme ici par le javascript de fin de flux (frameset/content) feedContent().

Programmation PHP/Exemples/MiniCMS/Implémentation

Nous avons besoin des fonctionnalités :
TODO
NICE TO HAVE
Le but étant de fournir un maximum de code de service pour les héritages futur le métier n'est approché qu'en vue de personnaliser le CMS client. 
Concernant l'approche modulaire :
La segmentation en composantes (classes ou "scriptlets") permets un découpage net et précis des différentes parties du projets développable séparément les unes des autres. L'association au sein d'un IHM ou couche de présentation via contrôleur, venant :
L'interface utilisatrice devant tirer parti des composantes et non l'inverse. La richesse des fonctionnalités est dégagée par le service et enclavé par un code orienté solution client. Il va donc de soi de privilégier proprement, pour enrichir ses propres librairies, de chercher le plus possible à développer ses classes et composantes plutôt que de perdre son temps en métier. 
Concevoir du code de haute qualité signifie souvent d'optimiser le code vers une solution à logique 'customer' càd spécialisée, ce qui n'est pas recherché lorsque l'on doit se développer de l'expérience sur le terrain. Au possible, il faut adapté sa modularité et péricliter le service en business pour le client.
Concevoir du code modulaire permets de développer concrètement sans trop d'efforts d'analyse pour les développement XP et sur un grand délais. Il est utile d'avoir conscience de ces deux approches sur le terrain ou lorsque l'on décide d'ouvrir son code au monde. La majorité des développeur ne faisant trop souvent qu'intégrer pour l'argent ou la renommée chez le client le fruit du travail des autres.
'Classes & Fermes de fonctions' contre 'scriptlets'
Les premières sont :
Les secondes sont :
[1] Complétion des données.
Pour disposer des fonctionnalités de gestion de données.
Les fonctionnalités d'appels sont regroupées ci-dessous
<?php
class dataManager
 private $pattern;
 protected $stack, $domDoc;
 public static 
 $crop
 = array(
 "std"=> '<?xml version="1.0" encoding="UTF-8"?>
 <crop><topic /><fields /></crop>'
 ),
 $data
 = array(
 "root"=>"/miniCMS/Owners/"

public static function getContentByData($pData)
 * get the content from data
 public static function setContentByData($pData)
 * set the content to data
 public function setCropForCustomer($pPath, $pCrop)
 * set crop to customer directory
 {
 file_put_contents($pPath, $pCrop);

public function dataManager()
 $this->initialize();

public function initialize()
 * init
 {
 $this->domDoc = new DOMDocument();
 if(@$this->data['path'])
 $this->domDoc->load( $this->data['path'] );