automne-community team mailing list archive
-
automne-community team
-
Mailing list archive
-
Message #00000
Re: Automne QA
-
To:
automne-community@xxxxxxxxxxxxxxxxxxx
-
From:
Grégory Salvan <gregory@xxxxxxxxxx>
-
Date:
Fri, 21 Oct 2011 12:19:00 +0200
-
In-reply-to:
<AE23D11D-A65A-4B8B-B1D4-AF9136595989@ws-interactive.fr>
-
User-agent:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110906 Fedora/3.1.14-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.14
Oui je vais créer une branche sur launchpad :)
Juste que je suis plutôt parti sur un fork de la base afin de pouvoir
écrire des tests, plutôt que de rajouter des fonctionnalités.
L'idée est de supprimer toutes les dépendances pour pouvoir lancer les
tests :
soit éclater grand_father en plusieurs classes : errors, exceptions,
logs, autoload (certainement d'autres)
supprimer toutes les constantes et les remplacer par un objet config
revoir la hiérarchie des dossiers et des fichiers :
actuellement je suis parti sur ça (à la symphony) :
/apps
/apps/admin
/apps/admin/config
/apps/admin/modules
/apps/admin/...
/cache
/config
/logs
/lib
/lib/automne/
/lib/automne/lib
/lib/automne/...
/modules
/tests
/web
/web/admin
L'objectif est de pouvoir configurer apache avec le dossier web en tant
que DocumentRoot et de protéger tout le reste.
Le fichier index de web devrait ressembler à ça :
require_once '../config/config.class.php'; // classe 'Automne' qui étend
atmCore avec une méthode statique setUp pour définir des options
particulières.
Automne::init('app','env')->launch();
avec app-> le nom de l'application (admin par exemple)
et env ->l'environnement soit par exemple 'prod', 'tests', 'dev'...
voila, je fais quelques tests, mais ça va certainement changer un peu
pour rester compatible avec les versions précédentes...
Le 21/10/2011 11:08, Frank Taillandier a écrit :
>> Exemple concret, avec la 4.2 on se débarrasse de la classe CMS_context. Cette classe existe depuis Automne 2, elle a été écrite en 2002. Sur la 4.2 on aura CMS_session qui la remplace et se base sur la classe Zend_session. CMS_context restera dans un mode de compatibilité (tous les appels qui y sont fait sont renvoyés vers CMS_session avec les transformations nécessaires pour émuler l'ancien fonctionnement) et seuls les installations migrées depuis une version inférieure auront cette couche de compatibilité.
> OK, je comprends bien le principe.
> Gregory de son côté a l'air parti pour s'attaquer au core et à des couches bases d'Automne, d'où le fork pour être sur de rien péter. Là où j'ai du mal à avoir la vision, c'est si on peut espère pouvoir merger ces modifs.
>
> Question : Greg, tu comptes pousser ton fork sur Launchpad j'imagine ?
> Question : plutôt d'avoir ces échanges par mail privés, que pensez-vous d'en profiter pour utiliser une mailing liste de Launchpad ?
>
> De mon côté, je retourne intégrer du nouveau modèle de page du blog d'Automne ;)
> --
> Frank
>