DbM Framework - Autorska aplikacja frameworka opartego na wzorcu MVC Opcje

[Salvation]

public function queryExecute(string $query, ?array $params = [], bool $reference = false): bool;

A po co Ci wartości domyślne w Interface? Rzadko się takie coś robi, bo powinno się świadomie wypełnić parametr.

kiedy zmienię na bool $reference bez wartości w Visualu pojawia się chmurka: Expected 3 arguments, Found 2.

Aplikacja działa ok, ale Visual coś pokazuje nie ok?

Wartość domyśla pozwala pominąć argument przy wywołaniu metody. Dostajesz informację z IDE, że źle wywołujesz metodę.

Czyli w Twoim przypadku poprawne będzie skorzystanie z takich wywołań:

[PHP] pobierz, plaintext 
queryExecute('query');
queryExecute('query', null);
queryExecute('query', null, true);
queryExecute(query: 'query', reference: true); // dla PHP 8
[PHP] pobierz, plaintext 

A to czy "aplikacja działa ok", bez podania ostatniego parametru w metodzie, powinno wyjść przy testach, które pewnie napisałeś?

Ten post edytował Salvation 12.02.2024, 09:25:01

[Malinaa]

1. Czyli w Twoim przypadku poprawne będzie skorzystanie z takich wywołań:
2. A to czy "aplikacja działa ok", bez podania ostatniego parametru w metodzie, powinno wyjść przy testach, które pewnie napisałeś?

1. Jasne, tylko po co w każdym wywołaniu metody pisać (dodawać false/true)
$this->database->queryExecute($query, [':limit' => $limit], false); ?
jeśli tak jest krócej i prościej $this->database->queryExecute($query, [':limit' => $limit]);

kiedy mimo, że rzadko się tak robi w interfejsie można dać: public function queryExecute(string $query, ?array $params = [], bool $reference = false): bool;
nie public function queryExecute(string $query, ?array $params = [], bool $reference): bool; i jest ok.

2. Dla testów dodałem ExampleTest.php wywołałem "composer test", aby sprawdzić czy działają i jest OK (1 test, 1 assertion), czyli testować też można.
Natomiast jeżeli chcesz mnie nauczyć pisania testów to możemy zrobić kolejny test np. DatabaseTest.php, ale to nie będzie takie proste.
No kto pisze testy ale pewnie, że byłoby warto coś przetestować.

Może jakieś pomysły jak powinien wyglądać idealny seo friendly link dla przykładowego z końcówką .html
/art_5_present-eusmod-grvd-lbero-luctus-ns-fermentum-nec.html - z podkreślnikiem nie za bardzo wygląda, a ze slasem jest kłopotliwy ?
Wydawało się, że przecinek będzie zgodny z seo podobnie jak kropka, ale jak się okazuje, przecinek nie, więc jak by to zrobić..
Robiłem kiedyś split testy i wyszło, że największa klikalność była dla linków z końcówką typu domain.com/key-word-etc.html
a 10 % więcej potencjalnych klientów, może oznaczać że zamiast zarabiać 100 mamy 110, 1000 -> 1100, 10 000 -> 11 000 zł, więc spora różnica na plusie.
Przydałaby się konstrukcja linków, w które klikamy bez opamiętania i nie trzeba używać słów typu: best-sex-in-life.html

Ten post edytował Malinaa 12.02.2024, 22:01:38

[Salvation]

1. Jasne, tylko po co w każdym wywołaniu metody pisać (dodawać false/true)
$this->database->queryExecute($query, [':limit' => $limit], false); ?
jeśli tak jest krócej i prościej $this->database->queryExecute($query, [':limit' => $limit]);

kiedy mimo, że rzadko się tak robi w interfejsie można dać: public function queryExecute(string $query, ?array $params = [], bool $reference = false): bool;
nie public function queryExecute(string $query, ?array $params = [], bool $reference): bool; i jest ok.

Przyjęło się - i takie też są zalecenia - że ergumenty metody z domyślną wartością lądują na końcu. A nic nie staje na przeszkodzie, żeby Interface wyglądał po bożemu:

[PHP] pobierz, plaintext 
public function queryExecute(string $query, ?array $params, bool $reference): bool;
[PHP] pobierz, plaintext 

A klasa, która go implementuje wyglądała tak:

[PHP] pobierz, plaintext 
public function queryExecute(string $query, ?array $params = null, bool $reference = false): bool;
[PHP] pobierz, plaintext 

Demo: https://3v4l.org/00aAp

2. Dla testów dodałem ExampleTest.php wywołałem "composer test", aby sprawdzić czy działają i jest OK (1 test, 1 assertion), czyli testować też można.
Natomiast jeżeli chcesz mnie nauczyć pisania testów to możemy zrobić kolejny test np. DatabaseTest.php, ale to nie będzie takie proste.
No kto pisze testy ;) ale pewnie, że byłoby warto coś przetestować.

Kto pisze testy? Przedewszystkim twórcy frameworków. Polecam podejście TDD. Znacznie mniej kodu się produkuje i - prawie - od razu wchodzisz w SOLIDy kod.

Ten post edytował Salvation 13.02.2024, 11:35:17

[Malinaa]

A nic nie staje na przeszkodzie, żeby Interface wyglądał po bożemu:

No, o tym pisałem wcześniej, że staje na przeszkodzie, bo Visual wyświetla chmurkę, że brakuje argumentu,
dlatego dałem tak samo jak w klasie bool $reference = false.

Jeżeli w interfejsie dam bool $reference aplikacja działa, teoretycznie jest ok, ale Visual pokazuje nie ok.

Kiedy napiszę w klasie i interfejsie bool $reference = false nie ma problemu, wszystko na zielono Ok.
Chyba, że jest coś jeszcze, może jakoś powtarzają się metody, wczytywane są 2x te same?
Raczej nie chciałbym w każdej metodzie dodawać false: $this->database->queryExecute($query, [':limit' => $limit], false);
ale dlaczego kiedy zmienię interfejs na bez false: public function queryExecute(string $query, ?array $params = [], bool $reference): bool;
w Visualu świeci na czerwono?

Testy, to może przy weekendzie zobaczę, czy coś da się zrobić,
chyba, że byłbyś tak dobry i napisał przykład dla Database.php?
Byłoby prościej próbować kolejne.

Adres SEO Friendly - coś nie widać pomysłów?
Teoretycznie z tego co widzę można tworzyć linki z podkreśleniem, chociaż nie jest zalecane:
przykład: /art_5_present-eusmod-grvd-lbero-luctus-ns-fermentum-nec.html
trochę też tak sobie wygląda z tymi podkreśleniami, może jakiś inny znak (dozwolony w seo linku), alko ze slasem
/art/5/present-eusmod-grvd-lbero-luctus-ns-fermentum-nec.html fajnie wygląda, tylko tutaj mam kłopot taki, ze przeglądarka traktuje ścieżkę jakby strona (statycznie) była w katalogu /art/5/
i wówczas trzeba przerabiać path np. przy wyświetlaniu obrazków na ../../images/ aby wejść do katalogu, podobnie dla ../../assets/ oraz podstron, itd...
Czy jest jakieś sprytniejszy sposób? Aby mieś 100% SEO i nie kombinować z path'em!

Ten post edytował Malinaa 13.02.2024, 22:38:14

[viking]

Zaczynając od php 8.0 wszystkie parametry required muszą być zdefiniowane pierwsze.
A nawet jak zdefiniujesz public string $a, public ?string $b = null, public string $c to automatem php przerobi $b na wymagany.

[Salvation]

dlaczego kiedy zmienię interfejs na bez false: public function queryExecute(string $query, ?array $params = [], bool $reference): bool;
w Visualu świeci na czerwono?

Przyjęło się - i takie też są zalecenia - że argumenty metody z domyślną wartością lądują na końcu.

Jak zrobisz to w ten sposób co proponujesz, to `$params` będzie required (choć kod na to nie wskazuje), więc jak podasz tylko dwa argumenty w wywołaniu, to otrzymasz błąd w IDE. Ale widzę, że już Viking mnie uprzedził :D
Mam wrażenie też, że nie do końca ogarniasz OOP. Dlaczego uparłeś się mieć wartości domyślne w Interface?

[Malinaa]

Zaczynając od php 8.0 wszystkie parametry required muszą być zdefiniowane pierwsze.

Nie inaczej required są pierwsze.

W przykładzie ostanie false mogło być mylące, dokładnie całość w interfejsie chciałem dać tak:

public function queryExecute(string $query, array $params, bool $reference): bool;

gdzie tylko $query jest required (jeden pierwszy argument)

ale wówczas np. w BlogModel.php Visual pokazuje chmurkę, że nie widzi wszystkich argumentów

dlaczego wyskakuje chmurka - ponieważ w BlogModel.php jest construct z DatabaseInterface i po zmianie na siłę trzeba wrzucać w metodę false
a chyba nie po to był pisany interfejs, aby w konstruktor wstrzykiwać klasę Database, albo w metodę nie wymagane false/true? Jak to napisał wcześniej Salvation.

Jak zrobisz to w ten sposób co proponujesz...

Zmieniłem na sposób, który zaproponowałeś, bo "tak się przyjęło"... i elegancko. Aplikacja działa; kłopot, że w Visualu świeci na czerwono.

Kod jest dostępny. Jak nie ma kodu, to podaj kod, kiedy jest kod to nie można do niego zajrzeć?
Coś tu nie rozumiem.

Może lepiej podam kod krok po kroku, bo chyba można ten kod ze sobą "pogodzić".

Klasa Database.php

Kod

public function queryExecute(string $query, ?array $params = [], bool $reference = false): bool
{
...
}

Interfejs DatabaseInterface.php był tak samo jak w klasie, ale chcemy, aby był tak:

Kod

public function queryExecute(string $query, array $params, bool $reference): bool;
{
...
}

i ok, zmieniam na powyższy - aplikacja działa, teoretycznie wszystko ok, ale przechodzę do
modeli, np.: BlogModel.php -> Visual wyświetla chmurkę -> brakuje argumentów w metodzie queryExecute()

I tutaj jest problem, no ale w konstruktorze miałem: public function __construct(DatabaseInterface $database) -> brak zgodności więc Visual świeci na czerwono,
no dobrze, ale generalnie nie ma problemu zmieniam konstruktor na:

Kod

public function __construct(Database $database)
{
...
}

i wszystko działa, w Visualu też wszystko jest na zielono, ok.

Przy czym w kontrolerach np. BlogController.php w konstruktor wstrzykiwany jest interfejs

Kod

public function __construct(DatabaseInterface $database)
{
...
}

Pytanie, czy tak jest dobrze, że mając interfejs w konstruktor modeli wstrzykuję klasę Database nie interfejs DatabaseInterface,
ewentualnie jak prawidłowo pogodzić te klasy i metody z klasą Database i interfejsem DatabaseInterface?
Tutaj coś nie wiem, które rozwiązanie jest dobre.
Czy w modelach może tu być w konstruktorze Database zamiast DatabaseInterface, bo ta zamiana rozwiązuje problem wyświetlania przez Visual chmurki z info o brakujących argumentach metody.

Chciałbym ogarnąć jeszcze miejsca w kodzie, gdzie zostało dodane TODO!
I trafiam na taką funkcje, która to była jako tymczasowa dla szablonów i jest powiązana z Database, które jak widać z powyższego jeszcze szwankuje.

plik template.php

Kod

// TODO! Temporary function
use Dbm\Classes\Database;

function temp_htmlUser($sessionUserId, $module = null, $tempPath = null): string
{
    $database = new Database(); // TODO!
    ...
}

Jak to zrobić, aby było ok dla szablonów, w których chciałbym mieć tylko funkcje do obsługi szablonu, np. path() itp. gdzie temp_htmlUser() wymaga połączenia z bazą danych?

Ten post edytował Malinaa 17.02.2024, 00:10:17

[nospor]

Jak to zrobić, aby było ok dla szablonów, w których chciałbym mieć tylko funkcje do obsługi szablonu, np. path() itp. gdzie temp_htmlUser() wymaga połączenia z bazą danych?

No toz dopiero co przerabialismy DI. Skoro jakas twoja tam funkcja potrzebuje obietku DB to masz go pokolei przekazywac az dojdzie do tej funkcji. Zasada sie nie zmienia.

To po pierwsze.
A po drugie funkcja template nie powinna nic wiedziec o bazie. Ona tylko powinna dostac dane niezbedne do wygnerowania szablonu

[Malinaa]

Tak przerabialiśmy i wiem jak mógłbym to zrobić dla klasy, ale tu są tylko funkcje.

Jest plik index.php w folderze public, tu wczytuje:
require(BASE_DIRECTORY . 'application' . DS . 'template.php');
w pliku template.php dodaje funkcje dla szablonów
i idąc po kolei, pierwszy szablon base.phtml w folderze templates wstawiam jakie potrzebuje funkcje,
pierwsza z góry <?= trans('lang') ?> itd. i mogłoby tak być, aż dojdziemy do
templates/_include/navigation.phtml linia 52 funkcja echo temp_htmlUser() (gdzie temp oznaczyłem jako temporary -> TODO! nie template)
w tej funkcji docelowo htmlUser() potrzebne jest pobranie danych z bazy danych i tutaj mój system szablonów w wersji pierwszej już wymięka.

Czy można ten system zostawić na funkcjach i pobrać obiekt DB dla funkcji, czy tutaj już muszę przerobić cały system na klasę? Plik template.php z funkcjami na Class -> Template.php
Kłopot przy przerabianiu jest taki, że chyba będę musiał poprawić też wszystkie szablony, ponieważ wówczas w wymienionym
base.phtml już nie będę mógł zrobić tak <?= trans('lang') ?> jak bym chciał, a raczej <?= $object->trans('lang') ?>

I tak zaglądam jak to zrobić, aby było dobrze. Prawdopodobnie to co mam jeszcze w pliku public/index.php jako funkcje

### FUNCTIONS - application starting, template engine, etc.
require(BASE_DIRECTORY . 'application' . DS . 'start.php');
// Default template engine, you can change it to any other one
require(BASE_DIRECTORY . 'application' . DS . 'template.php');

i tak będzie trzeba zmienić na klasy, ponieważ z tymi funkcjami to za dobrze nigdy nie będzie?
Tylko to oznacza konieczność przerobienia też wszystkich szablonów .phtml, wywołania funkcji <?= trans('lang') ?> i każdej innej,
no chyba, że może zostać <?= trans('lang') ?> itd. oraz htmlUser() <- DB ?

Tak na to jeszcze raz zajrzałem i jak mam zaś po kolei przerabiać te szablony to mi ręce opadły, dobrze byłoby wiedzieć jak zrobić teki system szablonów, co by teraz zaś nie wałkować szablon po szablonie...

[nospor]

Jak ty sobei lubisz komplikowac prace
I co z tego ze tu masz funkcje a tam miales klasy? Przeciez tam w klasach i tak przekazywales DB do funkcji, ktora sie nazywala __construct, ale to nadal byla funkcja.

Skoro teraz masz:
function temp_htmlUser($sessionUserId, $module = null, $tempPath = null): string

a potem wywolanie
echo temp_htmlUser($this->getSession('dbmUserId'));

To czemu nie zrobisz analogicznie z db?


function temp_htmlUser($sessionUserId, DatabaseInterfacce $db, $module = null, $tempPath = null): string

a potem wywolanie
echo temp_htmlUser($this->getSession('dbmUserId'), $this-getDatabase());

Skoro w kontrolerze masz metode getSession to przeciez mozesz tam dodac metode tez getDatabase(). Przeciez kontroler ma juz obiekt DB wiec metoda getDatabase musi go tylko zwrocic. I juz

[Malinaa]

Tak jakoś mam, że i tu gdzie można by przyjąć, że nie ma już problemu, pojawiły się znaki zapytania komplikujące dokończenie dzieła

Bo wiesz wcześniej to miałem te szablony z końcówką typu base.html.php i funkcje (trans(), path(), htmlUser(), dalej $this->getSession() itp.) w tych plikach wydawały mi się ok,
ale zmieniłem rozszerzenie szablonów na końcówkę base.phtml i tak się zawiesiłem na tym, czy te funkcje w tych plikach są w ogóle ok?!

Dzięki za info. Jeżeli funkcje są tu ok, to problem z głowy,
no może jeszcze tylko z takim drobiazgiem co zrobić
i "sprzątam" pozostałe znaki zapytania oznaczone w kodzie TODO!

Kod

use Dbm\Interfaces\DatabaseInterface;

function htmlUser(DatabaseInterface $database, int $sessionUserId, string $module = null): string
{
...
}

Jeśli w funkcji dam DatabaseInterface $database to muszę dodać use Dbm\Interfaces\DatabaseInterface co nie wygląda rewelacyjnie w tym pliku template.php.

[nospor]

Jeśli w funkcji dam DatabaseInterface $database to muszę dodać use Dbm\Interfaces\DatabaseInterface co nie wygląda rewelacyjnie w tym pliku template.php.

Skoro uzywasz DB w pliku template.php to nie masz wyjscia.

[Malinaa]

Używam, choć przyszedł mi na myśl inny system szablonów. Jakiś gotowiec! Ciekawe, który by się tu nadawał najbardziej?

1.W tym pliku może pominę typowanie argumentów dla funkcji
function htmlUser($database, $sessionUserId, $module = null): string {}
wówczas nie trzeba dodawać 'use' co wygląda tu lepiej.

Kod prawie posprzątany, zostało zapytanie:

2. Czy można tu w zapytaniu użyć "SELECT roles FROM dbm_user WHERE id = ?"
czy bezpieczniej będzie "SELECT roles FROM dbm_user WHERE id = :id".
Jak to jest z :id lub znakiem zapytania w zapytaniu, czy tak samo bezpieczne?

Kod

public function userPermissions(int $id): ?string
    {
        $database = $this->database;
        $query = "SELECT roles FROM dbm_user WHERE id = ?"; // TODO! Jak to jest z :id lub znakiem zapytania, czy tak samo jest bezpieczne?
        ...
    }

3. Problem powstały przy napisaniu interfejsów. Jakby to zapytać możliwie najkrócej, które rozwiązanie wybrać.

Czy w

Kod

class BlogModel
{
    private $database;

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

można wstrzyknąć: public function __construct(Database $database) klasę nie interfejs i będzie Ok?

Po tej zmianie można tez zmienić metody w interfejsie na pożądane, czyli bez wartości
public function queryExecute(string $query, ?array $param, bool $reference): bool;
zamiast
public function queryExecute(string $query, ?array $params = [], bool $reference = false): bool;
i jest czysto, bez błędów.
Natomiast jeżeli ma być DatabaseInterface $database w modelach to interfejsy zostają z wartościami,
bo nie wiem jak inaczej całość pogodzić.

Z tego co przejrzałem kod są to 3 ostatki do poprawienia oznaczone TODO i powinno być OK.
Bynajmniej na ten czas, no chyba, że przyjdzie pomysł na dalszą rozbudowę

Ten post edytował Malinaa 19.02.2024, 21:03:57

[nospor]

ad2) bez znaczenia


Na pozostale dwa juz nie wiem czy mam sile odpowiadac.... Nie poto wprowadzilismy interfejsy zebys je teraz radosnie usuwal bo wizualnie ci sie nie podoba w templates masz use DB. No kurde.... juz ci dawno pisalem ze template nie powinien nic weidziec o DB, tylko dostac dane niezbedne do wygenerowania widoku i wtedy nie masz w ogole DB tam. No ale jak sie nie slucha to sie ma jak ma

Zas co do chmurek w twoim edytorze to tez nie ogarniam. Zmien edytor. Mi phpstorm nie pokazuje zadnuch chmurek czy bledow.

Nie ogarniam tez czemu tak na ciebie siedli za te wartosci defaultowe w interfejsie. A juz w ogole nie rozumiem czemu kaza ci default kasowac w interfejs a zostawic w klasie. No to juz w ooggole nieporozumienie, bo jak kiedys dojdzie inne klasa ktora implementuje interfejs ale tym razem bez defaultow tak mowi interfejs, to kod ci sie wywali bo jakies kawalki kodu beda jechac po starej klasie gdzie byly default. I zonk.

[Malinaa]

2. Ok i super.

1. Ach, dasz radę. Ten template jest light weight

Nie jest tak jak piszesz, albo coś nie kumam.
Zgodnie z tym co pisałem w template.php nie ma use DB nie ma też już use Interface,
usunąłem tylko typowanie z funkcji
function htmlUser($database, $sessionUserId, $module = null): string {}
nigdzie nie było powiedziane, że każda funkcja musi mieć typowanie, więc jest oki.

Wywołanie funkcji jest m.in. w navigation.phtml
echo htmlUser($this->getDatabase(), $this->getSession(''));
gdzie $this->getDatabase() jest w BaseController.php wstrzykiwane z interfejsu DatabaseInterface $database nie klasy DB (Database).

Chyba, że chcesz, aby zamiast $database, dać jakąś tablice z danymi usera: id, login, avatar itd...
No to akurat w przypadku tej funkcji "globalnej" (i używanej w różnych miejscach) jest mocno kłopotliwe, jeszcze nie wiem, ale raczej musiałby tu dodać jakiś nowy mechanizm,
coś jak w Symfony -> TwigExtension, albo coś za dużo sobie wyobrażam i można prościej.

Ale po co Extension itd. kiedy $this->getDatabase() idzie z interfejsu i załatwia sprawę?!

3. Czemu miałbym usuwać wartości defaultowe w interfejsie, które są w klasie - była informacja, że tak się przyjęło (no i mus, nie ma rady).
Może tak, program działa bez tych wartości, ale nawet Visual podpowiada, że po usunięciu domyślnych wartości coś nie do końca zagrało z interfejsem i klasą.
A piszesz, że lepiej jest dokładnie napisać interfejs zgodny z klasą też w defaultowych wartościach, co wbrew temu co się przyjęło będzie pomocne przed zonk'iem.
Pomijając Visual Twoja informacja utwierdza mnie w przerkonaniu, że te defaultowe wartości powinny tam być, wiec zostawiam interfejs tak jak utworzyłem.

Znalazłem jeszcze jedno TODO

Kod

private function paramType($value)
    {
        switch (true) {
            case is_null($value):
                return PDO::PARAM_NULL;
                break;
            case is_int($value):
                return PDO::PARAM_INT;
                break;
            case is_bool($value):
                return PDO::PARAM_BOOL;
                break;
            default:
                return PDO::PARAM_STR;
        }
    }

Jak zapisać typowanie dla tej metody, spróbowałem z mixed, ale wówczas się sypie
private function paramType(mixed $value): mixed ?

Ten post edytował Malinaa 20.02.2024, 22:40:34

[nospor]

Nie jest tak jak piszesz, albo coś nie kumam.
Zgodnie z tym co pisałem w template.php nie ma use DB nie ma też już use Interface,

No nie ma bo usunales. O tym wlasnie mowie...nie po to wprowadzalismy interfejsy bys teraz radosnie je usuwal bo ci sie nie podoba use w twoim pliku.

nigdzie nie było powiedziane, że każda funkcja musi mieć typowanie, więc jest oki.

X postow wczesniej plakales ze musi to byc zrobione perfekcyjnie,teraz cos usuwac bo cie sie wizualnie nie podoba use.

Ja mam dosc. Milego

[Malinaa]

Tak chcę, aby było bezbłędnie. Czy będzie perfekcyjnie jeśli dodam w pliku template.php use Dbm\Interfaces\DatabaseInterface? Myślę, że nie, jeżeli usunę też nie, więc po co się nad tym rozwodzić.
Pewnie, aby było dobrze i tak będę musiał dopisać klasę Template (zamiast tych funkcji), albo użyć gotowego silnika szablonów.
Wówczas rzeczywiście oddzielę ten widok tak jak wcześniej pisałeś i template nie będzie nic wiedzieć o DB.

Przy tym template trochę mnie odcięło (coś tam usunąłem, dodałem, już nie pamiętam), ale przypakowałem na siłce i mocy przybyło, jak nie siłka to Red Bull doda Ci skrzydeł.

P.S. Podaj adres podeślę Ci śniadanie. Jeżeli nie masz siły spróbuj coś innego, dobrego i poczujesz się o niebo lepiej
Dzięki za pomoc. Pozdrawiam serdecznie

Dopisuje klasę TemplateEngine, wówczas można przyzwoicie dodać use Dbm\Interfaces\DatabaseInterface; kod umieściłem pod linkiem:
https://github.com/artimman/dbmframework/tr...nts/Template_v1
w pliku public/index.php odznaczam linie
//require(BASE_DIRECTORY . 'application' . DS . 'template.php');
przechodzę do BaseController w application/classes gdzie dodałem extends TemplateEngine

Sprawdzam jak działa templates/base.phtml i yield'y, include, extends jest ok, pozostało {{ $this->trans('lang') }}
Czy ktoś ma może pomysł jak sprawić, aby w szablonach działało {{ trans('lang') }} i/lub podobnie?
Zostało dopisanie mechanizmu, którym można wywoływać metody klasy jak funkcje w szablonach bez $this (->nazwaMetody).
Mam nadzieję, że wówczas i szablony będą zakodowane w porządku.

Ten post edytował Malinaa 24.02.2024, 23:19:59

[nospor]

Sprawdzam jak działa templates/base.phtml i yield'y, include, extends jest ok, pozostało {{ $this->trans('lang') }}
Czy ktoś ma może pomysł jak sprawić, aby w szablonach działało {{ trans('lang') }} i/lub podobnie?

Jak zwykle nie kumam
Skoro ten kod

private function compileEchos(string $code): string
{
return preg_replace('~\{{\s*(.+?)\s*\}}~is', '<?php echo $1 ?>', $code);
}

ci obsluguje {{$this->metoda}}
to wywal $this i dodaj do echo

private function compileEchos(string $code): string
{
return preg_replace('~\{{\s*(.+?)\s*\}}~is', '<?php echo $this->$1 ?>', $code);
}


ps: dalej tworzysz potworki ala:

if (..) {
...
return ...
} else {
return ...
}

Nauki ciagle ida w las

[Malinaa]

Gadanie, kumasz. Chociaż szczęście każdy rozumie na swój sposób

return preg_replace('~\{{\s*(.+?)\s*\}}~is', '<?php echo $1 ?>', $code);

działa prawidłowo i jest potrzebne np. w pętli
{% foreach($colors as $color): %}
<li>{{ $color }}</li> <- jest elegancko
{% endforeach; %}
więc może nie ruszajmy tego co funkcjonuje dobrze.

na podanym kodzie
return preg_replace('~\{{\s*(.+?)\s*\}}~is', '<?php echo $this->$1 ?>', $code);
wyskakuje błąd

dopisałem taki kod

Kod

private function extensionPath(string $code): string
    {
        return preg_replace('~\{@\s*path(.+?)\s*\@}~is', '<?php echo $this->path($1) ?>', $code);
    }

    private function extensionTrans(string $code): string
    {
        return preg_replace('~\{@\s*trans/((.+?),(.+?),(.+?)/)\s*\@}~is', '<?php echo $this->trans($1,$2,$3) ?>', $code);
    }

w szablonie
{@ path('test/') @}
{@ trans('lang', [], []) @}
dla path() wygląda, że idzie, ale dalej przy funkcjach z wieloma argumentami trans() to nie wiem

poza tym trzeba te wszystkie metody wklepywać m.in. to compileCode(), co nie jest fantastycznym "mechanizmem",
ale nie widzę tu prostego rozwiązania i preg_replace() nie wystarczy, musiałby chyba tworzyć jakąś machine do obsługi takich custom funkcji?

No nie wygląda ten silnik szablonów rewelacyjnie z $this wszędzie, szablon jest zapchany $this'em,
ale jeżeli nie przeszkadza, nie obciąża systemu to może tak zostawić?


Powtórki jak się domyślam w class Database

Pytałem o function paramType($value), brak informacji na temat typowania dla takiej metody, gdzie return jest "mixed" - PHP 7, w 8 może wystarczyło by dać tylko mixed, chociaż z mixed to i tak nie wiadomo - skłoniło mnie do if and else, aby nie zostawiać metody bez typowania w klasie, gdzie każda metoda ma typowanie. Nauka nie idzie w las, takie pragmatyczne rozwiązanie. Poza tym to nie samolot, śmiga chociaż nie ma "skrzydeł".

[nospor]

wyskakuje błąd

Juz ci kiedys pisalem co masz zrobic gdy wyskakuje blad. I znowu, gadam w proznie

Powtórki jak się domyślam w class Database

No wlasnie zle sie domyslasz. Nie mam czasu ogladac za kazdym razem calego twojego kodu. Skoro mowiles o szablonach to i ja spojrzalem tylko na szablony i tam wlasnie takie potworki byly