Wolfie
31.08.2009, 18:45:59
Witam,
Mam takie krotkie pytanko
Zaimplementowalem juz prawie caly wzorzec mvc w mojej aplikacji, jeszcze trzeba kilka rzeczy zrobic no i tutaj pojawila sie sprawa logowania uzytkownika no i pytanie z tym zwiazane
Gdzie mam umiescic session_start() ?
Czy na poczatku kontrolera ? poprostu poza klasa ?
Czy w widoku headera html ?
Void
31.08.2009, 18:57:44
Najlepiej w pliku bootstrap, czyli tam gdzie inicjalizujesz wszystkie obiekty swojej aplikacji, front controller itp. zależy jak skonstruowana jest twoja aplikacja mvc.
Wolfie
2.09.2009, 10:16:47
Moja aplikacja jest skonstruowana mniej wiecej tak :
index.php gdzie inicjalizowane sa wszystkie obiekty :
<?php
require_once('class.Database.php');
require_once('class.ActiveRecord.php');
require_once('class.Filter.php');
require_once('class.MailboxAccess.php');
require_once('class.MailboxView.php');
require_once('class.MailboxController.php');
$dao = new MysqlDatabase('localhost','root', 'wmateusz', 'spam');
$tokenRow =& new TokenRow($dao);
$tokenTable =& new TokenTable($dao);
$totalsRow =& new TotalsRow($dao);
$totalsTable =& new TotalsTable($dao);
$mailboxAccess =& new MailboxAccess();
$mailboxController =& new MailboxController($mailboxAccess, $_POST);
echo $mailboxController->display(); ?>
a nastepnie kontroler ktory odpowiada za widoki :
<?php
class MailboxController extends MailboxView {
function MailboxController (&$model,$postvars=null) {
MailboxView::__construct($model);
$this->header();
switch ($postvars['check']) {
case 'ok':
if(($this->model->connect('gmail.com',$postvars['login'],$postvars['pass'],'993','imap')) == false) {
$this->login();
} else {
$this->inbox();
}
break;
default:
if ( empty ($postvars) ) { $this->login();
}// else {
// $this->inbox();
//}
break;
}
$this->footer();
}
}
?>
czyli session_start() ma byc w index.php czy w kontrolerze ?
W index.php, bo nie widzę żebyś jakiegoś `boota` osobnego ładował, wszystko widzę że ładujesz w index.php - więc tam daj.
$tokenRow =& new TokenRow($dao);
A po co & tutaj...? O ile pamiętam, to się tak w PHP4 robiło.
Co do pytania, chyba lepiej by było w
index.php, a IMHO najlepiej - osobna klasa sesyjna jako helper.
Wolfie
2.09.2009, 11:47:31
erix, chodzi Ci o wszystkie przypadki gdzie jest & ?
phpion
2.09.2009, 12:13:23
Cytat(Wolfie @ 2.09.2009, 12:47:31 )

erix, chodzi Ci o wszystkie przypadki gdzie jest & ?
Tak, w PHP5 nie musisz dawać & bo obiekty domyślnie przekazywane są przez referencję, a nie przez wartość. Z & korzysta się w PHP4.
Swoją drogą:
class MailboxController extends MailboxView
dość ciekawa interpretacja dziedziczenia
Wolfie
2.09.2009, 12:55:07
Cytat
dość ciekawa interpretacja dziedziczenia

Poprostu w koncowym etapie tworzenia skorzystalem z
tego przykladu mvc i zarowno kontroler jak i index.php zapozyczylem ze wspomnianej strony
Crozin
2.09.2009, 13:39:26
Swoją drogą... widzę, że w ogóle ten kod jest pisany pod PHP4. =& czy & przy parametrze funkcji dla obiektów - które w PHP5 są przekazywane domyślnie jako referencje. Brak deklaracji zasięgu (public|protected|private) dla metod. Konstruktor jako NAZWA_KLASY zamiast __construct().
IMO sesje są dosyć mocno związane z użytkownikiem (w sensie, że ogóle os. odwiedzającej stronę, a nie konkretnym użytkownikiem witryny) i we wnętrzu obiektu reprezentującego użytkownika może być wpleciony mechanizm sesji.
Wolfie
2.09.2009, 13:52:01
No tak, ten link co podalem rzeczywiscie jest pisany w php4, sam zwrocilem uwage na ten konstruktor i u siebie poprawilem na bardziej aktualna wersje, wiec oprocz ampersanda i konstruktora sa jeszcze jakies niuanse ? bede chcial ten kod przedstawic pewnie ktoregos dnia na jakiejs rozmowe kwalifikacyjnej wiec chetnie sie dowiem czy sa tam jeszcze jakies inne nalecialosci z php4
Crozin
2.09.2009, 13:59:13
Nie zrozum mnie źle, ale... na prawdę polecałbym zobaczyć manual, a przynajmniej przeczytać w nim rozdział o podstawowych różnicach pomiędzy 4-ką, a 5-tką.
Nie chce mi się przeglądać tamtego linku, ale bardzo dziwnym jest wg mnie tworzenie kontrolera na podstawie widoku. Widok powinien być IMO przekazany do kontrolera by ten mógł nim swobodnie manipulować, ale przecież na zdrowy rozsądek widać, że "kontroler jest rozwinięciem widoku" nie jest prawdą.
Wolfie
2.09.2009, 14:06:02
Czyli porpstu zamiast dziedziczyc po klasie widoku, zrobic osobna klase dla kontrolera i widok przekazywac jako parametr do kontrolera......
Crozin
2.09.2009, 14:42:31
Oczywiście rozwiązań jest wiele, przykładowo jedno mogłoby wyglądać tak:
<?php
interface View{
public function setVar($name, $value);
public function display($filename);
}
class TemplateView implements View{
protected
$vars = array();
public function setVar($name, $value){
$this->vars[$name] = $value;
}
public function display($filename){
require './templates/' . $filename . '.php';
}
}
abstract class Controller{
protected $view;
public function __construct(View $view){
$this->view = $view;
}
//proxy
public function __set($name, $value){
$this->view->setVar($name, $value);
}
public funcion execute($action){
$this->{'execute' . $action}();
$this->view->display($action); //wyświetla szablon o nazwie akcji
}
}
//Jakiś przykładowy kontroler - powiedzmy: moduł aktualności
class NewsController extends Controller{
public function executeIndex(){
$this->news = News::getAll(5); //News to jakiś tam model. getAll(5) na potrzeby przykładu zwraca 5 ostatnich aktualnosci
$this->categories = NewsCategory::getAll(); //zwraca nam wszystkie dostępne kategorie newsów (np. do późniejszego wyświetlenia drzewa kategorii)
}
}
I szablon:
<h1>Aktualności</h1>
<ul>
<? foreach($news as $n): ?>
<li><?= $n->getContent() ?></li>
<? endforeach ?>
</ul>
Oczywiście powyższe to jedynie prosty przykład okrojony do jakiegoś tam niezbędnego minimum. Rozwiązań mogą być dziesiątki - to jest tylko jednym z wielu.
Wolfie
2.09.2009, 15:20:20
Narazie nie mam czasu analizowac ale napewno sie przyda......
viking
2.09.2009, 16:19:52
Tylko po co wynajdywać koło na nowo? Jest tyle frameworków gotowych właśnie po to powstałych aby takich rzeczy nie pisać od nowa. Również lepiej sprawdzonych i obsługujących pomysły na które pewnie byś nawet sam nie wpadł. W ZF sesję ładuję jako plugin kontrolera. postDispatch zamyka, preDispatch inicjuje.
rzymek01
2.09.2009, 16:58:27
Cytat(viking @ 2.09.2009, 17:19:52 )

Tylko po co wynajdywać koło na nowo? Jest tyle frameworków gotowych właśnie po to powstałych aby takich rzeczy nie pisać od nowa. Również lepiej sprawdzonych i obsługujących pomysły na które pewnie byś nawet sam nie wpadł. W ZF sesję ładuję jako plugin kontrolera. postDispatch zamyka, preDispatch inicjuje.
IMHO na etapie nauki powinno się samemu implementować MVC, bo co z tego, że nauczysz się Zenda, jak nie bedziesz wiedział "jak on to robi" i chociażby nie bedziesz w stanie napisac żadnych rozszerzeń do Zenda
Crozin
2.09.2009, 17:06:05
Argument by wiedzieć "jak on to robi" nie jest najlepszy bo nie jesteś w stanie poznać wszystkiego "od strony tech.". Ale w rzeczy samej - takie rzeczy jak implementacja konkretnego wzorca (w dodatku bardzo popularnego) powinna "być zaliczona"
Wolfie
2.09.2009, 19:19:54
Crozin, rzymek01, absolutnie sie z wami zgadzam dlatego wlasnie postanowilem napisac samemu aplikacje oparta na mvc
viking
3.09.2009, 06:37:04
Cytat(rzymek01 @ 2.09.2009, 17:58:27 )

IMHO na etapie nauki powinno się samemu implementować MVC, bo co z tego, że nauczysz się Zenda, jak nie bedziesz wiedział "jak on to robi" i chociażby nie bedziesz w stanie napisac żadnych rozszerzeń do Zenda
Nie zgodzę się. Jeśli chcesz pisać dobrze powinieneś uczyć się z dobrze napisanego kodu. Jakie są efekty gdy postępuje się inaczej widać choćby po pierwszych postach gdzie już na dzień dobry wytkniętych zostało kilka błędów. Oczywiście Zend Fr. dla początkujących jest trudny no ale to samo można powiedzieć o pisaniu własnego projektu. Pamiętam jak ja dostałem skrzydeł gdy ze śmietnika który ciężko było zawsze dostosować i przenieść dalej, zacząłem stosować konwencję PEAR obecną również w ZF. Wcześniej nawet nigdy nie mogłem się zdecydować czy pisać $zmi_nna czy $zmieNna - co projekt to inaczej. Z czasem zaczniesz przeglądać kod źródłowy bo albo trzeba coś rozszerzyć, albo nie do końca pasuje funkcjonalność i w takiej sytuacji najwięcej się nauczysz. Możesz podpatrzyć rzeczy o których wcześniej zupełnie nie wiedziałeś.
Powstał ostatnio fajny artykuł:
http://devzone.zend.com/article/8385-Move-That-Bus Fajnie obrazuje sytuację o której mówię.
Wolfie
3.09.2009, 09:11:17
A ja zwroce uwage na to ze wszystko zalezy od podejscia, ja np chce sie uczyc programowania, niekoniecznie w php , ale w ogolnym rozumowaniu, pozniej mam zamiar przerzucic sie na inny jezyk, a jesli zaczne korzystac z frameworkow zamiast zaglebic sie w strukture kodu to moim zdaniem bedzie to marna nauka......
viking
3.09.2009, 09:56:41
Tyle że jedno nie wyklucza drugiego. Np wczoraj rozszerzałem Zend_Auth. Żeby to zrobić musiałem przekopać się przez calutki kod tego komponentu (na marginesie trochę przesadzają z mieszaniem autoryzacji). I to nie pierwsza taka sytuacja - dorobiłem się już pokaźnego zbioru klas własnych. Wystarczy chwilę pogooglać żeby znaleźć choćby
http://www.zymengine.com itd. Framework wcale nie oznacza że wszystkie zadania ktoś już za ciebie odwalił a ty tylko z tego korzystasz nic nie myśląc. Za to pozwala wyrobić sobie pewne nawyki i podpatrzeć jak lepsi ode mnie coś robią (np. zacząłem regularnie czytywać
http://weierophinney.net/matthew/ ).
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę
kliknij tutaj.