Réflexions

De Patchwork.

Sommaire

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)
  • bug w3m+<b>: *http://www.cfhtb2009.org/* url isolation
  • pForm_hidden->getValue() qui retourne les données même non valides => porte ouverte à des pb ?
  • pTask : bug dans la tâche => GIF89A dans le mail ?

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 "..." ?
  • diminuer le nombre de requêtes en version clientside :
    • regrouper en fin de w.js tous les morceaux statiques de l'application (templates, pipes et traces) ?
    • et/ou prefetch (templates, pipes et traces)
    • utiliser des sprites CSS pour l'ombre QSelect, etc.
  • 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, pour minimiser les accès centraux
  • blinder les régressions avec des batteries de tests unitaires

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
    • gestion auto des bounces pour ne pas se faire blacklister
  • 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 http://pear.php.net/go-pear&nbsp;?
  • si tokenizer non présent : webservice ? Mais : pb avec entre les 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 <http://csstidy.sourceforge.net/> ou équivalent
  • reprendre l'idée de http://conditional-css.com/ (ne pas chercher à faire l'évaluation coté browser, c'est impossible)
  • 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 ?
  • jsqueez : approfondir le cas particulier des blocs with et catch, qui ont un scope particulier
  • error.patchwork.log ne gère pas les requêtes parallèles (développement à plusieurs en même temps, pTask, etc.)
  • 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.

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...
  • PHP 5.3 : namespace, dynamic static calls ?
  • 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)

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 :
  • 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
    • {raw-$varname} ou {$varname|unescape} ?
    • 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.).

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 ?
  • distinguer agent/folder.php et agent/folder/index.php pour "get list" et "get one" ?
  • 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,
  • 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 ?
  • optimiser le nombre/type de marqueurs insérés en analysant les arguments des fonctions à callback
  • fonctions à callback/fonctions appelée par variables : résolution statique si possible, résolution dynamique (ou warning) sinon, de l'empilement des fonctions ?
  • ajouter une option preprocesseur pour supprimer les *_once trouvés au début de fichiers dans les libs externes (Zend, PEAR)
  • généraliser le preprocesseur statique utilisé pdt le bootstrap
  • minimiser le nombre de marqueur par analyse de la profondeur de graph du code
  • ajouter le support de la syntaxe alternative PHP

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.

Coté JavaScript

  • 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
Récupérée de « http://pa.tchwork.com/wiki/R%C3%A9flexions »