[Framework] 0.9.4 vs 1.0

Z zasobów na SVN wynika, iz 4programmers.net będzie tworzony z wykorzystaniem framework 0.9.4. Wszystko ładnie pięknie, ale z tego co widzę jest sporo różnic. Czy nie lepiej by było od razu tworzyć to na docelowym framework? Po wrzuceniu zastąpieniu kodów starego frameworka na nowe system przestaje rozpoznawać funkcje w widoku.
Call to undefined function include_meta()
O dziwo sam framework działa i ma się świetnie. Rozumiem, że jest to brak kompatybilności, ale czy to nie wpłynie na późniejsze aktualizacje kodów? W przypadku aktualizacji do nowszego frameworka może się okazać, że potrwa to dość zajmie sporo pracy (mogę się mylić).

Hmm, no wlasnie nie wiem :| Utworzylem galaz 1.0 na SVN, aby wprowadzac nowe rozwiazania do frameworka. Z kolei 0.9.4 jest juz praktycznie gotowe i pod te wersje mozna pisac 4programmers.net.

Staralem sie zachowac jak najlepsza kompatybilnosc, ale to prawda - jezeli wezmiemy wersje 1.0, to kod 4programmers.net moze wymagac poprawy. Moze opisze pokrotce, jakie zmiany poki co wprowadzilem w 1.0.

1. Lepszy autoloader

Ropoznaje z jakim "materialem" mamy do czynienia. Mozemy wiec utworzyc nowy obiekt w ten sposob:

$model = new Foo_Model; // autoloader wykryje model
$controller = new Foo_Controller; // autoloader wykryje kontroler
$wiki = new Parser_Wiki; // prawdopodobnie biblioteka. Najpierw jednak system odszuka pliku /lib/parser/wiki.class.php
$html = new Html; // biblioteka lub helper! Najpierw sprawdzi, czy nie istnieje taki helper

2. Likwidacja pliku common.php. Kod z klasy Front_Controller przeniesiony do klasy Core.

3. Inicjalizacja podstawowych zmiennych w klasie Core. W tym zaladowanie automatycznych zasobow PRZED wywolaniem kontrolera. Jest to o tyle istotne, iz w wersji 0.9.4, zasoby do automatycznego ladowania okreslone w pliku konfiguracji, byly ladowane w momencie utworzenia instancji klasy kontrolera. Dzieki temu mozemy korzystac - np. z polaczenia z baza danych jeszcze przed inicjalizacja klasy kontrolera - np. w jakims triggerze.

4. Rozbudowanie mozliwosci klasy Config. Nadal oczywiscie konfiguracja moze byc przechowywana w pliku PHP lub XML. Dodanie czegos na wzor przestrzeni nazw. Np.:

Config::setItem('core.foo', 'foo');
Config::setItem('core.bar', 'bar');

echo Config::get('core')->foo; 
var_dump(Config::get('core')); // wszystkie zmienne przypisane do przestrzenii core

Oczywiscie, nadal jest mozliwe przypisywanie wartosci "w starym stylu":

Config::setItem('foo', 'foo');

5. Dodanie metody setDefault() do klasy Config. Dzieki temu mozemy zadeklarowac wartosc domyslna jezeli dane pole nie zostalo wczesniej zadeklarowane w pliku konfiguracji - np.:

Config::setDefault('core.templateExtension', '.php');

6. Odczytywanie pola include w pliku XML (hmm, moze ktos ma lepszy pomysl na to?). Chodzi o includowanie innych plikow konfiguracji w ramach danego pliku. Czyli np.:

<config>
  <include>foo.xml</include>
  <include>bar.xml</include>
</config>

W takim przypadku, do projektu zostana wczytane jeszcze pliki foo.xml oraz bar.xml.

7. Konfiguracja widokow moze byc zapisana w pliku XML. Sa one odczytywane przy pomocy klasy Config (oczywiscie konfiguracja moze byc zapisana rowniez w formie pliku PHP).

8. Kompilacja konfiguracji. Jezeli mamy przykladowo, 10 plikow XML z konfiguracja projektu, mozemy ustawic opcje kompilacji. Oznacza to, ze framework bedzie zapisywal konfiguracje do jednego pliku PHP. Dzieki temu nastepnym razem nie bedzie zmuszony do odczytywania i parsowania wszystkich plikow XML. Po prostu wczyta sobie tablice PHP.

9. W klasie Router zamiana nazwy metody z getModule() (ktora byla mylaca) na getFolder() (zwraca podkatalog, w ktorym znajduje sie kontroler).

10. Nie mozna dziedziczyc po klasie Core.

11. Dodanie klasy Context, po ktorej mozna dziedziczyc i w latwy dostep uzyskac dostep do skladowych systemu. Przykladowo, tworzymy biblioteke:

class Foo extends Context
{
    function bar()
   {
        echo $this->getContext()->input->ip(); 
        echo $this->input->ip(); // krotsza wersja
        echo Core::getInstance()->input->ip(); // tak bylo konieczne w 0.9.4 i jest rowniez mozliwe w 1.0
   }
}

12. Mozliwosc dodania metody initialize() w bibliotece. Jezeli piszesz nowa biblitoeke, i nie chcesz dziedziczyc po Context, mozesz dodac metode initialize(). Zostanie ona wywolana automatycznie jezeli zostanie zadeklarowana w ten sposob:

class Foo extends FooBar
{
    private $context;
   
    public function initialize(IContext $context)
    {
         $this->context = $context->getContext();
    }
}

Loader wykrywszy te metode w klasie, automatycznie ja wywola przekazujac w parametrze instancje klasy Context.

13. Dodanie w klasie Controller, metody getModule(). Zwraca ona ewentualna nazwe modulu, w ktorym zawarty jest aktualnie wykonywany kontroler.

14. Dodanie metody getLibrary() w klasie Controller. Ponizsze instrukcje sa sobie rownowazne:

$foo = &$this->load->library('foo');
$foo = &Load::loadClass('foo');
$foo = new Foo; // utworzy nowa instancje nawet jezeli klasa zostala juz zainicjalizowana
$foo = $this->getLibrary('foo');

15. Dodanie metody getModel() w klasie Controller. Ponizsze wywolania sa sobie rownowazne:

$foo = &$this->load->model('foo');
$foo = new Foo_Model; // utworzy nowa instancje
$foo = $this->getModel('foo');

16. Wywolanie widoku: stary sposob nadal dostepny, ale mozna tez krocej:

class Foo_Controller extends Controller
{
    function main()
    {
        return true; // wywola widok foo.php
    }

    function bar()  
    {
        return true; // wywola fooBar.php
    }

    function foobar()
    { 
         // nie wywola nic
    }
    

    function foo1()
    {
         return View::NONE; // nie wowola nic
    }

    function foo2() 
    {
         $this->foo = 'foo';
         return View::MAIN; // wywola foo.php i przekaze do widoku wartosc pola foo
    }
}

17. Dodanie klasy View_XHTML, ktora zlokalizowana jest w /lib/view/xhtml.class.php. Jest to domyslny sposob wyswietlania widokow - w formie XHTML. Istnieje mozliwosc napisania nowego adaptera i miec mozliwosc wyswietlania formy, w jakiej chcemy wyswietlic zawartosc przekazana z kontrolera do widoku. Np.:

function foo()
{
    return View::getView('plik', array(), new View_PDF); 
    return View::getVieW('jaksNazwa', array(), new View_XHTML); 
}

Chcialbym rowniez, aby helpery byly gromadzone w klasy (nie bylby to obowiazek!). Mowie o domyslnych helperach. PHP nie ma mozliwosci tworzenia przestrzeni nazw, dlatego mozna gromadzic funkcje w metody statyczne. Przykladowo zamiast:

html_a('http://dev...'); 

Mozna by bylo napisac:

Html::a('http://dev...');
Html::img('...');
Form::open(); // wyswietil <form ... 
Form::submit(); // wyswietli <input type="submit"

Hmm, widzę że nieświadomie zmusiłem Cię do napisania tego wszystkiego. W zasadzie zastanawiam się, czy nie było by lepiej pisać już pod 1.0, a jeżeli nie, to może pisać w obu gałęziach jednocześnie (to rozwiązanie ma swoje minusy). Chodzi oto, że po powstaniu portalu na 0.9.4, może się okazać, że trzeba przejść z nim w krótkim czasie na nowy 1.0 i coś czuję, że zacznie się zabawa.

Co do zmian, bardzo przydatne zmiany. Jestem pod wrażeniem ogarnięcia tego wszystkiego w jednym mózgu.

Aha, co do namespace to w php 5.3.x już jest. Trzeba poczekać a na pewno w niedługim czasie zostanie wprowadzone do gałęzi stable.

Dominium napisał(a)

Hmm, widzę że nieświadomie zmusiłem Cię do napisania tego wszystkiego.

Eee i tak bym kiedys napisal :D

W zasadzie zastanawiam się, czy nie było by lepiej pisać już pod 1.0, a jeżeli nie, to może pisać w obu gałęziach jednocześnie (to rozwiązanie ma swoje minusy). Chodzi oto, że po powstaniu portalu na 0.9.4, może się okazać, że trzeba przejść z nim w krótkim czasie na nowy 1.0 i coś czuję, że zacznie się zabawa.

No tak. Co prawda nie trzeba bedzie przepisywac niczego od nowa, na pewno jakies zmiany tu i owdzie sa konieczne. Proponuje poki co pisac w 0.9.4, zanim nie wyjdzie 1.0, a ja postaram sie, aby obydwie wersje byly mozliwie jak najbardziej kompatybilne. Dlaczego? Poniewaz planuje dodac do frameworka jeszcze pare rzeczy, takich jak:

• poprawione dzialanie validatora (mozliwosc ustalenia komunikatow bledu dla danych pol)
• poprawione dzialanie klasy Input
• dostosowanie stylu kowania (tzn. w starszych klasach metody gdzie dane sa zwracane, nie nosza przedroststka get - np. zamiast getIp() jest ip(). Moze byc to mylace, gdyz nie wiadomo, co dana metoda robi).

Co do zmian, bardzo przydatne zmiany. Jestem pod wrażeniem ogarnięcia tego wszystkiego w jednym mózgu.

Eee, ja tylko interpretuje rozne pomysly gdzies upatrzone i dostosowuje do potrzeb i mozliwosci frameworka :)