Phalcon v2.0.0 UPGRADE

Kb. 1 hete jött ki a Phalcon v2.0.0, amelynek a legfőbb célja, hogy a v1.3.x-es verzióvonal forráskódjait átültessék a PHP szintakszisához elég közel álló Zephir nyelvre, ami szintén a Phalcon készítők gyermeke.

Zephir röviden:

Mindenki vessen egy pillantást a Zephir köztes nyelvre, amely hidat képez a C és a PHP között, és leegyszerűsítheti a saját PHP modulok írását. Mi sem bizonyítja ezt jobban, mint a most kiadott Phalcon v2.0.0 *.zep kiterjesztésű forrás állományai.

Ennyit a Zephir-ről!

A Phalcon v1.3.x --> v2.0.0 upgrade folyamatról írt néhány sort a Phalcon csapata is a blogjukban.

Ebből a cikkből is látszik, hogy elsődleges céljuk egy Zephir alapú v2.0.0 verzió megalkotása volt felhasználva a v1.3.4-es verzió kódjait és funkcionalitását, ami azt eredményezi, hogy a lehető legnagyobb mértékben kompatibilis a v2.0.0 a v1.3.4-el, kivéve néhány pontot természetesen. :)

Egy Phalcon-ra épített projektben az upgrade során szerzett tapasztalataim a következők voltak:

(a lista még bővülhet) 

------------------------------------------------------------

\Phalcon\DI\InjectionAwareInterface->setDi() metódus fejléce megváltozott:

    public function setDI($dependencyInjector)

        -->

    public function setDI(\Phalcon\DiInterface $dependencyInjector)

------------------------------------------------------------

\Phalcon\Mvc\Application->registerModules metódus fejléce megváltozott:

    public function registerModules($modules, $merge=null){ }

        -->

    public function registerModules(array $modules, $merge = null) {}

------------------------------------------------------------

A \Phalcon\Config értékek nem lehetnek callback és/vagy Closure típusúak, mert

akkor a ->merge() metódus ki fog akadni!!!

Egyetlen egyszer be tudja a ->merge() állítani a Closure típusú értéket, de ha egy már Closure típusú érték helyére egy újabbat kellene összefésülni, akkor fog kiakadni "Call to undefined method Closure::count()" kivétel üzenettel.
A jelenséget ez az if elágazás okozza a Phalcon forrásában:

https://github.com/phalcon/cphalcon/blob/phalcon-v2.0.0/phalcon/config.zep#L227

------------------------------------------------------------

\Phalcon\Mvc\Router->getDefaultModule() metódus nem létezik Phalcon v2.0 alatt

------------------------------------------------------------

\Phalcon\Events\EventsAwareInterface::setEventsManager() metódus fejléce eltér 

Phalcon v2.0 alatt:

\Phalcon\Events\EventsAwareInterface::setEventsManager($eventsManager) 

-->

\Phalcon\Events\EventsAwareInterface::setEventsManager(Phalcon\Events\ManagerInterface $eventsManager) 

------------------------------------------------------------

Az alábbi utasítás formát át kell írni:

\Phalcon\Mvc\Model::find(array(
'conditions' => '...',
'bind' => array( 1 => 'VALUE'),
'bindTypes' => array(\Phalcon\Db\Column::BIND_PARAM_***),
));

A következőre:

\Phalcon\Mvc\Model::find(array(
'conditions' => '...',
'bind' => array( 1 => 'VALUE'),
'bindTypes' => array( 1 => \Phalcon\Db\Column::BIND_PARAM_***),
));

Röviden:
A 'bindTypes' tömbnek az indexelése most már minden esetben követnie kell a 'bind' tomb indexelését.


------------------------------------------------------------

\Phalcon\Mvc\Model\ValidatorInterface->validate() metódus fejléc megváltozott 
Phalcon v2.0 alatt
public function validate($record);
--> 
public function validate(\Phalcon\Mvc\ModelInterface $record);

------------------------------------------------------------

Phalcon XSLT sablon motor

Már egy ideje pofozgatom az alábbi XSLT alapú sablon motort, amely kifejezetten a Phalcon PHP-s keretrendszerhez lett kialakítva:

Packagist link:
https://packagist.org/packages/racztiborzoltan/phalcon-xslt-view-engine

Github:
https://github.com/racztiborzoltan/phalcon-xslt-view-engine

Még nem igazán tartom tökéletesnek, de a céljaimnak egyenlőre meg fog felelni. Amúgy is sokat fejlődött az első kiadáshoz képest!

De egyre jobban érik egy v2.x ág elindításának a gondolata.



Próbáljuk meg egészséggel fogyasztani! :)

(nem csak) Drupal bölcsességek

GIT workflow-k ismét felütötték a kíváncsiság hangjait bennem, így néhány percre leléptem, és többek között erre a linkre bukkantam. (Vigyázat!!! A linken van a link! :))

DE!!!!
Az előbbi linken az alábbi okosságokat is találtam, amelyek többsége nem csak a drupalos fejlesztőkre érvényes: 
http://szantogabor.com/bolcsessegek

PHP Snippet: View szintek gyorsítótárazása Phalcon-ban

Nem nagyon találtam meg a Phalcon dokumentációjában, csak némi google zaklatás után.

A helyzet: Phalcon View objektumban beállítható, hogy legyen gyorsítótárazva a nézet, de ekkor a legfelső szinttől a teljes tartalmat gyorsítótárazza. Ha a renderelési szint lejjebb van állítva, akkor nem készít gyorsítótár bejegyzést.

DE!!! Van egy a dokumentációban nem említett beállítás, amellyel megadható, hogy a View objektum melyik szintjének kimenete legyen eltéve a gyorsítótárba.

Ezt pedig a következőképpen lehetséges:

    $view->cache(array(
        'level' => \Phalcon\Mvc\View::LEVEL_ACTION_VIEW
    ));


----
Örültem a szerencsének!

-----------------------------------------------------------

Kiegészítés a fenti bejegyzéshez (2014-04-02)

Nem minden esetben történik meg a fentebb említetthez hasonló beállítások mellett a megfelelő View szintek gyorsítótárazása.

Az alábbi érdekes jelenségeket tapasztaltam ezzel kapcsolatban:

1. Ha nincs megadva a ->cache() metódusban a gyorsítótárazandó szint, akkor csak a LEVEL_MAIN_LAYOUT renderelési View szint esetén fog automatikusan gyorsítótárazni.
   (Ez a pont inspirálta a fenti bejegyzést! :))
2. A View esetén beállított renderelési szintnek nagyobbnak kell lennie a gyorsítótárazandó View szintnél, hogy beinduljon az automatikus gyorsítótárazás
3. LEVEL_LAYOUT renderelési szint esetén bármilyen gyorsítótárazandó szint beállítása esetén két eredményt sikerült kicsiholnom:
• Nem volt gyorsítótár bejegyzés létrehozva,
• Vagy állandóan csak a LEVEL_LAYOUT szint lett csak a gyorsítótárba letárolva, annak ellenére, hogy pl. LEVEL_ACTION_VIEW lett megjelölve a gyorsítótárazandó View szintnek
4. Egy hasznos, gyakorlati kísérletezgetések utáni tanács:Ha a ->cache() metódusban a 'level' értéknek TRUE-t adunk meg, akkor éppen a View-nak beállított renderelési szint teljes tartalma fog a gyorsítótárba bekerülni.
   Valamint, ha ugyanez a 'level' érték FALSE-t kap, akkor nem lesz gyorsítótár generálva!
   

Egyenlőre ennyi!

PHP függvény hívás gyors teszt

in medias res:

<?php
$foo = function($a, $b, $c)
{
    $j = 5-10-34-1+3/5;
    //    echo 'foo function';
};


function foo($a, $b, $c)
{
    $j = 5-10-34-1+3/5;
}


class Bar
{
    public static function static_foo($a, $b, $c)
    {
        $j = 5-10-34-1+3/5;
    }
   
    public function foo($a, $b, $c)
    {
        $j = 5-10-34-1+3/5;
    }
   
   
}


$max = 10000;

echo '1 - '.$max;
echo '<br />';echo '<br />';


echo 'foo(1, 2, 3)';echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    foo(1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo '$foo = function($a, $b, $c){ /* ... */ }';echo '<br />';
echo '$foo(1,2,3)';echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    $foo(1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo '$function = "foo";';echo '<br />';
echo '$function(1, 2, 3)';echo '<br />';
$i = 0;
$function = 'foo';
$time = microtime(true);
while ($i<$max)
{
    $function(1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo "call_user_func('foo', 1, 2, 3)";echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    call_user_func('foo', 1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo "call_user_func_array('foo', array(1, 2, 3))";echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    call_user_func_array('foo', array(1, 2, 3));
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo "call_user_func(array('Bar', 'foo'), 1,2,3)";echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    call_user_func_array(array('Bar', 'foo'), array(1,2,3));
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo 'call_user_func_array(array("Bar", "foo"), array(1,2,3))';echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    call_user_func_array(array('Bar', 'foo'), array(1,2,3));
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo 'call_user_func_array("Bar::foo"), array(1,2,3))';echo '<br />';
$i = 0;
$time = microtime(true);
while ($i<$max)
{
    call_user_func_array('Bar::foo', array(1,2,3));
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo '$bar->{$function}(1, 2, 3)';echo '<br />';
$i = 0;
$bar = new Bar(1, 2, 3);
$time = microtime(true);
while ($i<$max)
{
    $function = 'foo';
    $bar->{$function}(1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';


echo '$class::$function(1, 2, 3)';echo '<br />';
$i = 0;
$class = 'Bar';
$function = 'static_foo';
$time = microtime(true);
while ($i<$max)
{
    $class::$function(1, 2, 3);
    $i++;
}
echo microtime(true) - $time;
echo '<br />';echo '<br />';
?>


---------------------------------------------

Majd egy nálam produkált egyik kimenet:


1 - 10000

foo(1, 2, 3)
0.1220018863678

$foo = function($a, $b, $c){ /* ... */ }
$foo(1,2,3)
0.23000001907349

$function = "foo";
$function(1, 2, 3)
0.13000011444092

call_user_func('foo', 1, 2, 3)
0.21000099182129

call_user_func_array('foo', array(1, 2, 3))
0.22499990463257

call_user_func(array('Bar', 'foo'), 1,2,3)
0.27999997138977

call_user_func_array(array("Bar", "foo"), array(1,2,3))
0.29000091552734

call_user_func_array("Bar::foo"), array(1,2,3))
0.29000020027161

$bar->{$function}(1, 2, 3)
0.13499999046326

$class::$function(1, 2, 3)
0.13499999046326



---------------------------------------------

Kb. a dobogó:

• 1. hely
• foo(1, 2, 3)
•  2. hely
• $function = "foo"; $function(1, 2, 3)
• $bar->{$function}(1, 2, 3)
• $class::$function(1, 2, 3)
• 3. hely:
• call_user_*()

Virtualbox linux natív képernyő felbontáshoz szükséges lehet

Kijött a Xubuntu 12.10 is az Ubuntu 12.10 megjelenésével egyidőben!

Mivel úgy látszik még mindig ismerkedek a linux-okkal, és most már nem annyira biztos, hogy a Debian mellett fogom letenni a voksom, ezért feltoltam egy Virtualbox-os virtuális gépre a Xubuntu legújabb változtatát.
De telepítés után és a Virtualbox Integrációs Szolgáltatások feltelepítése után nem ismerte fel a monitorom teljes felbontását, és teljes képernyős módban is max. 1024x768-as felbontás tudott maximum!

Megoldás:
Némi keresgélés után találtam ezt a blog bejegyzést (biztos sok egyéb helyen is van megoldás):

http://ubuntuforums.org/showthread.php?t=1880909

Három csomagot kell telepíteni, ha még nem lennének a rendszerben:

• virtualbox-guest-dkms - ez a virtualbox "quest-additions"-el már felmászott korábban
• virtualbox-guest-utils - személy szerint ez nem volt telepítve nálam
• virtualbox-guest-x11 - ezzel is rendelkeztem már, úgy mint az első csomaggal

Nekem  ez nálam megoldotta a problémát, valószínű mindenki másnál is meg fogja! Valamint ha jól sejtem, akkor az Ubuntu család összes tagjánál is ugyanezeket kell telepíteni, ha gond lenne (Kubuntu, Lubuntu, Ubuntu, Edubuntu, stb...)

Windows 7 nem hibernál

Az általában rám jellemző, részletesebb, de a témához jelentős mértékben nem kapcsolódó bevezető szöveg, amely sokak számára felesleges, értelmetlen, és/vagy unalmas is:

------------------------------------------

Egyre komolyabbá kezd válni a gondolat, hogy leváltom a Windows 7-et. Ezt a dolgot már morzsolgatom magamban. Linux disztró válogatás, tesztelgetés. Asztali környezet válogatás tesztelgetés. Mind ezt csak Virtualbox-ban. Persze közben volt egy éles telepítés Linux Mint személyében, amely mellé az automatikusan csomagolt MATE asztali környezetet gondoltam ki. Próbálgattam élesben is, de gyorsan feledésbe merült nagyobb rááldozható szabadidő, és egyéb tényezők miatt!
De most okt. 23. előtti kedden elérkezettnek láttam az időt, hogy ismét egy hosszabb válogatási időszak végén (mert ugye a tehetség kutató műsorok korát éljük :)) pontot tegyek egy disztro mellé, ami az elmúlt 2-3 hétben alakult végeredménnyé. Ez a Debian lett!
Első éles telepítésre során kiakadt a GRUB a telepítési folyamatban. Ez sikeresen kinyírta a Windows boot-olást is, amit egy partíció boot flag újbóli kiosztása megoldott a live cd-ről elindított partícionáló segítségével.
Második próbálkozásra szépen felkúszott a Debián (becézve: "debi", vesd össze: 'Olyan debi vagyok, hogy mindjárt OMG leszek' :))
Számomra (,web fejlesztéshez) szükséges néhány alap Windows program alternatívájának, vagy éppen linux-os változatának telepítése (pl. MySQL Workbench, Eclipse, xCHM, stb..). Egy kis driver kutakodás hang és wifi után. Az előbbi hiányosságot betudom a Debian-ra jellemző régebbi, de biztosan stabil csomagok meglétének. (Nem vagyok linux-os, de a kernel is még 2.x). Némi ügyeskedéssel úgy gondolom, mindent le lehet cserélni (Pl. Iceweasel --> Firefox). Hang és wifi az internetes leírások alapján elég könnyen sikerült belőni. Örülök. Estére egy újabb problémába ütköztem: hibernálás után elszállt a hang. Ezt még meg kell "gugliznom". Talán majd ha eredményre jutok, még ide is feldobok néhány hasznos fórum hivatkozást.

To be continued ... in a other galaxy far, far away!

Most itt pontot (illetve kötöjelet) teszek ezen rész végére!
------------------------------------------

A lényeg:

A következő jelenség ütötte meg a szememet:
Windows 7-ben a Start menüben a hibernálás művelet helyett kikapcsolta a monitoromat (megj.: laptopom van!), valamint egyszerűn csak zárolta a felhasználói fiókomat a redmondi operációs rendszer 6.1-es verziójú változata. (Még csak az kellene, hogy egy mondatban kétszer szerepeljen a Windows 7 kifejezés :))
Irány a Google, de két nagy irányba mentek el a válaszolók: vagy driver frissítés kell, vagy (esetleg és) az energiagazdálkodásnál ki kell kapcsolni a jelszó kérését a rendszer visszatérésekor.

De, amit mostanában ritkábban szoktam, magyarul is megpróbáltam rákeresni a bajomra, és ím ez lett az eredménye:
http://pcforum.hu/tudastar/63933/Windows+7+nem+hibernal.html

A tudástárban folyó csevegés végén megszületett az én megoldásomra is a gyógyír: Valószínűleg a pár nappal ezelőtt telepített Linux (Debian) "gyökér" partíciója (sorry linux közösség!) átvette a boot flag-et a Win7-es partíciótól.
Nincs más dolga az embernek, mint átbillenteni egy Windows (pl. EASEUS Partition Master Home Edition), vagy egy Linux-os (pl. GParted) partíció kezelőben a Windows-t tartalmazó partíció boot flag-jét, azaz boot-olhatónak (indíthatónak, aktívnak) kell megjelölni!


------------------------------------------

A lényeg lényege:

Windows mellé telepített Linux esetén a telepítés után érdemes a megnézni a partíciós táblát annak érdekében, hogy a személyes véleményem szerint hasznos hibernálás megfelelően funkcionáljon!

------------------------------------------

Ui.: Itt nem igen érvényes a "Lényeg lényegében lényegtelen!" mondat! :)