DbM Framework - Autorska aplikacja frameworka opartego na wzorcu MVC Opcje

[Malinaa]

A ja jakos w robocie dosc czesto musze do tematu podchodzic pragmatycznie...

Z filozoficznego punktu widzenia:
" Wyobraź sobie że życie polega na żonglowaniu pięcioma piłkami. Ich nazwy to praca, rodzina, zdrowie, przyjaciele i prawość. Wszystko udaje ci się utrzymywać w powietrzu. Ale pewnego dnia wreszcie do ciebie dociera, że praca jest gumową piłką. Jeżeli ją upuścisz, odbije się i wróci. Pozostałe cztery piłki - rodzina, zdrowie, przyjaciele, prawość - to szklane kule. Jeśli się którąś upuści, może się obić, wyszczerbić lub nawet roztrzaskać.


No, ale wracamy na polską ziemię 10x szybciej, jeśli środowisko tego wymaga itp. itd. Jasne.

Ten post edytował Malinaa 11.01.2024, 12:44:53

[viking]

1. Przy instalacji należy zmienić nazwę na config.php - nie wiem dlaczego to jest potwór?
2. O ile rozumiem chcesz zamienić config.php.dist na .env
Podałeś jednak od razu link na jakąś petardę, może jakiś przykład dla zielonych (nie git gotowiec, a czysty kod), bo mam mieszane uczucia, nie wiem co chcesz zrobić.
3. Tak racja (musiałem podejść do tematu pragmatycznie), z katalogiem vendor rzecz zrobiła się bardziej złożona, mogę próbować wytłumaczyć jeśli trzeba, ale przeczytaj README.md co powinno rozjaśnić kłopot. którym teoretycznie można by się nie przejmować... ale odbiorca (klient) jest bardzo istotny.

Też mi się trochę nie podoba rozwiązanie z kontrolerami i metodami (do poprawki), ale nie mam coś pomysłu na lepsze.
Jak masz pomysł na poukładanie kodu w stabilną całość - podaj koniecznie rozwiązanie problemu, a będę mówił Ci Królu przez cały tydzień.

Większość osób które chciałyby wrzucić taki config na swojego gita pewnie puści to jak leci zapisując w nim wszystkie hasła do systemu. .env jest uniwersalne, powinno być wykluczone z commita. Są też różne środowiska. Np osoba pracująca z kontenerami może chcieć zaczytać env do kontenera podczas uruchamiania swojego stacka. Poza tym nie lubię jak wszędzie pałętają się jakieś stałe.
Przykładów jak używać masz pełno, np https://github.com/vlucas/phpdotenv#immutab...y-customization

Dlaczego mam czytać readme żeby dowiedzieć się coś o vendor? Tego folderu nie ma prawa być. Są różne wersje php, OS, różne zależności. Tych plików nie wrzuca się ot tak.

Poprawny kod powinien być zgodny z https://www.php-fig.org/psr/psr-15/

Nie rozumiem nigdy tego pisania własnego FW przez początkujących. Nie, nie jest to dobra metoda bo nabierasz złych nawyków, nie masz kogoś, kto nad tobą stoi i wytyka cały czas błędy. Poużywaj trochę mainstreamowe fwameworki, zobacz jak w nich robi się pewne rzeczy. A jak już będziesz na poziomie pro wtedy można coś myśleć (chociaż i tak nie ma to sensu).

[Malinaa]

Większość osób które chciałyby...

Aby większość osób nie wrzuciła config z hasłami na gita dodany został plik config.php.dist natomiast config.php jest .gitignore, więc nie wiem dlaczego - potwór.
Na pewno lepiej będzie przerobić na .env - dzięki za info.

Nie chcesz przeczytać, ok. Przecież nie spodziewałem się, że chcesz, więc tłumaczenie mamy z głowy.

Co tu rozumieć, potrzebny jest kod w czystym PHP do prostych aplikacji, czyli wzorzec MVC (frameworkowy) do takich systemów jest lux, nadaje się do systemu CMS.
Poziom pro, ponownie nie wiem co masz na myśli, czy też co chcesz zrobić, albo czego nie chce Ci się robić, poza tym co lub kogo lubisz, może nie lubisz... "chociaż i tak nie ma to sensu",
więc abyśmy nie pisali bez sensu, może zapytam krótko: co Twoim zdaniem ma sens?

Ten post edytował Malinaa 11.01.2024, 13:25:36

[viking]

Przeczytać przeczytałem ale napisałem dlaczego to jest bez sensu. Vendor i zależności tworzone są w zależności od OS i wersji php. To że sobie coś wrzucisz u kogoś innego nie oznacza z góry że to zadziała. Sam php mailer ma np zależności

"ext-ctype": "*","ext-filter": "*","ext-hash": "*"

U kogoś nie będzie i już nie działa. Nie dowiesz się tego bez instalacji, sypnie błędem w którymś momencie wykonywania kodu.

Wzorzec MVC jest standardem i owszem wszędzie się nada. Ale jego implementacja robi różnicę. Jest od groma różnych frameworków. Przykładowo https://www.slimframework.com/ wchodzę na stronę i widząc go pierwszy raz wiem jak dodać kolejną podstronę. A to dlatego że przestrzega reguł (psr). Wiem że ma testy i dużo osób od lat go poprawia. U Ciebie nie dość że trzeba się przekopać przez kod który tylko Ty rozumiesz to nie ma żadnej gwarancji że on działa poprawnie.

Laravel 11 też dąży do tego aby na start było jak najmniej, do tego ma gigantyczną społeczność i pełną integrację z różnymi projektami zewnętrznymi (alpine, tailwind itp). Znów ogromna ilość testów, osób które nad nim pracują i fajne rozwiązania których nigdy nie wdrożysz u siebie (nawet to ograniczenie php 7.3 gdzie mamy już 8.3).

To tylko dwa przykłady. I żeby nie było, dobrze że piszesz coś tylko IMO najpierw popracuj z innymi FW, zobacz jak coś jest zrobione i na pewno dojdziesz do wniosku że to co napisałeś jest do zaorania (też dobrze).

[Malinaa]

Rozumiem, mimo to chciałbym opracować mechanizm (w wersji stabilnej) oparty na wzorcu MVC (chyba już z czystej ciekawości), ale dzięki za wytykanie błędów.
IMO? Wyobraźnia jest nieograniczona, reszta to taki chwyt marketingowy, w którym nowości zawsze wygrywają (to kwestia czasu kiedy inne FW też zostaną zaorane)

Ten post edytował Malinaa 11.01.2024, 14:06:07

[viking]

To na początek ja bym spróbował ogarnąć temat z którym masz tutaj taki problem czyli rozwiązanie z singletonem. Spróbuj tak przepisać kod żeby zaimplementować jakiś gotowy system dependency injection np https://php-di.org/ (propozycja losowa). I poczytaj chociaż dokumentację innych fw żeby zobaczyć co można robić i w jaki sposób.

[Malinaa]

Wydawało mi się, że takie powszechne rozwiązanie jak framework oparty na wzorcu MVC na moje potrzeby (wspomniany CMS i proste aplikacje) będzie najlepszym rozwiązaniem, a teraz to już nie wiem,
tzn. wiem, że nic innowacyjnego nie wymyślam i pewnie nic innowacyjnego tu już nie wymyślę, jeżeli masz jakiś genialny pomysły to fajnie byłoby zastosować, nie wiem co mam powiedzieć -> łap okazje -> będzie można się czymś wyróżnić.

Problematyczny temat to już próbowałem ogarnąć, nie był to początek, bardziej wygląda na koniec, ale tak jak będzie jeszcze na to czas, spróbuję z dependency injection,
wszak chciałbym wiedzieć jak to się dzieje, że taka "żarówka" świeci i ją zbudować, chociaż większości osób wystarcza on/off i też są happy.

P.S. Dokumentacje w j. ang. można czytać, jeśli ma być ze zrozumieniem to na 50% zobaczę co można robić i w jaki sposób, czyli trafię bankowo w najciekawsze kawałki.

[com]

Malinaa musisz sobie postawić zasadnicze pytanie poco to tworzysz? Kiedy będziesz szukał potencjalnej pracy kiedyś zakładam na pewno to nastąpi zapytają Cie jakie frameworki znasz, nie powiesz im przecież, że tylko "DbM Framework" bo nikt tego poza Tobą nie zna. Dziś startując na rynku pracy większość ofert wymaga od pracownika znajomości jednego z fw: Symfony, Laravel itp. Jakaś bazę wiedzy już zebrałeś i większość z nas pisała kiedyś własny framework albo swojego cmsa, bo kiedyś to było modne, czasy się zmieniły, dziś nie ma to już sensu, a tworzenie takiego czegoś często uczy Cie od razu z automatu złych praktyk, bo nie masz żadnego mentora który wytyka błędy, nospor i viking dotknęli tylko szczytu góry lodowej przeglądając to w mniej czy bardziej dokładny sposób, ale dziś to nie wystarczy. Podstawami do nauki PHP od zawsze była dokumentacja, ale oprócz tego przez lata wypracowane zostały pewne standardy oznaczone jako PSR https://www.php-fig.org/psr/ i jeśli tworzysz oprogramowanie i się do nich nie stosujesz to od początku popełniasz błąd, który w próżniejszym czasie będzie Cie kosztował nauka złych nawyków których nie będziesz się w łatwy sposób w stanie pozbyć. Polecałbym poczytać np coś takiego https://phptherightway.com/ i zamiast przepalać własne godziny na tworzenie własnego frameworka bez wiedzy i doświadczenia, skupić się na próbie zrozumienia jak działa jeden z powszechnych i dostępnych fw na rynku. A jeśli masz ambicja do tego żeby stworzyć własnego CMSa jako taki pet project dla samorozwoju, to właśnie oprzyj go na takim Symfony czy Laravel, dzięki temu uda Ci się zrozumieć jak to działa i nie będziesz uczył się złych praktyk, a poznasz wiele dobrych praktyk, szczególnie jeśli chodzi o Symfony to nie ma tam antywzorców itp Troche gorzej jest w Laravel, oczywiście da się je wyeliminować ale to trzeba być już na wyższym poziomie wtajemniczenia, niemniej jednak nawet użycie Laravel będzie miało równie wymierne korzyści(po prostu Laravel posiada/posiadał takie anty wzorce jak Active Record(można go zastąpić przez jakiś Data Mapper np Doctrine) oraz nadmiernie wykorzystywał wzorzec Fasady, ale pozostałe kwestie są tam na najwyższym poziomie). Do nauki polecam https://symfonycasts.com/ lub https://laracasts.com/. Na przyszłość jak już tworzysz własny Fw to jest coś takiego jak https://symfony.com/doc/current/create_framework/index.html i należało by się zastosować do tych zasad opisanych tam żeby to miało jakikolwiek sens

Kiedy już opanujesz podstawy wybranego przez siebie fw, bez problemu jeśli trafisz na jakiś problem przy tworzeniu tego własnego CMSa znajdziesz tutaj na forum i na innych masę osób które znają ten fw na wylot i beda w stanie Ci pomoc, nakierować itp, nikt tego nie napisze za Ciebie ale to będzie dla Ciebie merytorycznie znacznie korzystniejsze niż ocenianie wielu godzin twojej pracy nad "DbM Framework", bo jakby się defakto nad tym mocno zastanowić i zastosować do PSR i innych dobrych praktyk to ten kod cały by trzeba napisać na nowo Nie chcę Cie zrazić i nie odbierz tego jako hejt, to normalne kiedy osoba która się uczy zabiera się za tworzenie FW/CMS, a na jej kod spojrzy ktoś z dużo większym stażem, tez kiedyś zaczynałem i popełniłem taki sam projekt, zarówno robiłem własnego CMSa jak i fw w swojej karierze(ale dopiero pierwszy komercyjny projekt zrobiony w Symfony, nawet po latach jak do niego zajrzałem, to mimo iż dziś posiadam o wiele więcej doświadczenia niż wtedy, ale budowałem go zgodnie z dokumentacja na SynfonyCast wtedy defa kto nazywało się jeszcze KnpUniversity, to jak patrze na ten kod po latach to on nadal nie wymaga zmian, no możne poza tym że dziś bym dodał typy zmiennych wszędzie gdzie się tylko da, za to jak zaglądam do swojego cmsa/fw to widzę jak mało jeszcze wtedy znałem te technologie), ale to było ponad 15 lat temu, dziś bym się tego nie podjął a od początku po przestudiowaniu dokumentacji dla PHP zacząłbym eksperymenty pewnie z Symfony Tobie również życzę by "DbM Framework" pozostało historia do której wrócisz za 10 lat i zobaczysz jaki przeskok w swojej wiedzy za ten czas zyskałeś i żeby pierwszy twój projekt w fw jaki sobie wybierzesz nadal za te 10 lat cieszył oko, a nawet jakby było tam cos do poprawy to żebyś mimo wszytko dostrzegał to jaka przepaść będzie dzielić cms na fw "DbM Framework" a na ogólnodostępnym fw, ale to myśle już teraz zauważysz jeśli spróbujesz pójść w te stronę Bo jeszcze przed Tobą poznanie czym jest DDD i tworzenie kody który będzie Framework-agnostic, bo fw to jest taki Ninja Master toolbox(scyzoryk, pila, klucze w jednym) i jest on w miarę uniwersalny ale on powinien być tylko jednym z narzędzi ułatwiającym prace tak jak IDE jest dla pisania kodu i powinien pomagać a nie nas ograniczać ale to gdzieś tam daleko w przyszłości zrozumiesz o czym mówię

PS na koniec dodam jeszcze że w protokole HTTP nie da odzwierciedlić wzorca MVC, tutaj tworzona jest tylko jedna z wariacji bazująca na tej idei, ale nigdy nie będzie to pełnoprawny MVC, wiec w sumie powoli przestaje się tak nawet nazywać te fw(Jeśli przeczytasz o Symfony na nie polskiej stronie Wikipiedii, bo tam nikt tego nie redaguje to nie ma już nic wzmianki o MVC)

Ten post edytował com 18.01.2024, 15:01:47

[Malinaa]

Spróbuj tak przepisać kod żeby zaimplementować jakiś gotowy system dependency injection

viking piszę, że nie chcę żadnego gotowca, a na siłę podajesz gotowca za gotowcem.

Potrzebuję mechanizm, który działa bez Composera, Composer ma być opcjonalny, można użyć, ale nie ma takiej konieczności, aby uruchomić aplikacje typu CMS, albo coś prostszego ma wystarczyć wypełnienie formularza instalacyjnego z danymi typu login, hasło, serwer, baza danych -> klikamy Go i gotowe, aplikacja śmiga (bez żadnego composer install). W przypadku części kodu napisanej pod Landingpage obyłoby się też bez wypełniania formularza instalacji.
Co mi tu brakuje, aby poprawnie poukładać tych kilka plików w folderze library/dbmframework:
1. Wspomniane DI, które nie za bardzo wiem jak napisać dobrze w czystym kodzie (bez gotowca) tak, aby dało się używać w całej aplikacji.
2. Problem z kontrolerami i modelami, przydałoby się więcej abstrakcji i wstrzykiwanie, ale to jest powiązane z DI.

Wspomniałeś o katalogu vendor, że nie może w nim być nawet autoloadingu, nie ma go być w ogóle - kod poprawiony vendor usunięty, aplikacja działa bez vendora i Composera i już jest tak jak chciałem, a jak zechcesz użyć Composera to też wystarczy, że wykonasz composer install i będzie chodzić z Composerem.
Usunięty katalog vendor i var dodane do gitignore (program utworzy sobie var'a a composer vendor).

config.php - nie jest błędem, więc na ten czas podarujmy sobie .env, oki.

PSR 15 i Interfejsy - Królu naucz pisać porządne interfejsy, bo z interfejsami to mam zielono.
Czy takie tam Psr\Http\Server\RequestHandlerInterface można zastosować bez Composera? Jak to, kiedy musi być bezbłędnie

SlimFramework jest Ok, bliski temu co przyszło mi na myśl, ale Composer jest tu niezbędny podobnie jak w każdym innym FW co nie spełnia mini wymogu - Mechanizm (DbM Framework) ma działać na czystym kodzie bez pakietów, bibliotek, Composera itd.
Poza tym SlimFramework pisany i poprawiny jest od kilkunastu lat, ma swoją społeczność itd. przy kodzie DbM FW posiedziałem w zeszłym roku przez jakiś miesiąc tworząc v1 i teraz drugie podejście i powstało v2 - no bez sensu byłoby zabierać się dzisiaj za kolejny framework i liczyć na oklaski, ale potrzebny jest wspomniany mechanizm na minimalistycznym, bezbłędnym kodzie.

Malinaa musisz sobie postawić zasadnicze pytanie poco to tworzysz?

Pan Bóg stworzył istotę dla hecy, z tyłu plecy, z przodu plecy. A jednak po niej przyszedł ten, który był zrodzony, a nie stworzony
Chcesz pomóc? Napisz jak mam zakodować DI i inne drobiazgi, o których pisałem wyżej.

Ten post edytował Malinaa 18.01.2024, 22:10:37

[Salvation]

(...) ma wystarczyć wypełnienie formularza instalacyjnego z danymi typu login, hasło, serwer, baza danych -> klikamy Go i gotowe, aplikacja śmiga (...)

No to wrzuć vendora do paczki instalacyjnej od razu. Tak robi wiele "gotowych" systemów. A composera i tak wdróż, bo niepotrzebnie wymyślasz koło na nowo.
Chyba, że chcesz się jedynie nauczyć tego co "pod maską", bo w przeciwnym razie ten autorski framework będzie tylko do szuflady.

Już znam firmy co wrzucają klientów na własny fw (swoją drogą, ciekawy model biznesowy), bo tworzenie go zajęło tyle, że jeszcze się nie spłacił.

[Tomplus]

Ja osobiście rozumiem dlaczego ktoś tworzy i stosuje własne FW. Mają kilka zalet:
- na początku są proste w obsłudze
- są lekkie
- uwzględniają specyfikę hostingu
- są szyte na miarę umiejętności twórcy.

Jednak problemy przychodzą gdy, projekt się rozrasta i różnych powiązań modułów jest coraz więcej. Zaczynają pojawiać się zbędne powtórzenia, blędy tam gdzie nie powinno ich być.

[Malinaa]

Mam chwilę, więc usiadłem do projektu. Dependency injection z tego co widzę tak szybko nie zrobię, właściwie to trzeba przerobić całość w katalogu /library/dbmframework/
https://github.com/artimman/dbmframework a następnie kontrolery itd.
a co gorsza nie mam pomysłu jak zrobić, aby było Git.

No to wrzuć vendora do paczki instalacyjnej od razu. Tak robi wiele "gotowych" systemów. A composera i tak wdróż, bo niepotrzebnie wymyślasz koło na nowo.
Chyba, że chcesz się jedynie nauczyć tego co "pod maską", bo w przeciwnym razie ten autorski framework będzie tylko do szuflady.
Już znam firmy co wrzucają klientów na własny fw (swoją drogą, ciekawy model biznesowy), bo tworzenie go zajęło tyle, że jeszcze się nie spłacił.

Z informacji ma być bez katalogu vendor!?
Zrobiłem tak, że w pliku index.php dodałem funkcje autoloadingWithWithoutComposer($pathAutoload); i rozpoznaje, czy został uruchomiony Compser, jeśli tak to autoloading leci z Composera, jeśli nie to dopisałem własny autoloadnig, któet wczytuje wszytsko co potrzeba bez Composera. Takie rozwiązanie nie jest chyba wymyślaniem koła od nowa? Jeżeli w tym rozwiązaniu coś nie gra, no to pytanie jak wrzycić vendora do paczki instalacyjnej, mając na względzie, ze pewnie ten vendor będzie generowany innaczej w zależości o wersji PHP.

Projekt ten ma charakter takiego "poligonu ćwiczebnego", nauczenia się tego co jest "pod maską", ale będzie super Git jeśli uda się wyciągnąć z niego coś więcej niż kod zaszufladkowany tym bardziej, że po prostu jest mi taki kod potrzebny, problem, aby napisać go bezbłędnie

Tak daleko nie patrzyłem, ale ciekawy model biznesowy.

Ja osobiście rozumiem dlaczego ktoś tworzy i stosuje własne FW.

Pocieszające słowa, bo już myślałem, że porywam się na coś co każdemu wydaje się być bez sensu i głupie, że aż głupio gadać.
Jeden poza oczywiście nosporem, który potrafi motywować (nie zniechęcać).

Usiadłem do tego DI, ale już przy pierwszym uruchomieniu PHP-CS-Fixer pojawił się kłopot z szablonami, doszedłem do wniosku, ze projekt prosi się, aby dla templates utworzyć osobny katalog, więc tak też zrobiłem.
Wydaje się, że teraz jest Git, chociaż zamiast MVC i katalogów w application/ Ciontroller, Model, View mam teraz Controller, Model i ../templates/ .

Tu pojawia się kolejne pytanie, np. w IndexController miałem linie
$this->view("blog/index.html.php", $data); gdzie template był w index.html.php - tak to jakoś wymyśliłem na początku, ale nie widziałem takich nazw plików
i tak teraz sobie przypomniałem, czy nie lepiej aby zamiast index.html.php był plik index.phtml i tak należałoby przerobić wszystkie pliki w katalogu templates?

Wracając do DI i więcej abstrakcji w projekcie.

Plik np. IndexController jak mam tutaj zrobić wstrzykiwanie przy konstruktorze i metodach:
public function __construct(DatabaseClass $database, TranslationClass $translation)
public function index(TranslationClass $translation, etc...)

Plik RoutClass:
linia 41: $controllerNamespace = 'App\\Controller\\' . $this->controller;
linia 42: $this->controller = new $controllerNamespace;

oraz model, plik FrameworkClass:
linia 76: return new $modelNamespace;

Jakiś pomysł jak poskładać to co jest "pod maską" w katalogu /library/dbmframework/ ?
Ponieważ z tego co widzę obecnie wyszedł dwusuw, a potrzebny jest czterosuw ekonomiczny 2.0 200KM

Ten post edytował Malinaa 27.01.2024, 21:11:28

[viking]

Kontroler to generalnie nie jest miejsce na wciskanie całej logiki i wszystkich zależności. Gdybyś użył jakiegoś kontenera (jak podałem przykładowy php-di) to mógłbyś wtedy wykorzystać https://www.php-fig.org/psr/psr-11/ i np w jakimś swoim service używać $container->get(MyClass::class) żeby wyciągnąć instancję klasy. Trzeba by poczytać dokumentację bo ma kilka ciekawych rzeczy.

[Malinaa]

jak podałem przykładowy php-di

Przeglądałem podane przykładowe PHP-DI, ale wymaga użycia Composera i wówczas pewnie można by zrobić coś na kształt Slim framework,
ale jak już pisałem powinno funkcjonować bez konieczności użycia Composera, który jest tu opcjonalny, jeśli projekt wymagałby większej rozbudowy itd.

Na potrzeby obecnego projektu "maluszka" mogłoby wystarczyć to co jest, ale potrzebuję zastosować w kodzie DI (wstrzykiwanie) tylko bez żadnych gotowców,
gdyż bez tego o ile dobrze widzę jakakolwiek nieco większa rozbudowa nie ma sensu, ponieważ idąc już parę kroków dalej koło się zamyka, czyli lipa.

Dla przykładu zamiast obecnych templetów, które z rozszerzenia nazwa_pilku.html.php raczej przerobię na nazwa_pliku.phtml mogę chcieć rozbudować projekt, o któregoś gotowca (twig templating component),
zastosować np. Slim\Views\Twig chyba można ? i już tutaj muszę mieć w kontrolerach wstrzykiwanie. Jednak należy mieć na względzie, że to tylko opcja (jeżeli zdecyduje się użyć Composera, domyślnie templates/ będą z rozszerzeniem .phtml).

P.S. Sorki, ale obecnie nie miałem kiedy do tego usiąść, może przy weekendzie coś wymyślę.

Ten post edytował Malinaa 2.02.2024, 23:24:53

[viking]

Musisz się w końcu zdecydować. Robisz to żeby się coś nauczyć i ewentualnie szukać potem pracy jako programista czy robisz coś dla siebie i nie ma znaczenia jak, byle jaki kod który jakoś działa. Nie oszukujmy się że ktoś ten "framework" prywatnie wykorzysta więc raczej chodzi o naukę. A z takim podejściem sam sobie kłody pod nogi rzucasz.

[Malinaa]

Musisz się w końcu zdecydować.

Jestem zdecydowany i nie interesuje mnie byle jakość. Tylko nie za bardzo rozumiem czy myślisz, że naprowadzasz mnie na właściwą drogę kiedy piszę któryś raz, że chcę jak najbardziej czysty PHP i HTML w templates, bez gotowców,
a opcjonalnie mieć możliwość użycia Composera i gotowych rozwiązań. Podałeś wcześniej "rozwiązania", które chyba nie rozwiązały żadnego opisanego problemu
i przy pierwszej lepszej okazji wytykasz swoje mądrości pisząc jakby to była jedyna dobra droga, oszukując jednocześnie na temat byle jakości, kiedy chyba nawet sam "czujesz", że nie po to tu jestem.

Pewnie jak zwykle i tak się zrozumiemy umiarkowanie, ale chciałbym zrobić to wstrzykiwanie np. w kontrolerach bez konieczności użycia Composera. Co w tym złego?
Napisałem to samo już któryś raz, ma się rozumieć nie da się bez Composera (plus PSR) itd. zrobić bezbłędnie, więc po temacie.

Z punktu widzenia rzeczy, o których się fizjologom nie śniło, tylko blondynom - jak to jest w WordPress CMS - użytkownik pobiera aplikacje, instaluje i gotowe, nie ma konieczności, ale zapewne można używać Composera?
Może przypasowałby tu silnik frameworka, a funkcjonalność CMS -> "Framework CMS", czy można jedno z drugim pogodzić, pewnie tak, ale wyjdzie "rakieta".

[viking]

Wstrzykiwanie zależności a menedżer (albo service locator w zależności od tego co chcemy użyć) to dwie różne rzeczy. Do samego di nie potrzebujesz composer.
Widok można sobie wstawić dowolny, jeśli będzie jeden standard to kod powinien implentowac jeden wspólny interfejs i wymiana to przełączenie w konfiguracji. To czy twój szablon będzie miał rozszerzenie phtml czy zupa to najmniejszy problem.
Ciężko się z tobą rozmawia, bo nie tylko ja zwracam uwagę na pewne rzeczy, które następnie ignorujesz, bo masz swoją lepszą wizję. Tylko niestety jesteś na bardzo początkującym poziomie i widać to po tych pomysłach. Skup się na tym żeby pisać dobry kod a nie archaizmy typu brak composer. Tak się pisało 15 lat temu. Tak, możesz się teraz na mnie obrazić ale mało mnie to interesuje. Cześć.

[Malinaa]

Kilka konkretnych informacji się pojawiło. Dzięki.

Na tym można by poprzestać, ale jak zwykle musiałeś pojechać z poziomem... No, jesteś Najlepszy.

P.S. Oj, Królu Złoty sądzisz, że z Tobą się lekko rozmawia, nie obrażajmy się,
ewentualnie jeśli kogoś szukasz, wybacz proszę nie jestem ideałem.

Composer jest zajebisty, więc nie obracaj kota ogonem, nigdzie nie pisałem że chcę bez Composera.
Wyobraź sobie wymóg jest taki, że musi działać też bez niego.

[nospor]

skoro tak bardzo nie chcesz uzywac DI co ci zaproponowano, to :

- modele niech nie dziedziczac po DatabaseClass tylko niech przyjmuja w konstuktorze obiekt DatabaseClass i go uzywaja
- obiekt DatabaseClass tworzysz raz w index.php i potem przekazujesz w konstruktorach dalej.
- np do FrameworkClass, ktore potem w metodzie model() nie przekazuje obiekt DatabaseClass do konkretnych modeli.

I tyle, zmian malo a masz pelne DI.

ps: i miejze litosc wywal te "Class" z nazw klas w koncu. To mialo sens 20 lat temu gdy klasy dopiero wchodzily a nie teraz gdy wszystko jest klasa

[Malinaa]

1. modele niech nie dziedziczac po DatabaseClass tylko niech przyjmuja w konstuktorze obiekt DatabaseClass i go uzywaja
2. obiekt DatabaseClass tworzysz raz w index.php i potem przekazujesz w konstruktorach dalej.
3. np do FrameworkClass, ktore potem w metodzie model() nie przekazuje obiekt DatabaseClass do konkretnych modeli.

Zacząłem od początku od pliku index.php tu nie spodobało mi się poprzednie:

### RENDER PAGE ###
use Dbm\Classes\RoutClass;
new RoutClass();

Sprawdziłem co tam kiedyś napisałem w wersji 1 i nie maiłem routes, tylko taką sprytna metodę.
Dopisuję routing, ale po drodze stwierdziłem, że całość jest do przerobienia: struktuira katalogów i po kolei, przy okazji zmieniłem te Class na bez Class, bo tak chciałeś (mi to nie przeszkadzało, wydawało się, że podobnie jak NameInterface tak też NameClass to nie problem, a chociaż od razu widać, że to np. nie AbstractClass, czy coś jeszcze innego mniejsza o to teraz jest bez i jest OK).

Teraz zamiast powyższego w pliku index.php mam
### ROUTER ###
$routes = require(BASE_DIRECTORY . 'application' . DS . 'routes.php');
$routes();
Pytanie, czy tak jest dobrze?

1. modele niech nie dziedziczac po DatabaseClass tylko niech przyjmuja w konstuktorze obiekt DatabaseClass i go uzywaja
Wcześniej bez zmiany na $routes nie można było nic do konstruktora w modelach wstrzyknąć po dodaniu kodu __construct() wysypywało się.
2. jak z pliku index.php przekazać Database w konstruktorach?
3. zamiast FrameworkClass jest AbstractController, - zmieniłem tu stary pomysł na modele bez możliwości używania konstruktora - teraz można wstrzykiwać w modelach.

Mamy plik index.php (w katalogu public) w przeglądarce otwieram stronę główną,
obsługuje ją klasa IndexController (src/Controller/) tu nadal coś jest nie tak, nie mogę wstrzyknąć do konstruktora

Kod

/*
     * TODO! public function __construct(Database $database, Translation $translation) // TODO! Wstrzykiwanie do konstruktora!?
     */
    public function __construct()
    {
        $database = new Database;

        $model = new BlogModel($database);
        $this->model = $model;

        $translation = new Translation();
        $this->translation = $translation;
    }

w powyższym konstruktorze jest model, no udało się tu poukładać kod i wstrzykuje

Plik BlogModel (src/Model)

Kod

public function __construct(Database $database)
    {
        $this->database = $database;
    }

Czy tak jest ok, bo coś nie czuje jak to jest z tym połączeniem, aby mieć jedno?

Pozostał przykładowy IndexController wstrzykiwanie do konstruktora, a do metod, czy też?
No i dalej abstract klasy, interfejsy, fabryki, I tyle, więcej nie pamiętam.

Zaproponowane DI będę chciał się zająć, ale w pierwszej kolejności chciałbym dobrze poskładać całość bez Composera i gotowców.

Ten post edytował Malinaa 5.02.2024, 23:09:33