GoldenLine
Zaloguj się
Tomasz Zadora

Tomasz Zadora programuję

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Dostępna wersja inoframeworka 0.0.3 - pojawił się manager połączeń do baz danych.

Została wzbogacona dokumentacja, rozdziały: "Plik konfiguracyjny _ino_cfg.php" (modyfikacja), "Ścieżka wywołania HTTP (request flow)" (modyfikacja), "Zarządzanie połączeniami do baz danych i zapytaniami SQL, klasa \ino\sql\DB" (nowy rozdział).

Dodatkowo pojawiły się klasy \ino\html\Form i \ino\html\FormField - nie są one jeszcze na ten czas udokumentowane.
Link do wypowiedziLink

konto usunięte

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Może zamiast każdorazowo zakładać nowy wątek, zrób jeden i dodawaj nowe posty?

PS. exit()/die() kończący pracę?
Link do wypowiedziLink

konto usunięte

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Może Tomasz chce rozwijać ewentualną dyskusję nad każdym elementem.
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Hej - na razie tworzę osobne wątki, żeby ewentualnie omówić pojawiające się nowe rzeczy,

Jednak jak Wam to przeszkadza to możemy zrobić jeden wątek pt. "Nowe wersje" albo "Nowości" i przykleić. Nie wiem na ten moment co byłoby lepsze - dajcie znać.Tomasz Zadora edytował(a) ten post dnia 06.06.12 o godzinie 10:46
Link do wypowiedziLink

konto usunięte

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Obstawiam jeden wątek.
Ewentualna dyskusja będzie tak czy siak.
A w tym momencie - chronologia jest... chwilowa. Ktoś się wypowie w 0.0.1 i już jest na początku listy wątków.

Ponowię pytanie - czemu skusiłeś się na ubijanie skryptu przed całkowitym wykonaniem?
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

W momencie kiedy zostaje dopasowany URL do jakiejś klasy implementującej \ino\core\URLRoutable to ona ponosi odpowiedzialność za obsługę requestu HTTP i powinna zakończyć działanie aplikacji.

Routing to ostatni etap startu aplikacji więc później i tak już nic się za bardzo nie dzieje.

Jest oczywiście sprawa jakichś rzeczy które mogą być robione przed zakończeniem skryptu, ale wg. mnie jest to trochę ryzykowne (zawsze może wystąpić krytyczny błąd/wyjątek przerywający skrypt) a dwa założenie jest taki jak napisałem wyżej: klasa przechwytująca ma odpowiadać za to co się dalej dzieje.

Natomiast to wyjście przez exit() nie jest obowiązkowe to tylko zalecenie, jeżeli się tego nie zrobi to po prostu wykona się plik index.php.

Jest jeszcze kwestia startupu standalone/CLI - jak się prześledzi procedurę startu to widać, że z oczywistych względów wtedy żaden routing nie jest przeprowadzany.

Co do nowego wątku: pojawi się taki jak będzie jakaś kolejna wersja - ale to najwcześniej w przyszłym tygodniu bo szykuje coś większego :)Tomasz Zadora edytował(a) ten post dnia 06.06.12 o godzinie 11:46
Link do wypowiedziLink

konto usunięte

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Ok.

Wszystko się zrobiło, routing swoje zrobił i teraz wywoływana jest klasa X odpowiedzialna za obsługę żądania.

Wg mnie ów klasa powinna zwrócić odpowiedź (np. obiekt implementujący przykładowy ResponseInterface).

Odpowiedź może być dowolnego typu - np. nagłówki redirecta, nagłówki error 404/500 czy HTML.
Brak odpowiedzi z klasy = błąd.

Dalej - index otrzymuje ową odpowiedź i może coś z nią zrobić lub po prostu wypluć użytkownikowi.

Jakikolwiek die/exit wg mnie jest złem.
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Masz racje - taki exit w środku to trochę "zło" no albo co najmniej trochę nieeleganckie.

W sumie to nawet często niepotrzebne (ale czasem przydatne napisze niżej) bo jest zmienna "$appConfig->urlRouter->ruleFound" i jeżeli nie jest false to znaczy, że zasada została znaleziona, przykład z pliku index.php testowej aplikacji INOFaktura:



// Jeżeli dany URL nie pasuje do żadnej z zasad routingu...

if (!$appConfig->urlRouter->ruleFound)

{

    // Jeżeli dany URL nie jest wejściem "domyślnym" -> twarde przekierowanie na wejście domyślne

    if ($_SERVER['REQUEST_URI'] != '/')

    {

        \ino\core\Util::httpRedirect('/', true);

    }

    

    // Zleć przechwycenie requestu HTTP klasie strony głównej

    $page = new \inofaktura\page\Index;

    $page->httpRequest($app, false);

}

Wg mnie ów klasa powinna zwrócić odpowiedź (np. obiekt implementujący przykładowy
ResponseInterface).
Odpowiedź może być dowolnego typu - np. nagłówki redirecta, nagłówki error 404/500 czy HTML.
Brak odpowiedzi z klasy = błąd.

Tylko zastanawiam się po co (może znasz jakiś ważny/ciekawy powód - napisz), bo ta znaleziona klasa pasująca do zasady routingu ma właśnie spełniać zasadę takiego interfejsu - i nie wiem po co dublować tą funkcjonalność: jedna klasa do znalezienia zasady i zwrócenie kolejnej klasy do obsługi wywołania....

Znaleziona klasa jest jakby zastępstwem typowego skryptu PHP do którego bezpośrednio odwołuje się przez URL.

I są jednak wyjątki gdzie exit wewnątrz może się przydać: w przypadku np. przekierowania, jeżeli ta znaleziona klasa implementująca interfejs \ino\core\URLRoutable wykona redirect (wygodnie przy użyciu \ino\core\Util::httpRedirect(...)) to później dobrze jest jednak wykonać exit aby upewnić się, że nic nie zostanie już wyrzucone na zewnątrz.

Natomiast sam index.php, nie powinien specjalnie niczego zawierać - chciałbym jak najwięcej oprzeć o klasy. Przykład kodu z góry to jedynie obsługa sytuacji nie znalezienia żadnej zasady i w tym momencie przekierowania na stronę główną, ale równie dobrze można dać tutaj nagłówek 404 lub przekierować do strony która ma informować że "strony nie znaleziono".Tomasz Zadora edytował(a) ten post dnia 06.06.12 o godzinie 18:02
Link do wypowiedziLink

konto usunięte

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Dublować nic nie dublujesz - wydzielasz odpowiedzialność obiektów.

Znaleziona klasa ma wygenerować odpowiedź a nie być odpowiedzią.
Jaka będzie odpowiedź - zależy od logiki w klasie (czy gdzie tam logika mieszka).

System nie jest zainteresowany nagłówkami odpowiedzi ani jej contentem.
Interesuje go tylko otrzymanie takowej z wywoływanego kontrolera.

Wydzielając odpowiedź jako osobną klasę unikniesz powstawania mega-obiektów. Odpowiedź jest ładnie wydzielona i można ją rozwijać niezależnie od pozostałych elementów.
Dobry interfejs odpowiedzi (i/lub klasa abstrakcyjna) pozwolą na przygotowanie dedykowanych rodzajów odpowiedzi.

Przykładowo - nic nie stoi na przeszkodzie by przygotować sobie:
- ResponseRedirect - której podajesz adres na jaki ma być przekierowanie a obiekt sam wybierze sposób przekierowania (nagłowki czy js),
- ResponseFile - która nie tylko prześle odpowiednie nagłówki ale i pozwoli na zarządzanie prędkością transferu, wymusi download itd.



public function downloadFile() {

    $File = new File($path);



    $Response = new ResponseFile($File);

    $Response

        ->limitTransfer(32)

        ->forceDownload(true);

    return $Response;

}


Czyż to nie jest śliczne i czytelne?

A w indexie robisz tylko wielki try { ... } catch(Exception $e) { echo new Response500('Mega fail!'); }

PS.
Wykonanie exit()/die() wg mnie jest rozwiązaniem tymczasowym i sporym problemem.
Co w sytuacji gdy coś po wygenerowani odpowiedzi ma się jeszcze dziać?
Coś poza kontrolerem? (kompresja, cacheowanie).Michał Wachowski edytował(a) ten post dnia 06.06.12 o godzinie 18:22
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Michał Wachowski:
Dublować nic nie dublujesz - wydzielasz odpowiedzialność obiektów.

Znaleziona klasa ma wygenerować odpowiedź a nie być odpowiedzią.
Jaka będzie odpowiedź - zależy od logiki w klasie (czy gdzie tam logika mieszka).

Tutaj piszesz o generowaniu odpowiedzi....
System nie jest zainteresowany nagłówkami odpowiedzi ani jej contentem.
Interesuje go tylko otrzymanie takowej z wywoływanego kontrolera.

...a tutaj o tym, że system nie jest zainteresowany odpowiedzią... nie wiem - ale to jest chyba trochę sprzeczność?

Teraz dokładnie tak to działa, że aplikacja zrzuca odpowiedzialność do znalezionej klasy i nie in teresuje jej co się dalej dzieje: czy np odpowiedzialna klasa zrobi sobie redirect, wyrzuci obrazek zamiast HTML albo zainicjuje ściąganie pliku.

Wydzielając odpowiedź jako osobną klasę unikniesz powstawania mega-obiektów. Odpowiedź jest ładnie wydzielona i można ją

Obecne rozwiązanie tego nie wymusza, niżej piszesz o różnych rodzajach odp. etc.

Można tego typu obiekty przygotować jako część FW (w pakiecie core albo html w zależności co to robi) i później z nich korzystać wewnątrz klas które przechwyciły wywołanie HTTP dla danego URL/URI. Przykładem takiej klasy jest \ino\core\Util gdzie mamy metodę httpRedirect.

PS.
Wykonanie exit()/die() wg mnie jest rozwiązaniem tymczasowym i sporym problemem.
Co w sytuacji gdy coś po wygenerowani odpowiedzi ma się jeszcze dziać?
Coś poza kontrolerem? (kompresja, cacheowanie).

Tego typu sprawy raczej nie są po tylko przed - kwestia nagłówków HTTP albo pobierania jakichś danych z memcached etc. :) Tak jak wcześniej napisałem - zamysł jest taki, żeby po znalezieniu klasy przechwytującej, z poziomu aplikacji generalnie nic już nie robić. To znaleziona klasa będąca częścią jakiegoś modułu najlepiej wie co ma się dalej stać.

Doceniam to, że chce Ci się pisać i dyskutować, ale jednak zostanę przy tej koncepcji która jest aktualnie.

Być może później jak FW się rozbuduje i sama aplikacja testowa i aplikacja generatora aplikacji będą w pełni funkcjonalne, zobaczysz, że to nie jest takie złe :)Tomasz Zadora edytował(a) ten post dnia 06.06.12 o godzinie 19:06
Link do wypowiedziLink
Tomasz Zadora

Tomasz Zadora programuję

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Może jeszcze tak: jeżeli w trakcie prac okaże się, że to jest złe rozwiązanie to je zmienię.... to jest dopiero początek/wersja alpha więc nic jeszcze nie jest ostatecznie ustalone.
Link do wypowiedziLink

konto usunięte

Temat: Dostępna wersja 0.0.3 - manager połączeń do baz danych

Inaczej.

System jest zainteresowany odpowiedzią - jako obiektem. A nie jego zawartością.
Nagłówki odpowiedzi powinny być wysyłane w momencie wysyłania odpowiedzi do użytkownika - w ostatnim momencie.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Pierwsza wersja 0.0.1 i str...




Wyślij zaproszenie do
Anuluj