Piwigo.org

mathiasm · 2008-02-25 21:46:00

J'ai sollicité Pierrick. J'espère qu'il pourra donner son avis.

VDigital · 2008-02-25 21:49:53

http://jelix.org/reference/1.0.1/jelix/ … tml#append

VDigital · 2008-02-25 21:51:28

mathiasm a écrit:
J'ai sollicité Pierrick. J'espère qu'il pourra donner son avis.

Pierrick est présent... s'il le faut, son avis sera le bienvenu.

rvelices · 2008-02-25 22:07:39

VDigital a écrit:
http://jelix.org/reference/1.0.1/jelix/jtpl/jTpl.html#append

le append de jTpl concatene une variable (equivalent a concatenation des chaines de caracteres), alors que append de smarty ajoute a une array (equivalent a assign_block_vars ...).

rub · 2008-02-25 22:07:48

rvelices a écrit:
- temporairement (et tres peu performant) les anciens templates vont aussi marcher le temps de tout migrer (techniquement la classe Template contient un smarty et le vieux template avec les variables en doubles)

On ne peut pas faire utiliser 2 classes, la nouvelle classe intégrant le output de la première.
En gros, on garde les $template pour le fonctionnement actuel, on rajoute "$templatebis" pour les éléments migrés et à fin de la page, on recupére le ouput de $template dans une variable de $templatebis.

rvelices a écrit:
- pour le moment on perd les triggers du template (loc_begin_parse etc ...) - de toute maniere d'apres moi ils sont a revoir pour qu'on ait pas besoin de manipuler le template dans le code php... - comme maintenant les templates sont compiles ca ne marchera plus correctement

C'est vrai qu'on avait la sacré habitude de modifier les tpl à la volée mais certains triggers peuvent aussi servir pour modifier des variables du template.
Il faudrait surement ajouter des triggers ou se liés proprement à leur triggers (s'il y a en).
En tout cas, il faudra éviter de modifier leur source. Soit on fait une classe qui hérite de la leur, soit on utilise un système de plugin, s'il y en ont. Mais, il faut pouvoir changer de version sans problème!

rvelices a écrit:
- derniere question - je choisi quel repertoire pour le cache des repertoires compiles ? (qq chose comme PHPWG_ROOT_PATH/data/templates_c ou PHPWG_ROOT_PATH/_data/templates_c ou simplement PHPWG_ROOT_PATH/_templates_c ou encore PHPWG_ROOT_PATH/templates/_compiled ... ?)

Pourquoi ne pas créer un PHPWG_ROOT_PATH/tmp dans le lequel on pourrais mettre PHPWG_ROOT_PATH/tmp/_complied et PHPWG_ROOT_PATH/tmp/_unzip (pour plugin manager)

rub · 2008-02-25 22:11:13

Pour choisir entre les deux, le plus simple ce n'est pas de prendre un template (ou deux) de les migrer avec les 2 outils et de les comparer!
Comparaison perf, codage possible, etc. avec notre environnement!
Car même si l'un est plus rapide que l'autre en benchmark, ce n'est peut-être sensible pour PWG!

rvelices · 2008-02-25 22:15:14

rub a écrit:
rvelices a écrit:
- temporairement (et tres peu performant) les anciens templates vont aussi marcher le temps de tout migrer (techniquement la classe Template contient un smarty et le vieux template avec les variables en doubles)
On ne peut pas faire utiliser 2 classes, la nouvelle classe intégrant le output de la première.
En gros, on garde les $template pour le fonctionnement actuel, on rajoute "$templatebis" pour les éléments migrés et à fin de la page, on recupére le ouput de $template dans une variable de $templatebis.

En fait j'ai deja prepare une class template qui aggrege un smarty et un vieux template... C'est la seule possibilite que j'ai trouve pour tous les assign_var_from_handle (par exemple le menubar.tpl est vieux et index.tpl nouveau etc...). Ca marche plutot bien et c'est transparent pour la phase de migration...

gbo · 2008-02-25 22:26:42

rub a écrit:
Pour choisir entre les deux, le plus simple ce n'est pas de prendre un template (ou deux) de les migrer avec les 2 outils et de les comparer!
Comparaison perf, codage possible, etc. avec notre environnement!
Car même si l'un est plus rapide que l'autre en benchmark, ce n'est peut-être sensible pour PWG!

SVP, pensez à envoyer un exemple aux béoteins des plugins, pour qu'ils puissent appréhender la nouvelle mouture.

VDigital · 2008-02-25 22:30:08

rvelices a écrit:
En fait j'ai deja prepare une class template qui aggrege un smarty et un vieux template... C'est la seule possibilite que j'ai trouve pour tous les assign_var_from_handle (par exemple le menubar.tpl est vieux et index.tpl nouveau etc...). Ca marche plutot bien et c'est transparent pour la phase de migration...

Que veux-tu que je te dise? Livre nous ça dans papillon qu'on regarde ta merveille!

rub · 2008-02-25 22:45:22

rvelices a écrit:
rub a écrit:
rvelices a écrit:
- temporairement (et tres peu performant) les anciens templates vont aussi marcher le temps de tout migrer (techniquement la classe Template contient un smarty et le vieux template avec les variables en doubles)
On ne peut pas faire utiliser 2 classes, la nouvelle classe intégrant le output de la première.
En gros, on garde les $template pour le fonctionnement actuel, on rajoute "$templatebis" pour les éléments migrés et à fin de la page, on recupére le ouput de $template dans une variable de $templatebis.
En fait j'ai deja prepare une class template qui aggrege un smarty et un vieux template... C'est la seule possibilite que j'ai trouve pour tous les assign_var_from_handle (par exemple le menubar.tpl est vieux et index.tpl nouveau etc...). Ca marche plutot bien et c'est transparent pour la phase de migration...

C'est bien plus simple comme ca, c'est vrai...

Mais le but de cette classe n'est pas simplement de faciliter la migration mais aussi d'ajouter les fonctionnalités spécifiques de pwg (comme les traductions!)?

rvelices · 2008-02-25 23:10:19

rub a écrit:
Mais le but de cette classe n'est pas simplement de faciliter la migration mais aussi d'ajouter les fonctionnalités spécifiques de pwg (comme les traductions!)?

Exact. Dans cette classe j'ai deja qq chose come:

Code:

$this->smarty->register_function( 'lang', array('Template', 'fn_l10n') );
  static function fn_l10n($params, &$smarty)
  {
    return l10n($params['t']);
  }

ce qui nous laisse ecrire dans le template

Code:

{lang t='Thumbnails'}

biensur on peut enrichir avec l10ndecimal etc...

VDigital · 2008-02-26 07:17:49

ou

return __e($params['t']);

8-)

rub · 2008-02-26 09:57:57

rvelices, je vais bientôt commiter sur la partie picture pour le diaporama.
Si tu peux, évites de modifier les tpl liées à picture.php ;-) Merci!

P@t · 2008-02-26 10:00:29

A mon avis, les possibilités de smarty sont très interessantes pour faire mumuse avec les plugins ;-)
Mais bon, j'ai pas encore vraiment mis le nez dedant...

gildor · 2008-02-26 10:48:35

Concernant l'OpenID, juste pour mettre mes 2cts au pot commun: je pense que c'est de plus en plus nécessaire.

En fait, je pense qu'il faut surtout autoriser à faire des "plugin" d'authentification. C'est déjà plus ou moins fait (je ne suis pas trop au courant en fait) quand on utilise l'authentification phpBB.

L'idéal c'est de sortir les mécanismes actuels d'authenfication dans un plugin externe (ne garder qu'une table de correspondance auth extern -> user, le reste est inchangé).

Après je ne suis pas du tout un expert OpenID et pas plus un expert PHPWebGallery.

Mais permettre de faire des plugins d'authentification, je pense que ca vaut le coup à long terme. De toute façon, si PHPWebgallery doit s'intégrer dans un gros site web, je vois pas trop comment faire sans une sorte de SSO (OpenID ou autre)... Laissons au gens la possibilité de faire des trucs externes pour connecter leur propre SSO.

Piwigo.org

Annonce

#31 2008-02-25 21:46:00

Re: Evolution des templates

#32 2008-02-25 21:49:53

Re: Evolution des templates

#33 2008-02-25 21:51:28

Re: Evolution des templates

mathiasm a écrit:

#34 2008-02-25 22:07:39

Re: Evolution des templates

VDigital a écrit:

#35 2008-02-25 22:07:48

Re: Evolution des templates

rvelices a écrit:

rvelices a écrit:

rvelices a écrit:

#36 2008-02-25 22:11:13

Re: Evolution des templates

#37 2008-02-25 22:15:14

Re: Evolution des templates

rub a écrit:

rvelices a écrit:

#38 2008-02-25 22:26:42

Re: Evolution des templates

rub a écrit:

#39 2008-02-25 22:30:08

Re: Evolution des templates

rvelices a écrit:

#40 2008-02-25 22:45:22

Re: Evolution des templates

rvelices a écrit:

rub a écrit:

rvelices a écrit:

#41 2008-02-25 23:10:19

Re: Evolution des templates

rub a écrit:

Code:

Code:

#42 2008-02-26 07:17:49

Re: Evolution des templates

#43 2008-02-26 09:57:57

Re: Evolution des templates

#44 2008-02-26 10:00:29

Re: Evolution des templates

#45 2008-02-26 10:48:35

Re: Evolution des templates

Pied de page des forums