Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Nauka MVC i url'e
Forum PHP.pl > Forum > PHP
kamilos12
Witam,
napisałem klasę do ładowania modeli, wywoływanie następuje w sposób np. nazwa.pl/article/showarticle/id, chciałbym się dowiedzieć w jaki sposób stosować polskie url'e np. nazwa.pl/artykul/id
Zastanawiam się czy np:
  1. $replacements = array(
  2. 'artykul/' => 'article/showarticle/'
  3. );
  4. $_GET['url'] = str_replace(array_keys($replacements), $replacements, $_GET['url']);

Czy to ma jakiś sens, czy jakoś inaczej do tego podejść?
aras785
Mało się na tym znam, ja zrobiłem to tak: https://github.com/aras123/MiniFramework/bl...ork/Request.php

I później mogę w obie strony generować ten ładne url'e.

czyli np:
  1. echo $this->request->url(array('controller'=>'index','action'=>'index','id'=>'2'));


Wygeneruje mi to co zdeklarowałem w w config router. Tak ja to zrobiłem i może coś Ci się przyda. Pozdrawiam


Martin-ZG
Na youtube jest super tutorial MVC wpisz w wyszukiwarkę :"PHP: Create Your Own MVC"
Stef@n
Na ile ten tutorial jest poprawny?
!*!
Cytat(Stef@n @ 26.10.2013, 09:27:20 ) *
Na ile ten tutorial jest poprawny?


Na jakieś 5% ... nazwy plików index i htaccess się zgadzają ;)
Zabrakło tam sformułowania iż link http://domena/kontroler/metoda/wartość jest w celach szkoleniowych, nikt na środowisku produkcyjnym nie używa odpalania kontrolerów w takiej formie.
Stef@n
ale czy czasem Symfony2 i ZF nie używają tego typu linków? Czy coś nie załapałem?
!*!
Tu nie chodzi o to, kto czego używa, tylko jak z tego korzystać. Nie raz spotyka się aplikacje, pisane przez ludzi którzy zaczynają. Uznali, że skoro S2, ZF czy inne FW używają tego typu routera, to jest to bezpieczne i poprawne, tym czasem to niekiedy luka bezpieczeństwa, ponieważ nie używają przy tym chociażby ACL czy sprawdzania danych.

Skoro przez http://domena/kontroler/metoda/wartość możesz odpalić dowolny kontroler i każdą metodę z wartością, to jest to tak samo głupie jak wczytywanie plików po nazwie przez GET, taki mechanizm dobry jest przy pisaniu aplikacji, to zwyczajnie wygodne dla programisty.

Jestem zwolennikiem routera opartego o pregi, dzięki temu jeden (dowolny i nieszablonowy) link jest przypisany do jednego kontrolera, bez możliwości manipulacji.
markonix
Tak naprawdę routing kontroler/metoda to analogia do strukturalnej aplikacji i utworzenia pliku o nazwie kontroler.php i w nim ewentualnie jakiś switch/case.
Tu i tu plik może zostać bezpośrednio wywołany z dowolnymi argumentami i metody zabezpieczenia tego są takie same.

Na korzyć MVC - jest możliwość zabezpieczenia tego w przejrzystszy sposób, można skorzystać z konstruktora (globalny ACL), można metody zrobić prywatnymi tym samym zablokować możliwość bezpośredniego wywołania i ogólnie obudować to obiektowo.

Jeżeli wykonujemy jakieś operacje CRUD na obiektach z własnością to pierwszym krokiem powinno być sprawdzenie praw dostępu - ale tak jak wyżej - nie ma tu większej różnicy w podejściu MVC czy strukturalnym - logika jest taka sama.
Stef@n
OK, czyli logika MVC została zachowana. Ale jak zrobię routing podobnie, ale z lepszym zabezpieczeniem będzie dobrze czy raczej. Pomyśleć nad własnym rozwiązaniem, lub inną budową linków np. kontroler,metoda,id,jakis-tekst.html
Proszę się nie dziwić moimi pytaniami, ale chciałbym MVC ugryść trochę po od siebie a nie poprzez gotowy framework.
!*!
Cytat(Stef@n @ 26.10.2013, 17:12:05 ) *
OK, czyli logika MVC została zachowana. Ale jak zrobię routing podobnie, ale z lepszym zabezpieczeniem będzie dobrze czy raczej. Pomyśleć nad własnym rozwiązaniem, lub inną budową linków np. kontroler,metoda,id,jakis-tekst.html


Można i tak, ale po co Ci w linku w ogóle jakieś informacje o kontrolerze czy metodzie ?

link: http://domena/pokazwpis/9331
  1. 'pokazwpis/[0-9]+' => array('controller' => 'AppName\Blog', 'method'=> 'show', 'param'=>1)
  2. );


edycja:

I to zbuduje

  1. $o = new AppName\Blog;
  2. $o-> show('9331');
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.
Invision Power Board © 2001-2025 Invision Power Services, Inc.