Réflexions

De Patchwork.

Sommaire 1 Bugs 2 Refactorisations 3 Debug tools 4 Non classé 5 Code 6 Sécurité 7 Performance 8 Templates 9 Formulaires 10 Contrôleur & URL 11 Preprocesseur 12 Application Offline / Générateur de CD-ROM 13 Coté JavaScript 14 I18N

Bugs

• liveAgent : tester agent vs exoagent
• erreur plus explicite ou loop_array par défaut lorsqu'un element de $o n'est ni une boucle ni un scalaire
• différence entre DEBUG et non-DEBUG : htmlspecialchars sur AGENT ?
• augmenter la résolution de appId, 1s ne suffit absolument pas !
• bug à l'enregistrement de la pCrontab, lorsque le niveau d'une appli. change (même base, même zcache)
• pForm_hidden->getValue() qui retourne les données même non valides => porte ouverte à des pb ?
• parse_str() est sensible aux magics quotes. Comme parse_str() peut modifier la table de symbole locale, l'overriding ne permet pas de corriger cela. Si on veut conserver cette possibilité, une combinaison entre un Parser PHP et extract() pourrait résoudre. Pourtant, ne serait-il pas utile de désactiver la possibilité de modifier ainsi la table de symbole ? Si c'est absolument nécessaire, extract() permettrait de le faire dans un second temps.
• les formulaires avec plusieurs boutons d'action et des champs required différents pour chaque action entrent en conflit avec required du html5. Des attributs novalidate bien placés peuvent résoudre le pb.
• Anti-CSRF se déclenche beaucoup trop fréquemment. Il faudrait ajouter une synchro du cookie+formulaire lors du submit de celui-ci.

Refactorisations

• pb de droits ac ftp + data/queue/*
• créer une abstraction "hash db", basée sur dba, sqlite ou hash de dossiers sinon
• remplacer toute dépendance sqlite actuelle par "hash db"
• loop>filter, renommer en "..." ?
• Scalability watch/touch : ajouter une superposition basée sur Memcache ?
• relation loop <=> SPL Iterator ?
• SESSION : mettre les SESSION::$authVars ($group et flash ?) dans un cookie compressé et crypté, pour minimiser les accès centraux
• blinder les régressions avec des batteries de tests unitaires
• aplatir la structure de fichiers :

1. remplacer public/__/toto.ext par public/toto.__.ext
2. déplacer le contenu de class/ à la racine et déplacer les class/agent/ dans public/

• garantir le bon fonctionnement de set_include_path()
• permettre de déclarer pour chaque superposition :
  • ses dépendances : version de PHP, extensions activées, etc.
    
  • sa configuration du préprocesseur : liste des tokenizers activés ou pas
  • ses convention de codage, vérifiées/corrigées automatiquement autant que possible
  • pour faciliter la déclaration des dépendances : analyse statique des dépendances, comme PHP_CompatInfo
• supprimer le mapping des caractères spéciaux dans le nom des classes et pour les agents, les remplacer par une constante contenant l'URL associée

Debug tools

• afficher/conserver la debugWin pour les contenus non-HTML et pour les pages blanches d'erreur
• assurer une persistance des logs : créer un fichier de log par requête, accompagnés d'un log général qui serve d'index et de log bas niveau (bootstrap)
• assurer un concept de session de développement (log général => log par session) qui regroupe tous les logs qui concernent le dév en cours, à l’exclusion du reste (requête parallèles faites par un autre dév)
• assurer un lien avec le code source, via pStudio
• flux allégé, détails arrivant par JSON à la demande
• reprendre bonnes idées de FirePHP

Non classé

• Explorer les EXOAGENTS privés (échanges de cookie vs sécurité X-domain...)
• pMail :
  • archive => version web consultable + tinyurl sur les liens trop long
  • ajouter un contrôleur pour interactions bidirectionnelles par email
  • analyse des raisons des bounces
• ajouter un utilitaire pour traduire facilement les chaînes, via un popup par ex.
• baser geodb sur geonames.org, et y ajouter des capacités d'i18n
• serverside : ajouter possibilité de mettre en cache un couple données/ptl mixés
• EXO* cross-domain : implémenter un client HTTP avec cache, cookie, et filtre des réponses (linérisations pour w())
• possibilité de faire des transclusions via des idées comme Purple Include
• installation sur un ftp via un script. Exploiter Go-pear ?
• si tokenizer non présent : webservice ? Attention aux différentes versions de PHP
• resolvePath à 3 niveaux de recherche : 1. dynamique fichier, 2. statique dossier parent + dynamique fichier, 3.statique fichier ; par défaut, 1. non utilisé, 2. pour >= zcache et 3. < zcache ?
• intégrer CSSTidy ou équivalent
• p:: lors du bootstrap, enregistrer un fichier qui liste les enfants d'un appli, pour vider les caches au besoin ?
• isoler chaque agent dans une transaction SQL (si connexion il y a, surtout pour le mode serverside)
• exoagents : afficher le domaine dans la debugWin et dans le msg "auth token needed"
• QSelect compatible avec cloneNode ?
• error.patchwork.log ne gère pas les requêtes parallèles (développement à plusieurs en même temps, pTask, etc.) - ajouter des "sessions de développement"
• actualisation du cache plus agressive : le cookie v$ pourrait être mis à jour beaucoup plus fréquemment que maxage, et ainsi même les sites statiques seraient synchronisés correctement : maxage.min serait utilisé pour les pages sans v$ dans l'url, et maxage.max pour les pages avec v$ dans l'url, la synchro JS du cookie ferait le reste
• parser le tout premier fichier (celui qui inclue le bootstrap de p::) pour extraire le code qui suit l'include en question et l'ajouter au .patchwork.php après transformation par le préproc.
• faire un script en ligne de commande qui crée une arborescence de liens symboliques, fusion des dossiers au sens de l'héritage d'application, pour simplifier le dév.
• ajouter un compilateur CSS comme LESS, SASS ou lessphp, améliorer en permettant l'exécution coté client, via remplacement des balises style par des balises script

Code

• Lib. externes : #include_path ... ds config.patchwork.php (et options pour le préproc, genre remove *_once... ?)
• permettre d'utiliser patchwork en mode librairie externe ? (idem PEAR, Zend...)
• donner un identifiant à chaque appli dans le config ?
• créer un js/pipe/... pour utiliser les pipes en tant que lib JS
• class toto clone tata {}
• donner la possibilité d'enregistrer des callbacks appelés à la suppression d'une session (gc)
• watch/touch : renommer ? ajouter wildcard touch('toto/*') <=> touch('toto') et watch('toto/*') (pas d'équivalent actuellement)
• Anticipation PHP 6 (http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE?view=co)
  • <?php declare(encoding = 'Shift-JIS'); ?>
  • TextIterator
  • ...\u678...
• créer une classe patchwork spéciale pour faire fonctionner une appli. tierce complète dans patchwork
• ajouter une directive #include pour permettre le packaging de code dans l'include_path

Sécurité

• utiliser js/xxtea et T$ pour crypter les données mises dans window.name
• antiCSRF token : scinder en une partie fixe pour clef de cryptage stable, et une partie variable pour se protéger des fixations de cookie (vraiment nécessaire ?)
• nettoyage des identifiants : SHY, confusables, diacritiques...
• Secure Password Hashes
• web service pour maquiller les adresses emails de façon certaine (cf ICI)
• X-Frame-Options ?
• http://tools.ietf.org/id/draft-abarth-origin-03.html

Performance

• diminuer le nombre de requêtes en version clientside :
  • regrouper en fin de w.js tous les fragments statiques de l'application (templates, pipes et traces)
  • OU regrouper ces fragments dans les contrôleurs HTML clientside
  • utiliser les data:uri ou bien ceci lorsque ça n'est pas possible
• paralléliser l'assemblage des pages - voir 1, 2, 3, 4)
• pré-calculer les routes vers les fichiers statiques pour chaque langue activée
• utiliser le cache manifest HTML5 pour précharger les ressources statiques ?

Templates

• élargir l'expression régulière des noms de variable de template genre [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
• Donner au designer la possibilité d'importer les données d'un agent via <!-- IMPORT ... map="table de correspondance des noms de variables" -->
• Créer des pipes typographiques :
  • les intégrer comme filtre à la compilation dans la phase de traduction ?
  • http://www.pyrat.net/Raccourcis-Typographiques-de-SPIP.html#sommaire_11
  • http://www.uzine.net/article1802.html
  • http://www.unicode.org/cldr/
• Renderer, en fonction de agent::contentType :
  • activation/désactivation/sélection du système de template
  • pré-filtrage des templates,
  • délimiteurs de variables et de blocs,
  • échappement des variables,
  • pipes spécifiques
  • namespace {r$...} === unescape({$...}) - exclusion volontaire de a$ et g$ car non filtrés
  • associer chaque .ptl à un Content-Type : via extension et mapping .js.ptl => text/javascript, .html.ptl => text/html, ...
  • en mode DEBUG, émettre un warning si l'extension ds l'url ne matche pas avec le Content-Type
• ajouter un index.ptl par défaut, de démo, idem dans chaque pieces ?
• réflexion pour les loops : dès le premier accès, figer le contenu, pour tjs connaître le nb d'itérations et supprimer les effets de bords potentiels des doubles utilisations ?
• permettre <!-- INLINE 'foobar' map="table de correspondance des noms de variables" --> (et aussi permettre les quotes)
• subdiviser les templates en méthodes pour passer à une granularité d'héritage sub-fichiers ! Etendre INLINE en conséquence
• résoudre les pipes constants à la compilation du template ? Comment faire avec {now:} ?
• ajouter une balise <!-- T -->...<!-- T fr -->...<!-- END:T --> ?
• syntaxe pour définir des agents blocs (form) ..  ?
• TemplateInheritance
• créer des a$__*__ sur le modèle des g$__*__ de façon à séparer les infos sur le contexte de la page dans lequel l'agent s'insère, et les infos sur le contexte de l'agent lui-même. Indispensable pour les exoagents notamment (g$__BASE__, etc.).
• voir Moving Edge-Side Includes to the Real Edge-the Clients

Formulaires

• protection (javascript) contre les doubles soumissions de formulaire POST
• ajouter une loop_formElements($a)
• ajouter un pForm_oneCheck|Radio pour les boucles.
• autoriser les requêtes POST aux agents JS (ou seulement aux liveAgent ?), pour implémenter des formulaires AJAX
• ajouter tous les éléments introduits par le WHATWG
• essayer d'intégrer upload-progress-meter directement dans la page, sans popup
• élément type="file" : voir SWFUpload et YUI Uploader
• ajouter une alerte lorsqu'une interception CSRF est en cours (prévenir que les données n'ont pas été enregistrées)
• ->getData() différentiel ?
• champ hidden pour savoir quel agent doit traiter quelle requête post ?
• onbeforeunload par défaut lorsqu'un élément (textarea uniquement ?) a changé ?
• onbeforeunload pour les loop_edit non enregistrées
• amélioration de l'ergonomie QSelect/Suggest
• ajouter règles de validation multiples, àla sénario de sympa
• checkbox : ajouter un hidden pour détecter les cas où toutes les cases sont décochées (car sinon default gagne)

Contrôleur & URL

• redirections réciproques entre les différentes techniques pour définir PATCHWORK_BASE.
• définir patchwork::redirect dans un appel live à un agent
• possibiliter de nommer les __1__ en qqch de plus humain ?
• ajouter une couche générique de contrôle d'accès aux agents ?
• arithmétique de dossiers ds p::redirect() ?
• ajouter un tinyurl like dans p:: (un seul pour toutes les appli p:: du même serveur : la plus courte)
• reprendre l'idée du forward d'action (http://www.symfony-project.org/book/1_0/06-Inside-the-Controller-Layer#Skipping%20to%20Another%20Action)&nbsp;?
• inclusion d'agents distants comportant des erreurs : window.onerror, <script onerror="mozilla only ?">
• PATCHWORK_DIRECT : n'autoriser que les __X__ explicites, retourner une continuation JS si l'agent demandé n'existe pas, ou resynchro si n° de version mismatch
• normalisation des URLs pour les requêtes frontales (p:: str_replace //, /, $url, en fonction de la signature de l'agent frontal), erreur 404/continuation JS pour les PATCHWORK_DIRECT ?
• ajouter un couche de routage des URL, pour découpler la relation URL -> code et permettre une i18n plus aisée. Compliqué car nécessite le mapping inverse code -> URL dans les PTL en particulier, pour la génération des liens

Preprocesseur

• permettre la surcharge du preprocesseur lui-même, et de ses classes annexes,
• minimiser le nombre/type de marqueurs insérés en analysant les arguments des fonctions à callback
• minimiser le nombre de marqueur par analyse de la profondeur de graph du code
• fonctions à callback/fonctions appelée par variables : résolution statique si possible, résolution dynamique (ou warning) sinon, de l'empilement des fonctions ?
• substitution de fonctions par empilement, gestion du contexte d'appel (pile de fonctions imbriquées dans membres static). Ou plutôt, classe spéciale "global" dont les méthodes statiques remplacent automatiquement les fonction globales de même nom ?
• ajouter une option preprocesseur pour supprimer les *_once trouvés au début de fichiers dans les libs externes (Zend, PEAR)

Application Offline / Générateur de CD-ROM

• compilateur de base de données : génère des agents exploitables en local, sans serveur, idem cache statique d'agents, directement exploitable sans autre manip par le navigateur. Conception d'un moule d'application, pour générer l'ensemble des paramètres d'entrée.
• voir le cache manifest HTML5

Coté JavaScript

• utiliser "use strict"; aussi souvent que possible
• patchwork + web2.0 : DHTML et AJAX, réutilisation facile des structures définies dans le template ?
• créer une lib js pour intégrer un exoagent sans forcément avoir patchwork sur le serveur
• créer une lib pour gérer les graphems cluster, sur le modèle des u::*. Baser les pipes dessus.
• intégrer une interface pour d'autres compresseurs JS : YUI Compressor ou Google Closure Compiler par ex. (voir ici et ici)

I18N

• Unicode CLDR : translittérations, culture, ... (cf. http://www.unicode.org/cldr/ et PRADO::System::I18N)
• ajouter un mécanisme de routage/récriture/forward d'URL ?
• translate MDB2 : coalesce(...), normalisation des caractères blancs (et d'autres ?)
• Internationalisation des URL :
  • liste de mots pris dans le nom/argument des agents
  • tradution d'url : vérifier cohérence avant/après urlencode de l'url
  • optimisation de ces mots par prefix-compresse puis regexp adaptée avec callback pour la substitution
  • translittération vers ASCII
• rendre printf & co utf8 compatible
• permettre d'adjoindre des tables de traduction avec un "package", et également dans le template ?
• faciliter la traduction avec Google AJAX Language API