Bootstrap file

[suky]

Chtel bych otevrit diskuzi a zeptat se, jak resite bootstrap file? K teto otazce me mimo jine prituklo tema, ale predevsim tema na nemeckem ZF foru, kde se to taky celkem resilo. Chtel bych se zeptat na vase nazory.

[Techi]

Připomíná mi to DOSovskou éru kdy si kluci porovnávali své autoexec.baty a config.sysy

[harvejs]

zdar tak teda moj zjednoduseny bootstrap je v uz spominanej teme (http://forum.zendframework.cz/index.php?topic=618.msg3086#msg3086) nebudem to tu pastovat znova, tak mozte pozriet tam. Urcite to nie je dokonale, rad by som to vylepsil, teda budem vdacny za akekolvek pripomienky. Pouziva este niekto ako bootstrap  "nekonvencnu" classu? Alebo to mate standardne v jednom file?

[suky]

Tak jsem se rozhodl taky prispet. Upozornuji, ze jde jen o muj nazor.

Harvejsi, urcite se vyplati pouzit do bootstrapu jednu tridu, ktera se postara o celou inicializaci aplikace. Vyplati se to hlavne programatorovi, a to predevsim pokud pracuje na vice projektech, pak staci vzdy vzit tridu a jen hezky volat metody, ktere chci a vymazat, ktere nechci.

ALE smysl objektove orientovaneho programovani lezi uplne jinde, a tak bych se priklanel k procedurarnimu bootstrap filu. Jelikoz je mych par bootstrap filu stale ve fazi vyvoje, tak je musim nejak poupravit, nez vam je postnu.

Zkus si rict jedinou vyhodu toho, co nekonvencni trida prinasi. Jsem zvedav.

Po tom co vyresime zpusob jakym by to mel bootstrap file provadet, je na case se zeptat, co vsechno by mel provadet?
Co by mel spravny bootstrap file obsahovat?

[harvejs]

Zdar, no priznavam, ze ta moja Bootstrap trieda je vlastne len nejake zoskupenie funkcii a rozgranulovanie funkcionality. S OOP to samozrejme nema nic spolocne. Jedinu vyhodu ktoru to pre mna ma je prehladnost. Jednoducho sa s tym pracuje, lahko sa  v tom orientuje, hned viem, kde mam ake nastavenie hladat, kde mam co pridat ak potrebujem.

[suky]

Jo, vzdyt to ti nevyvracim.

Vyhody:

• prehlednost pro programatora

Nevyhody:

• nespravnost konceptu (zadne OOP)
• parsovani tridy je pomalejsi (usuzuji) nez proceduralniho kodu
• ...

Dospejeme tedy k nazoru, ze je to (nekonvencni trida) zbytecne?

[mm-marek]

podobnou funcionalitu měl návrh třídy Zend_Application, nakonec se do frameworku nedostal....

osobně vidím i jako diskutabilní tu přehlednost, kódu tam bude stejně, jen se tam přidá inicializace metod

[suky]

No diskutabilni... Mel bys jednu tridu a v nejake init-metode bys jen volal potrebne dalsi metody, ktere by tam mohly byt i s temi nepotrebnymi. Ale jak pises proceduralni kod je proceduralni kod.

No a zamysleme se nad obsahem bootstrap filu...

[jirin_cz]

No a zamysleme se nad obsahem bootstrap filu...

To, co se ti hodi a to co pouzivas vsude ne? Muzes to davat i do pluginu, ale proc to nevznout hned do toho bootstrapu. Nekdo tu psal db do pluginu, ja ji mam v bootstrapu a nevadi mi to:)

Souhlasim s harvejsem, ze ot je jak ten autoexec.bat apod., proste a jednoduse pouzivej co ti sedi vice.

[suky]

Lepsi by bylo, kdyby nekdo postnul neco konkretniho, ne stylem "davajte si tam co chcete". 

[Pacek]

Moje adresářová struktura je následující:

Co se adresářové struktury týče, každý si ji zřejmě navrhne podle sebe, proto bych ji nerad v tomto vlákně rozebíral.

A bootstrap file:

<?php
error_reporting(E_ALL|E_STRICT);
ini_set('display_errors', 'on');

date_default_timezone_set('Europe/Prague');
set_include_path('.' . PATH_SEPARATOR
                     . './lib/' . PATH_SEPARATOR
                     . './app/models/' . PATH_SEPARATOR
                     . './app/views/forms/' . PATH_SEPARATOR
                     . get_include_path());
require_once 'Zend/Loader.php';
$autoload = Zend_Loader::registerAutoload();

$dbConfig = new Zend_Config_Ini('./app/config.ini', 'db');
$db = Zend_Db::factory($dbConfig->database->adapter, $dbConfig->database->params->toArray());
$defaultAdapter = Zend_Db_Table::setDefaultAdapter($db);
$db->setFetchMode(Zend_Db::FETCH_OBJ);
define('_TABLE_PREFIX', 'rss_');

$registry = new Zend_Registry(array(), ArrayObject::ARRAY_AS_PROPS);
Zend_Registry::setInstance($registry);
$registry->db = $db;

$session = Zend_Session::start();
$registry->session = new Zend_Session_Namespace('session');

$registry->Zend_Translate = new Zend_Translate('csv', './langs', null, array('scan' => Zend_Translate::LOCALE_DIRECTORY));

$frontController = Zend_Controller_Front::getInstance();
$frontController->setBaseUrl('/rss/')
                ->setControllerDirectory(array('default' => './app/modules/default/controllers/',
                                               'users'   => './app/modules/users/controllers/',
                                               'admin'   => './app/modules/admin/controllers/'));

$routerConfig = new Zend_Config_Ini('./app/config.ini', 'routes');
$router = $frontController->getRouter();
$router->addConfig($routerConfig, 'route');

$viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
if(is_null($viewRenderer->view)) $viewRenderer->init();

$viewRenderer->view->setEncoding('UTF-8');
$viewRenderer->view->baseUrl = 'http://localhost/rss/';
$viewRenderer->view->setHelperPath('./lib/Extend/View/Helper/', 'View_Helper');
$viewRenderer->view->setEscape('htmlspecialchars');

$actionHelpersPrefix = Zend_Controller_Action_HelperBroker::addPath('./lib/Extend/Controller/Action/Helper/', 'Action_Helper');

$layout = Zend_Layout::startMvc();
$layout->setLayoutPath('./app/views/layouts/');

$frontController->throwExceptions(true)
                ->registerPlugin(new Extend_Controller_Plugin_TimeCounter())
                ->dispatch();

Do lib/Extend ukládám všechny svoje třídy, připadá mi to lepší než je pojmenovávat svým jménem .

[harvejs]

zdar, ja som tu toho uz asi napisal dost, len by som sa chcel pozastavit nad vetou "parsovani tridy je pomalejsi (usuzuji) nez proceduralniho kodu", jasne s tym suhlasim, ak by sa tie metody pustali 1000x, ale pri jednom zbehnuti je podla mna rozdiel nemeratelny

no este som chcel doplnit moj bootstrap, lebo v predoslom prispevku som ho koli jednoduchosti dost osekal.
mam tam teda okrem ineho este metody:

   public static function setupEnvironment()
   {
           error_reporting(E_ALL | E_STRICT);  

ini_set('display_startup_errors', 1);  

ini_set('display_errors', 1); 
    

date_default_timezone_set('Europe/London');
    

    if($_SERVER['SERVER_ADDR'] == 'xxx')

    {

self::$env = 'production';

    }

    else 

    {

self::$env = 'development';

    }

    }

    public static function setUpDbCache()
    {

$frontendOptions = array(

    'automatic_serialization' => true

    );

$backendOptions  = array(

    'cache_dir'                => 'cache'

    );

$cache = Zend_Cache::factory('Core',

                             'File',

                             $frontendOptions,

                             $backendOptions);

                             

Zend_Db_Table_Abstract::setDefaultMetadataCache($cache);
    }

 
    public static function setupRoutes()
    {
    

$router = self::$frontController->getRouter();
          // nastavenie vsetkych pravidiel, je toho vela, tak to nepastujem,  ale viete si to predstavit :)
    }

je mozne, ze tie veci nie su tam, kde by mali byt, alebo ze to riesim nekoncepcne potom by som bol rad, ak mi poradite, ako to mam spravit koncepcne, resp. ako to spravit lepsie a preco.

este ma napadla dalsia malicka vyhoda. mozno je to len moja nevedomost, ale da sa v eclipse nejakou klavesovou skratkou dostat ku konkretnemu suboru? lebo ku triede sa dostanem ALT + SHIFT + g, nemusim sa preklikavat cez navigator

[tomas.fejfar]

První doporučení je přepsat pravidla z kódu do konfigu a pak $router->setConfig($config), k souboru se dostaneš Ctrl + Shift + R

[harvejs]

diki tie routy skusim prepisat do configu a tou skratkou si mi prave usetril 50% mojho pracovneho casu nechapem, ako to, ze som to nevedel najst, diki!

[suky]

Pacek: Pekne

harvejs: Pokud projekt nevyzaduje velkou navstevnost, je to samozrejme zanedbatelne, ale pro velke projekty to vyhodne neni. Tak proc se spolehat na to, ze projekt bude mit nizkou navstevnost?

tomas.fejfar: Muzu se zeptat na duvod, proc presouvat nasteveni rout do configu?

[harvejs]

opat si dovolim oponovat
pri pouzivani zendu frameworku sa pre uplne cokolvek, aj male ulohy, volaju desiatky az stovky roznych metod vytvaraju sa desiatky objektov, teda podla mna to fakt nezavazi ani pri velkej nasvstevnosti. Je to staticke volanie 5-6 metod, podla na je to nemeratelny cas. Jeden partial loop trva 50x dlhsie ako toto Ale mozme sa asi natahovat na tom dlho, pokial to nebudeme moct realne otestovat. Ale mozem to skusit zprofilovat a mozno na nieco pridem. 

[suky]

Dobre, samozrejme s tebou souhlasim. Ale s tim spatnym konceptem me nepresvedcis! Kdyz je neco teoreticky spatne, je to pro me proste spatne. Usud sam. Nechme to uz lezet.

[harvejs]

jasne, nechajme to, zly koncept si priznavam, a uvedomujem si vsetky nebezpecenstva a nastrahy zivota so zlym konceptom diki za vsetky pripomienky a navrhy, urcite nad tym budem rozmyslat

[tomas.fejfar]

Do configu proto, že je to přehlednější

Kód:

routes.equipment.route               = "/equipment/:eqId/history/*"
routes.equipment.defaults.action     = equipment
routes.equipment.defaults.controller = history

vs.

$router->addRoute(
    'equipment',
    new Zend_Controller_Router_Route('/equipment/:eqId/history/*',
                                     array('controller' => 'history ',
                                           'action' => 'equipment'))
);

Rozdíl v přehlednosti je snad očividný

[maikis]

zajímalo by mě jestli je rychlejší (lepší?)  dávat jakékoliv nastavení, hodnoty do configu nebo do bootstrapu , když pominem přehlednost (podle mě se to dá přehledně udělat i php souboru)

přeci jenom to musí nějaký script načíst z toho configu .. nebo jsou to zanedbatelné časy?

[Jiří Pospíšil]

Řekl bych, že se k INI configu každý tak nějak sám dostane, jakmile začne dělat na nějakém rozsáhlejším projektu. Z hlediska výkonu bude vždycky čisté PHP rychlejší než INI/XML config, v případě rozsáhlejšího INI/XML configu už ty časy zanedbatelné nejsou, z osobní zkušenosti se může jednat i o stovky ms . Používání cache na config objekt je tedy nutnost.

[tomas.fejfar]

Používání cache na config objekt je tedy nutnost.

Ano, to rozhodně. Ono stačí i primitivní serializování do souboru, který se smaže jednou za čas Není nutno se babrat se Zend_Cache. Ale to vytváření toho configu trvá fakt dlouho.

Druhým důvodem pro konfig je, že když se někdo rozhodně, že "konfigurace/:action" bude "nastaveni/:action" tak ti nebude sahat do zdrojáku.

[L.V.]

BTW, Zend_Application je uz v inkubatoru 

http://framework.zend.com/wiki/display/ZFPROP/Zend_Application+-+Ben+Scholzen

Vypada to slibně. Těším se jak malé dítě 

[suky]

harvejs
Rozhodl jsem se na nase probirane tema napsat clanek.

[harvejs]

Ahoj! Tak to ma tesi dik