Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /www/webvol34/an/96qmbdpibm1sspm/danielliljeberg.se/public_html/blog/wp-content/mu-plugins/gkphp.php on line 1
Archive for december, 2010 « Daniel Liljeberg

Arkiv för december, 2010

Warning: Use of undefined constant archives - assumed 'archives' (this will throw an Error in a future version of PHP) in /www/webvol34/an/96qmbdpibm1sspm/danielliljeberg.se/public_html/blog/wp-content/themes/cordobo-green-park-2/archive.php on line 32

Warning: Use of undefined constant page - assumed 'page' (this will throw an Error in a future version of PHP) in /www/webvol34/an/96qmbdpibm1sspm/danielliljeberg.se/public_html/blog/wp-content/themes/cordobo-green-park-2/archive.php on line 32

Warning: A non-numeric value encountered in /www/webvol34/an/96qmbdpibm1sspm/danielliljeberg.se/public_html/blog/wp-content/themes/cordobo-green-park-2/archive.php on line 32

Warning: A non-numeric value encountered in /www/webvol34/an/96qmbdpibm1sspm/danielliljeberg.se/public_html/blog/wp-content/themes/cordobo-green-park-2/archive.php on line 32
class="post-140 post type-post status-publish format-standard hentry category-php">

Abstrakt basklass för Singleton pattern i PHP 5.3+

28 december, 2010

I PHP 5.3+ så tillkom funktionen get_called_class, som ger dig namnet på klassen som anropade medlemsfunktionen du befinner dig i. Tidigare har vi haft __CLASS__, men om du tex haft en klass bar som extendat klassen foo och i bar använder dig av __CLASS__ i en funktion så kommer __CLASS__att vara foo även om du har en instans av ett objekt av typen bar.

Funktionen get_galled_class kommer dock returnera foo i detta fall. Tack vare detta är det nu möjligt att göra en basklass för singletons och inte behöva implementera detta pattern i varje klass som du vill skall använda sig av det. För att lyckas med detta gör du följande

Flattr this!

Warning: Use of undefined constant archives - assumed 'archives' (this will throw an Error in a future version of PHP) in /www/webvol34/an/96qmbdpibm1sspm/danielliljeberg.se/public_html/blog/wp-content/themes/cordobo-green-park-2/archive.php on line 32

Warning: Use of undefined constant page - assumed 'page' (this will throw an Error in a future version of PHP) in /www/webvol34/an/96qmbdpibm1sspm/danielliljeberg.se/public_html/blog/wp-content/themes/cordobo-green-park-2/archive.php on line 32

Warning: A non-numeric value encountered in /www/webvol34/an/96qmbdpibm1sspm/danielliljeberg.se/public_html/blog/wp-content/themes/cordobo-green-park-2/archive.php on line 32

Warning: A non-numeric value encountered in /www/webvol34/an/96qmbdpibm1sspm/danielliljeberg.se/public_html/blog/wp-content/themes/cordobo-green-park-2/archive.php on line 32
class="post-131 post type-post status-publish format-standard hentry category-php category-zend-framework">

Dela "okända" objekt mellan isolerade moduler i Zend Framework

28 december, 2010

 

Jag ställdes nydligen inför ett scenario där jag ville isolera varje modul i ett ZF projekt ifrån varandra. Systemet skulle själv känna av vilka moduler som var installerade och de skulle i princip sköta sig själva. Alla javascript och andra saker som de behövde skulle de själva inkludera och initiera via sina Boostraps.

En del saker som skulle delas av hela systemet lades i /library/Core men utöver det så skulle ingen module behöva ha kännedom om någon annan modul. Detta är rellativt enkellt men då jag ändå ville att en del saker skulle se centraliserade ut för användaren så dök mitt lilla problem upp.

Låt oss tex säga att vi har en UserController i vår default modul. I denna har vi editAction som skall presentera settings för användaren som denna kan ändra. Så länge detta bara är ifrån grundobjektet för en User så är det ju inga problem alls. Men låt oss nu säg att vi även har en Messages modul som hanterar meddelanden. Användaren skall kunna göra inställningar för denna modul, men vi vill inte att användaren skall behöva gå in i Messages modulen och göra inställningarna där. Vi vill istället att alla inställningar som är kopplade till användaren, oavsett till vilken modul de hör, skall göras ifrån samma settings sida för vår användare.

Jag började med en lösning där alla formulär som hanterade en användares inställningar ärvde ifrån UserSettingsForm. Sedan skapade jag möjligheten att registrera dessa formulär på ett centralt ställe (jag la den i Zend_Registry i en array som hette user_settings_forms)’. Sedan loopade jag igenom denna lista av formulär och visade upp dem alla när man besökte /user/edit och således körde editAction i UserController.

Detta lilla koncept har jag dock vidareutvecklat och gjort mera generellt och presenterar det här nedan. Tanken är att man skall kunna ha ett centralt register där man kan lägga objekt som skall användas på ett centralt ställe. Om vi tar exemplet ovan så ser det nu ut enligt följande.

Jag utveckalr fortfarande detta koncept en del så några saker kan ändras eller behöva lite puttsning. Tex singleton hanteringen här kommer bli lite knas då flera olika Object_Registry’s kan ärva ifrån denna klass. Vi börjar med en Abstract klass som kallas Core_Object_Registry_Abstract.

Sedan så implementerar vi ett simpelt register för som bara accepterar forulär.

Sedan gör vi en specialicering av denna för våra formulär med användarens inställningar.

Det vi gör här är att vi säger att det enda som accepteras i detta register är objekt av typen Core_User_SettingsForm. Vi skapar även möjligheten att tala om för registret vilken användare det är vi skall jobba med och har implementerat funktionen setUser i alla formulär av typen Core_User_SettingsForm. Denna funktion skapar i grundklassen ett gömt element i formuläret med id på användaren för att identifiera denna och i specialiseringar i varje kalls så har den hand om att plocka ut nuvarande data för användaren och fylla i denna i formulären när vi presenterar dem. Core_User_SettingsForm låter oss även sätta överskrift på just detta formuläret. Jag visar alla formulär i en tabbcontainer så därför ville jag ha detta.

Om vi sedan tittar på Messages_Form_UserSettingsForm så kan den tex se ut såhär.

Som synes så hämtar vi ut nuvarande data för användaren gällande hans inställningar för meddelanden i funktionen setUser.

I Messages modulens bootstrap så lägger vi till

Detta görs sedan i varje modul som har inställningar som användaren skall kunna göra i sin sida för inställningar.

I vår default moduls editAction för vår UserController så har vi sedan

Nu kommer kunna visa alla formulär som är till för att sätta användarens inställningar på ett och samma ställe, utan att en enda modul behöver känna till något om någon annan modul.

Jag använder ju nu detta till formulär, men detta kan appliceras på i princip allt som skall kunna presenteras eller på ett centralt ställe utan att själva kärnan i applikationen behöver känna till alla moduler och deras uppbyggnad.

Som synes så skapas inte objekten i registret innan de kallas vilket sparar prestanda, men det finns mera jobb att göra på detta.

Som avslutning vill jag nämna att man hade kunnat åstakomma ungefär samma beteende med ett observer-pattern, men jag kände att jag fick bättre kontroll på alla delarna på detta sätt.

Flattr this!