Forum PHP.pl

Rapide Framework




Rapide Framework powstał na bazie rozwiązań stosowanych w kilku frameworkach. Organizację i sterowanie w dużej mierze oparto na Zend Framework. Kierowałem się przede wszystkim prostotą. Mojavi (tym bardziej Symphony) jest moim zdaniem zbyt rozległe. Po całej aplikacji krążą obiekty kontekstów, kontrolera głównego... Nie, nie - to nie jest to, czego szukałem.

Całe sterowanie w Rapide powierzono małemu i elastycznemu Front Kontrolerowi. Jądro podzielono na jak najmniejsze części pozwalające w przyszłości na szybką ich wymianę.

Na pierwsze spojrzenie Rapide działa identycznie jak Zend Framework. Jednak po głębszym zapoznaniu się z frameworkiem, okazuje się, że Rapide jest znacznie wygodniejsze.

Przede wszystkim Rapide poprawnie implementuje widok z MVC. W każdej chwili możemy zamienić widoki, aby prezentowane dane ukazały się np. w formacie CSV.

Ponadto wiele czynności zostało zautomatyzowanych, dzięki czemu nie musimy wczytywac konfiguracji do akcji, czy też martwić się o kontrolę dostępu.

Cechy frameworka

• Implementacja MVC
  
• Obsługa pomocników i appletów w widoku dzięki czemu szybko zamieścimy w aplikacji stałe elementy (takie jak menu) w pełni funkcjonalne (funkcjonalność zbliżona do kontrolera).
  
• Kontrola dostępu na podstawie ACL i grupy użytkowników. Konfigurację przeprowadza się w pliku konfiguracyjnym kontrolera i polega ona na zdefiniowaniu grup, które mają dostęp lub nie.

Biblioteki dostarczane przez Rapide

• Rapide_Controller
  Klasa bazowa dla kontrolerów. Zawiera szereg aliasów skracających czas tworzenie kontrolera.
  
• Rapide_View
  Klasa widoku implementująca szablony php. Rapide dostarcza prostą
  oraz rozszerzoną klasę widoku, pozwalającą na dekorowanie treści o elementy stałe (np. stopka, menu).
  
• Rapide_User
  Klasa danych sesyjnych. Umożliwia autentyfikacje użytkownika oraz składowanie danych w sesji.
  Zastępuje standardową tablicę $_SESSION. Umożliwia stosowanie handlerów, dzięki czemu sesja może
  być przechowywana w bazie danych.
  
• Rapide_ACL
  Access Control List - system kontroli dostępu. Pozwala na definiowanie grup mająych dostęp (lub nie) do poszczególnych kontenerów (akcji).
  
• Rapide_Registry
  Rejestr pozwalający na przechowywanie obiektów i wspódzielenie ich w całej aplikacji.
  
• Rapide_Database_MySQL
  Sterownik bazy danych MySQL dostarczający prosty i szybki w użyciu interfejs zarządzający danymi w bazie.
  
• Rapide_Language
  Prosta klasa języka. Dane przechowywane są w tablicach php.
  
• Rapide_Validator
  Szereg klas z rodziny Rapide_Validator dostarczaja prostych i skutecznych mechanizmów
  walidacyjncyh dla danych.
  
• Rapide_Form
  Klasa umożliwiająca szybki dostęp do danych przesłanych za pomocą formularzy. Obecnie bardzo skromna.

Zdaję sobie sprawę, że Rapide wcale nie musi być nadzwyczajnym frameworkiem. Napisałem go dla siebie. Zamieszczam go w sieci, ponieważ może przydać się osobom, które uczą się budowania frameworków.

Kod do pobrania: http://vgm.pl/adrianpawlikpl/rapide/

Tworzenie kontrolera

Kontrolery w aplikacji powinny dziedziczyć po abstrakcyjnej klasie Rapide_Controller. W zasadzie framework wymaga, aby kontrolery
implementowały interfejs Rapide_Controller_Interface.

Katalog kontrolerów definiowany jest w pliku konfiguracyjnym Rapide/config.php. Kontroler musi byź zapisany pod nazwą Kontroler.class.php.


Kontroler jest kontenerem dla wszystkich akcji. Dla przykładu: kontroler Nowosci będzie zawierał akcje Dodaj, Pokaz, Usun, Edytuj itd. Klasa kontrolera musi nosić nazwę Controller_Kontroler, natomiast metody będące akcjami - AkcjaAction.


Przykładowy kontroler

[PHP] pobierz, plaintext 
<?php
class Controller_Example extends Rapide_Controller
{
  public function ExampleAction()
  {
	echo 'Example action from controller Example';
  }
}
?>
[PHP] pobierz, plaintext 

Teraz wystarczy w przeglądarce wpisać adres: http://TwojAdres.pl/www/?controller=Exampl...;action=Example.
Rezultatem pracy frameworka będzie wyżej podany komunikat.

Metody klasy Rapide_Controller
Kontroler bazowy w Rapide został tak zaprojektowany, aby uprościć i przyśpieszyć budowę aplikacji. Poniższa lista zawiera metody, których warto używać:

getParameter($sParameter)
Zwraca parametr GET przekazany w adresie do kontrolera. W przypadku braku parametru wzraca null.


hasParameter($sParameter)
Zwraca wartość logiczną informującą, czy istnieje parametr GET przekazany w adresie.


getConfig()
Zwraca obiekt konfiguracji dla danego kontrolera. Dane konfiguracyjne pobierane są
z tablic php zapisanych w katalogu konfiguracji kontrolerów.


getView($sView)
Zwraca obiekt danego widoku. Widok pobierany jest z katalogu widoków.


getModel($sModel)
Zwraca obiekt wybranego modelu. Model pobierany jest z katalogu widoków.


getUser()
Zwraca obiekt User, który pozwala na zapis danych sesyjnych.


getLanguage()
Zwraca obiekt języka. Dane językowe dla kontrolera ładowane są wcześniej w pluginie
Rapide_Plugin_Language.


forward($sController = null, $sAction = null, array $aParameters = array())
Pozwala na określenie następnej akcji do wykonania. Pozostawienie wartości pustych spowoduje
forwarodwanie na domyślny kontroler.


redirect($sController = null, $sAction = null, array $aParameters = array())
Pozwala wykonać przekierowanie na inną akcję. Pozostawienie wartości pustych spowoduje
przekierowanie na domyślny kontroler.


Każdy kontroler posiada domyślną akcję Index. Jest ona wywoływana, jeżeli akcja nie zostanie
określona.


Przykładowe kody

Kontroler User - akcja zmiany hasla dla zalogowanego uzytkownika

[PHP] pobierz, plaintext 
<?php
 
class Controller_User extends Rapide_Controller
{
  public function PasswordAction()
  {
	$oForm = new Rapide_Form;
 
	if(!$oForm->isSubmitted())
	  return $this->getView('UserPassword');
 
	$sPassword  = $oForm->get('password');
	$sPassword2 = $oForm->get('password2');
 
	if($sPassword != $sPassword2)
	{
	  $aErrors[] = $this->getLanguage('Controller', 'User', 'Password', 'Error', 'Match');
 
	  $oView = $this->getView('UserPassword');
	  $oView->errors = $aErrors;
 
	  return $oView;
	}
 
	$iUser = $this->getUser()->id;
 
	$oUser = $this->getModel('User');
	$oUser->load($iUser);
 
	$oUser->password($sPassword);
	$oUser->save();
 
	$this->redirect();
  }
}
 
?>
[PHP] pobierz, plaintext 

Widok i szablon widoku dla tej akcji

[PHP] pobierz, plaintext 
<?php
class View_UserPassword extends Rapide_View_Html_Extended
{
  public function __construct()
  {
	$this->setTemplate('UserPassword');
  }
}
?>
[PHP] pobierz, plaintext 

[HTML] pobierz, plaintext 
<?php $this->title = $this->lang('Controller', 'User', 'Password', 'Title'); ?>
 
<h1><?= $this->lang('Controller', 'User', 'Password', 'Header') ?></h1>
 
<?php require_once('formErrors.inc.php'); ?>
 
<form action="" method="post">
  <p>
    <?= $this->lang('Controller', 'User', 'Password', 'Password') ?>: <br/>
    <input type="password" name="password">
  </p>
 
  <p>
    <?= $this->lang('Controller', 'User', 'Password', 'Password2') ?>: <br/>
    <input type="password" name="password2">
  </p>
 
  <p>
    <input type="submit" name="submit" value="<?= $this->lang('Form', 'Submit') ?>">
  </p>
</form>
[HTML] pobierz, plaintext 

Jak już wspomniałem - framework napisałem dla siebie. Mam nadzieję, że komuś może się przydać, chociaż w celach edukacyjnych.

Pozdrawiam, Adrian J. Pawlik.

Ten post edytował Prph 5.11.2006, 19:56:50

Świetny framework - podoba mi się... bardzo ciekawe rozwiązania w nim zastosowałeś, gratuluję pomysłów i przemyśleń!

Przeglądam go już troszkę i kilka pytań mi się narzuciło, mianowicie...

Jak działa u Ciebie dokładnie:
- Access Control List - system kontroli dostępu - mógłbyś podać jakiś przykład w kodzie jak to działa i jak to definujesz w którym miejscu gotowej aplikacji?

- interesuje mnie jeszcze działanie łańcucha akcji bo też widzę, że jest ciekawie rozwiązane... czy dzielisz akcje na akcje logiczne i akcje widoki? Czy po prostu gdy ostatnia akcja się zakończy, to przekazuje ona dane do uaktywnionego przez nią widoku. Jak to u Ciebie dokładnie wygląda z akcją ostatnią wyświetlającą wynik działania akcji wcześniejszych?
Może też jakiś przykładowy kod.

- jaka jest dokładna różnica między metodą forward a redirect klasy Rapide_Controller, czy nie lepiej zastosować tylko samą metodę forward? Możesz mi wytłumaczyć, hmm... w jakiś prosy sposób cel tego, bo do końca nie rozumiem tej kwestii.

Ten post edytował Quickest 7.09.2006, 14:17:42

Wyglada praktycznie tak samo jak Zend Framework. Kod jest ładnie napisany, no ale jest bardzo wzorowany na wspomnianym framework'u.

@Quickest: Pewnie tak samo jak w ZF, forward zmienia kacje a redirect zmienia akcje z kontrolerem.

Rzut na sam widok katalogów wygląda jak Zend.
Powiem szczerze, że też wzoruje się na zorganizowaniu Zenda, jednakże ja piszę trochę inaczej. Dopisuje obiekty których wyżej wspomniany framework nie posiada. Mam też inny styl. Upraszczam go maksymalnie.

System kontroli prezentowany jest przez klase ACL. Klasa acl przyjmuje definicje dostepu, ktore reprezentowane sa przez klase ACL_Access. Wszystko przeprowadza plugin: Rapide_Plugin_ACL. Jego dzialanie jest nastepujace:
1. Pobierz informacje z konfiguracji kontrolera jakie grupy maja miec dostep.
2. Dodaj definicje Access do ACLa
3. Pobierz informacje, ktore sa zablokowane.
4. Dodaj definicje do ACLa.
5. ACL sprawdza czy obecny uzytkownik ma prawa do danej akcji, jezeli nie - zwraca akcje Error403.


Przejrzyj kod ow plugina - wszystko jest ladnie zaprezentowane. Pamietaj, ze konfiguracja kontrolera trzymana jest w katalogu Configs jako plik z tablica php.



Nie mam podzialu na akcje. Jezeli ktos wyswietli widok a nastepnie ustawia kolejna akcje - na ekranie dostanie wynik 2 akcji. O tym nalezy pamietac. Jezeli korzystamy z widoku, to w chwili kiedy chcemy go wyswietli, zwyczajnie zwracamy go. Zobacz przykladowe kody - tam zwracam widok, a Rapide go wyswietla.



Forward: Przekaze tzw. Token (blasa zawierajaca kontroler, akcje i parametry akcji). Rapide uruchomi nastepna akcje. Nie nastapi przeladowanie strony.

Redirect: Nie przekazuje tokena - wysyla naglowek Location do przegladarki. Przegladarka wtedy wlaczy inna strone.

Kiedy stosowac jedno, kiedy drugie? W sumie i jedno i drugie mozna stosowac zawsze. Redirect powodue przeladowanie strony, forward nie. Ale po redirect na pasku przegladarki mamy adres obecnej akcji (tej na ktora przekierowalismy). Po forward na pasku znajduje sie ten sam adres - starej akcji.

@hwao, @Turgon: Tak, jak wspomnailem wzorowalem go na Zend Framework. Oto powody:

1. Struktura katalogow - swietne rozwiazanie, latwy __autoload,
2. Male, elastyczne klasy
3. Te klasy wspoldzialaja ze soba naprawde luzno.

Wcale nie oznacza, ze Rapide jest skopiowanym kodem z Zenda. Wiele kodu sie zgadza, a jednak nie wzorowalem sie na Zend. Na pewno zaczerpnalem pomysly z: Front kontroler, dispatcherem, pluginami i konfigiem. No pomysl na uzycie helperow takze zobaczylem w Zend. W zasadzie napisalem helpery, a pozneij zobaczylem ze w Zend jest to zrobione niemal idenycznie.

Pozdrawiam, Adrian.

Przede wszystkim - brak jakiejkolwiek dokumentacji w kodzie strasznie utrudnia jego przeglądanie.. pomijam fakt, że póki co jeszcze brakuje przykładowej aplikacji


Kontekst. Jeden kontekst. W Mojavi 3.0 kontekst był singletonem. W 4.0 nie było go wogóle, w jego miejsce był użyty ServiceLocator.


To niewątpliwa zaleta. Widziałem, że używasz interfejsów w miejsce klas abstrakcyjnych. Troche mnie dziwi i zaskakuje konwencja nazewnicza i aż takie wyróżnienie interfejsów. Z mojego punktu widzenia nie ma większego sensu aż tak rozbijać nazw, bo tworzą się przez to strasznie długie łańcuchy. Czy nie lepiej użyć
Rapide_Router zamiast Rapide_Router_Interface?


Widok widokiem, implementacji MVC jest wiele. Nie wiem czy zauważyłeś, ale w Mojavi 4 nie było konieczności dziedziczenia ze SmartyView/HtmlView, ponieważ były użyte Renderery. Dzięki nim możesz w bardzo prosty sposób tworzyć różne fragmenty stron w wielu technologiach. U Ciebie widzę jeszcze zaszłość po Mojavi 3, gdzie dziedziczenie jest wymuszone. Przydatną rzeczą jest również rozbicie widoków w zależności od content-type. Jest to bardzo fajna sprawa, ponieważ w połączeniu z routes, które powinny dawać możliwość zmiany typu outputu daje to nieprawdopodobne wręcz możliwości.
Co do Apletów - rozważyć należy czy to jest element widoku? Myślę, że Aplet jest mimo wszystko częścią, która jest bardziej zbliżona kontrolerowi. Dlaczego? W chwili obecnej decyzję o tym, co ma się stać z Apletem pozostawiasz widokowi. To niedobrze, zgodnie z filozofią OOP obiekt powinien wiedzieć sam co ma ze sobą zrobić. Rozważ to czy nie użyć "layoutu" w połączeniu z rejestrowaniem Apletów podatnych na zdażenia. W Javie jest taka technologia, która zwie się Portlety. Jest to rozszeżenie a właściwie zawężenie Servletów. Na portlecie można wykonać kilka akcji - hide/show, valid etc.


Z tym, że póki co przykładów brak


To nie jest poprawne podejście. User w Mojavi to nie jest handler sesji. To są dane obecnego użytkownika, jego sesja. To, jakiego handlera użyje programista nie powinno być zależne od frameworka. Fakt, framework może oferować taką funkcjonalność, ale nie w tak ścisłym związku z sesją.


Przykład?


Myślę, że w chwili obecnej tworzenie kolejnego poziomu abstrakcji do bazy danych to pomyłka. W chwili, gdy PDO jest i na pewno zostanie powinieneś bardziej się skupić na jego rozszeżaniu. Ponadto PDO jest znacznie szybsze niż natywne funkcje php.


A może obsługa gettexta?


Przykład? Konfiguracja?


Przykład? Inna sprawa to to, że nie ma sensu wiązać się aż tak bardzo z tą klasą. Dlaczego? Lepsze jest dostarczenie mechanizmów, które ułatwiają prezentacje błędów niż wiązanie widoku z formularzem.
Po co mi klasa, która tylko i wyłącznie tworzy mi input? Po to by określić validator? Wolę to wyłączyć do oddzielnego pliku i tam to trzymać, tak bym mógł w jednym miejscu zmieniać zasady sprawdzania np nazwiska.

Mam nadzieje, że te uwagi będą dla Ciebie przydatne i dzięki nim Twój framework stanie się lepszy.

Pozdrawiam,

Nadal nie rozumiem, tych praw dostępu, może dlatego, że pierwszy raz mam z tym do czynienia...
Jak wygląda taka konfiguracja pliku kontrolera? Przykład?

Przypuśmy plik konfiguracyjny kontrollera z przykładu:

np. /application/Config/Controller/example.php

[PHP] pobierz, plaintext 
<?php
$aConfig = array(array('example' => array('Security' => array('Groups' =>
array('Deny' => array('banned_user', 'moderators'), 'Allow' => array('admins'))))));
?>
[PHP] pobierz, plaintext 

Tak wygląda przykładowy plik konfiguracyjny? yyy...?

hmm... może za dużo nad tym siedzę i mam już mętlik w głowie i wszystko mi się miesza. Mianowicie nie rozumiem jednej rzeczy. ... na podstawie jakich danych user jest identyfikowany czy może mieć dostęp do danej metody?

Jak rozumieć metody: isAuthenticated() oraz setAuthenticated() w klasie Rapide_User?
Czy one nie powinny być wywoływane w trakcie sprawdzania danych user'a o zalogowaniu?
Albo może inne pytanie... jeżeli autoryzacja się nie powiedzie to przekierowujemy usera na akcję z formularzem logowania?

Ehh... wszystko już mi się to miesza jak widać , może ktoś mi rzuci światło na to, jak to dokładnie wygląda np. z akcją logowania usera na stronę w powyższym frameworku

Ten post edytował Quickest 7.09.2006, 18:21:55

Wszystko przez to ze nie udostepnilem dokumentacji. Nie umiem pisac dokumentacji :/

Konfiguracja kontroli dostępu

Konfiguracja jest zapisywana w pliku konfiguracyjnym kontrolera. Domyslnie jest to application/Config/Controller/Nazwa.php

Przykladowy plik wygląda następująco:

[PHP] pobierz, plaintext 
<?php
 
$aConfig['Actions']['Password'] = array
(
  'Security' => array
  (
	'Groups' = array
	(
	  'Allow' => array('admin', 'moderator'),
	  'Deny' => array('nieproszony_gosc')
	)
  )
);
 
?>
[PHP] pobierz, plaintext 

W tym przypadku dostęp będą mieli użytkownicy którzy posiadają grupy admin i moderator, ale nie posiadają grupy nieproszony_gosc. Czyli np. jezeli mamy uzytkownika Adrian z grupą moderator, to on uzyska dostęp. Jeżeli mamy użytkownika Joasia z grupami admin i nieproszony_gosc, to Joasia nie dostanie dostępu.

Autentyfikacja uzytkownika odbywa sie w klasie Rapide_User. Za pomoca metody isAuthenticated() klasa informuje, czy użytkownik sie zalogował (o tym za chwile). Ponadto metoda getGroups zwraca tablice z grupami, jakie ma użytkownik.

Można zdefiniować, aby dana akcja wymagała jedynie zalogowania użytkownika. Czyli nie musi ustawiać jakie grupy mają dostęp. Wystarczy wówczas zapisać taką konfigurację:

[PHP] pobierz, plaintext 
<?php
$aConfig['Actions']['Password'] = array
(
  'Security' => true
);
?>
[PHP] pobierz, plaintext 

Wartosc Security moze byc dowolna. Wazne zeby sekcja Security byla utworzona.

Oczywiście, wszystko nabiera sensu w chwili, kiedy użytkownik się zaloguje. Niżej przedstawiam akcję logowania:

[PHP] pobierz, plaintext 
<?php
 
class Controller_Auth extends Rapide_Controller
{
  public function LoginAction()
  {
	$oForm = new Rapide_Form;
 
	/*
	  Check the form. If it has not been submitted,
	  display the form.
	*/
 
	if(!$oForm->isSubmitted())
	{
	  return $this->getView('AuthLogin');
	}
 
	$sLogin	= $oForm->get('login');
	$sPassword = $oForm->get('password');
 
	/*
	   Check the data and display the form on failure.
	*/
 
	if(empty($sLogin) || empty($sPassword))
	{
	  $aErrors[] = $this->getLanguage()->get('Controller', 'Auth', 'Login', 'Error', 'Empty');
 
	  $oView = $this->getView('AuthLogin');
	  $oView->errors = $aErrors;
 
	  return $oView;
	}
 
	/*
	   Check the login using DAO.
	*/
 
	$oUserDAO = $this->getModel('UserDAO');
 
	$iUser = $oUserDAO->getIdByLogin($sLogin, $sPassword);
 
	if(!$iUser)
	{
	  $aErrors[] = $this->getLanguage()->get('Controller', 'Auth', 'Login', 'Error', 'Data');
 
	  $oView = $this->getView('AuthLogin');
	  $oView->errors = $aErrors;
 
	  return $oView;
	}
 
	/*
	   Everything is correct. Set the user and forward
	   to default action.
	*/
 
	$oUserModel = $this->getModel('User');
	$oUserModel->load($iUser);
 
	$aGroups = $oUserModel->groups();
 
	$oUser = $this->getUser();
	$oUser->setAuthenticated();
	$oUser->setGroups($aGroups);
 
	// Set additional data
 
	$oUser->id = $iUser;
	$oUser->firstName = $oUserModel->firstName();
	$oUser->lastName  = $oUserModel->lastName();
 
	$this->forward();
  }
 
  public function logoutAction()
  {
	$this->getUser()->destroy();
	$this->forward();
  }
}
 
?>
[PHP] pobierz, plaintext 

Ostatnie linie akcji Login przedstawiaja sposob autentykacji użytkownika oraz ustawienie dodatkowych informaacji (np imie i nazwisko).

Teraz już wszystko jasne jak słońce, gdy zobaczyłem kod
Zaczyna mi się coraz bardziej podobać ten framework :roll2:

Jeszcze dwa pytania jakie mi się nasuwają to:



no właśnie... a interesują mnie jak zamieścić stałe elementy typu np. pytania ankiety itp. tzn. jak dokładnie działają Applety, jak są obsługiwane?

I kolejne pytanie z serii "sto pytań do twórcy"... w którym miejscu wykorzystujesz Rapid_Log w frameworku i też może mały przykład?

W szablonie mamy możliwość używania tzw. pomocników. Pomocnicy, jak wskazuje nazwa, pomagają nam w generowaniu szablonu. Pomocnikiem może być np. metoda generująca ładną datę, albo przycisk.

W Rapdie pomocnicy są obiektami. Ich klasy znajdują się w katalogu Rapide/View/Helper/. Dostep do pomocnika jest następujący:

[PHP] pobierz, plaintext 
<?php
// plik z szablonem:
 
echo $this->url('Kontroler', 'JakasAkcja', array('paremetr' => 'wartosc'));
?>
[PHP] pobierz, plaintext 

Url jest pomocnikiem prosto z Rapide. Pierwszy parametr, to kontroler, drugi akcja, a trzeci to tablica asocjacyjna parametrow. Wynik bedzie nastepujacy:

[HTML] pobierz, plaintext 
http://127.0.0.1/katalog_rapide/www/?contr...arametr=wartosc
[HTML] pobierz, plaintext 

W ten sposob mamy pewnosc ze zawsze wygenerujemy poprawny adres url, zgodny z naszym Routerem (Router jest obiektem, ktory wyciaga z adresu nazwe kontroler, akjce i parametry - czyli parsuje przejazany adres url).

Jak tworzyc wlasne klasy pomocnikow?

1. Utworz plik o nazwie Pomocnik.class.php w katalogu Rapide/Rapide/View/Helper lub application/View/Helper/.
2. Nazwa klasy pomocnika musi byc w formacie View_Helper_Pomocnik.
3. klasa musi posiadac metode execute, do ktorej przejazane zostana argumenty.

Przyklad pomocnika

[PHP] pobierz, plaintext 
<?php
 
class Rapide_View_Helper_Url extends Rapide_View_Helper
{
  public function execute($sController = null, $sAction = null, array $aParameters = array())
  {
	return Rapide_Controller_Front::getInstance()
		   ->getRouter()
		   ->url($sController, $sAction, $aParameters);
  }
}
 
?>
[PHP] pobierz, plaintext 

A i dodam, ze helper zapisany w katalogu Rapide, nie aplikacji musi miec nazwe klasy w formacie Rapide_View_Helper.

Aplety

Do osadzania stalych elementow, jak menu, sonda etc uzywa sie apletow. Aplet ma funkcjinalnosc zblizona do kontrolera - ma dostep do widoku, modelu, konfiguracji, Usera (sesji) i jezyka.

Aplety zapisujemy podobnie jak helpery, ale tylko w katalogu application/View/Applet/
Plik musi nazywac sie MojAplet.class.php. Nazwa klasy: View_Applet_MojAplet.

Przykladowy aplet:

[PHP] pobierz, plaintext 
<?php
 
class View_Applet_User extends Rapide_View_Applet
{
  public function execute()
  {
	if(!$this->getUser()->isAuthenticated())
	  return;
 
	$oView = $this->getView('Applet');
	$oView->setTemplate('AppletUser');
 
	return $oView->fetch();
  }
}
 
?>
[PHP] pobierz, plaintext 

NAlezy pamietac, ze Aplet nie wyswietla szablonu - zwraca go metoda Fetch.
Aplet ma podobne metody jak kontroler. Aplety dzidziczymy z Rapide_View_Applet i polecam zapoznac sie z ta klasa - jest prosta, wiadac metody. Konfiguracje Apletu zapisujemy tak jak kontrolera, ale w katalogu Config/Applet/

Dlaczego stosuje tutaj setTemplate? Normalnie powinienem zrovic to w widoku, bo co interesuje Kontrolera jaki jest szablon. nie on wyswietla dane, tylko widok i to widok powinien wiedziec. Ale w przypadku apletow mozna tak zrobic, bo:

1. Aplety i tak najczesciej beda HTML.
2. Po co robic 10 widokow, mozna zrobic jeden Applet i ustawiac w nim szablon.
3. Aplet jest na tyle mala czescia aplikacji, ze mozna w nim ustawiac szablon - dla prostosty.

Dodam, ze aplet ma jedna metode - Execute i to ona zosanie wywolana.

Z szablonu aplet wywoluje sie nastepujaco:

[PHP] pobierz, plaintext 
<?php
// korzystamy z pomocnika Applet:
 
echo $this->applet('MenuBoczne');
?>
[PHP] pobierz, plaintext 

Pozdrawiam, Adrian.

Ten post edytował Prph 8.09.2006, 09:08:36

A tak na raty skaczac po plikach
form.class.php

[PHP] pobierz, plaintext 
<?php
private function _trim(array & $aArray)
  {
	foreach($aArray as $sKey => $mValue)
	{
	  if(is_string($mValue))
	  {
		$aArray[$sKey] = trim($mValue);
	  }
	}
  }
?>
[PHP] pobierz, plaintext 

array_map" title="Zobacz w manualu php" target="_manual - piszac frame'a przydaje sie b.dobra znajomosc samego php

File.class.php - kontrolujesz czy $_FILES zawiera dany klucz - czyli z klasy formularza mam zwracac wartosc o niestniejacym indeksie Rozumiem pikne E_WARNING

class Rapide_Util_Syntaxer_Php - z php wywalili f-cje highlight_ Ja nic nie wiem

Raz z kodzie stosujesz array_key_exists raz isset - zdecyduj sie

Ten post edytował NuLL 9.09.2006, 02:04:26

Racja, jest array_map. Zapomnialem o nim


Jezelu juz to NOTICE, ale nie bardzo Cie rozumiem. piknie przy poraniu, czy przy sprawdzaniu? Przy tym drugim na pewno nie piknie.


A tu mnie zaskoczyles (mile). O tym nie wiedzialem. Ciekawa funkcja, chociaz piszac cos wlasnego mam kontrole nad kolorami.



Tak wiem. Jest jeszcze kilka rzeczy w ktorch nie jestem konsekwentny, ale to oczywiscie jest do poprawy.

Dziekuje za uwagi NuLL.

Pozdrawiam, Adrian.

Rapide_Util_Syntaxer_Php

Zaskoczyłeś mnie... rozumie sens pisania takiej funkcji do SQL (ostanio taka pisalem) ale dla php?

php udostepnia 2 mechanizmy, jeden to tokenizer a drugi to wyzej wspomniany highlight_string/file w 1 mozesz dodolnie pokolorowac, w 2 masz tez sporo pole manewru, gdyz mozesz ustawic sobie jaki chcesz kolor (tylko tam masz juz pare sekcji).


isSet" title="Zobacz w manualu php" target="_manual() jest sporo szybszy (pare razu) od array_key_exists" title="Zobacz w manualu php" target="_manual()

A w highlight nie masz? Poza tym Twoja klasa na pewno robi to dużo wolniej niż funkcja.

@hwao: dzieki za informacje. Mialem pozniej zabrac sie za przetesotwanie obu funkcji.

@seaquest: w wolnej chwili zapoznam sie highlightem. Jak wspomnialem po prostu nie wieedzialem, ze w php jest taka funkcja. Chociaz cos kojarze. No nie wazne... zapomnialem o niej. Dziekuje za informacje.

Adrian.

Ja am takie pytanie:

Tutaj odwolujemy sie do metody klasy rapide jak do metody statycznej

[PHP] pobierz, plaintext 
<?php
$oController = Rapide::getController($oToken->getController());
?>
[PHP] pobierz, plaintext 

A tak wyglada deklaracja tej metody:

[PHP] pobierz, plaintext 
<?php
public function getController($sController)
  {
	if(!self::controllerExists($sController))
	{
	  $sError = sprintf('Controller %s does not exist', $sController);
	  throw new Rapide_Exception($sError);
	}
 
	/**
	 *  Attention: Controller's file loaded in self::controllerExists().
	 */
 
	$sControllerClass = 'Controller_' . $sController;
	return new $sControllerClass;
  }
?>
[PHP] pobierz, plaintext 

Metoda nie jest zadeklaroweana jakos attyczna, a jednak odwolujesz sie do niej jak do statycznej. Co pominalem ?

I nastepne:

Tutaj jest kawalek routera:

[PHP] pobierz, plaintext 
<?php
class Rapide_Router implements Rapide_Router_Interface
{
  public function execute()
  {
	if(isset($_GET[_ROUTER_CONTROLLER_ACCESSOR]))
	  $sController = $_GET[_ROUTER_CONTROLLER_ACCESSOR];
	else
	  $sController = _ROUTER_CONTROLLER_DEFAULT;
 
	if(isset($_GET[_ROUTER_ACTION_ACCESSOR]))
	  $sAction = $_GET[_ROUTER_ACTION_ACCESSOR];
	else
	  $sAction = 'Index';
 
	$oToken = new Rapide_Dispatcher_Token(ucfirst($sController), ucfirst($sAction), $_GET);
 
	if(!Rapide_Controller_Front::getInstance()
	   ->getDispatcher()
	   ->isDispatchable($oToken))
	{
	  $oToken = new Rapide_Dispatcher_Token('Error', 'Error404');
	}
 
	return $oToken;
  }
?>
[PHP] pobierz, plaintext 

Jesli nie jest podana akcja w URLu albo akcja jest bledna ustawiana jest akcja index.

Tutaj mamy zragment controllera

[PHP] pobierz, plaintext 
<?php
public function IndexAction()
  {
	$this->forward();
  }
?>
[PHP] pobierz, plaintext 

I deklaracja forward

[PHP] pobierz, plaintext 
<?php
public function forward($sController = null, $sAction = null, array $aParameters = array())
  {
	if(!isset($sController))
	{
	  $sController = _ROUTER_CONTROLLER_DEFAULT;
	  $sAction = 'Index';
	}
 
	$this->_oNextToken = new Rapide_Dispatcher_Token($sController, $sAction, $aParameters);
  }
?>
[PHP] pobierz, plaintext 

Z tego co widze, to jesli forward jest pusty to poleci defaultowy kontrolelr z akcja index. Akcja index robi pusty forward ? powinno sie zapletlic, co znow pominalem ?

Ten post edytował thornag 11.09.2006, 12:51:19

Ad1. Przeoczenie. Powinno byc static. Dzieki.

Ad2. Nie zapetli sie. Wybierze kontroler Index, akcje index. Jezeli akcja nie zostala okreslona wybierze domyslnie index. Ta jest definiowana domyslnie w bazowej klasie kontrolera i forwarduje na domyslny kontroler. Wymagane jest aby kontroler index mial zdefionowana wlasna metode indexAction.

Adrian.

Prph a mógłbyś wyjaśnić bardziej działanie klasy Rapide_View_Html_Extended, kiedy jest wywoływana, zasada jej działania itp

Pozdrawiam

Widok rozszerzony sluzy do dekorowania tresci. Wezmy pod uwage taki przyklad:

Mamy stopke, naglowek i menu boczne. Nasza tresc wyswietlana jest w srodku (taki standardowy przyklad). Wiadomo, ze widoki uzywaja szablonow (w Rapide sa to szablony php). Zalozny, ze mamy akcje Pokaz nowosci oraz dodaj nowosc. Nie byloby wygodnie, gdyby kazdy ten szablon byl postaci:

[HTML] pobierz, plaintext 
<html>
<body>
  <div id="top">
    <h1>Naglowek strony</h1>
  </div>
 
  <div id="zawartosc">
 
  <!-- Tu nasz szablon dla akcji -->
 
  </div>
 
</body>
</html>
[HTML] pobierz, plaintext 

W tym celu uzyjemy widoku rozszerzonego. Utworzymy szablon glowny o nazwie Main.php. Jego zawartosc bedzie taka jak przedstawiona wyzej. W miejscu, gdzie jest zawartosc wyswietlamy zmienna $this->content.

W rezultacie nasz widok zostanie udekoroweany o szablon Main.php. Nazwa tego szablonu zdefiniowana jest jako stala w samej klasie widoku.

Przyklad naszego widoku:

[PHP] pobierz, plaintext 
<?php
class View_MojWidok extends Rapide_View_Html_Extended
{
  public function __construct()
  {
	$this->setTemplate('SzablonDlaAkcji');
  }
}
?>
[PHP] pobierz, plaintext 

Ponadto szablon dekorujacy mozemy okreslic metoda setMainTemplate($nazwa).

Szablony akcji moga potrzebowac zaladowac css lub javascript. Sluza do tego helpery css i js:

[PHP] pobierz, plaintext 
<?php
// szablon akcji
 
$this->css('CssDlaTejAkcji.css');
$this->js('JSDlaTejAkcji.js');
?>
[PHP] pobierz, plaintext 

Wybrane pliki musza znajdowac sie w katalogu szablonu odpowiednio w css/ i js/

Dodam jeszcze, ze widok rozszerzony nie jesy wykonywany w jakis inny sposob. Po prostu programista swoj widok nie dziedziczy po Rapide_View_Html a po Rapide_View_Html_Extended.

Pozdrawiam, Adrian.

Ten post edytował Prph 17.09.2006, 18:51:21

Czy jest jeszcze jakieś miejsce skąd można pobrać Rapide framework. Pytam ponieważ link podany w sygnaturze prph jest 'nieaktualny'