Migracja Twig v2 do v3

Migruje Twig wersje 2 do wersji 3. Jedna ze zmian pomiedzy tymi zmianami to to, ze nie mozna miec if warunku w jednej lini z for petla.

Wersja 2:

<ul>
{% for user in users if (user.dob > '2000-01-01') %}
	
	<li>{{ user.name }}</li>
	
{% endfor %}
</ul>

Wersja 3:

<ul>
{% for user in users %}
	{% if (user.dob > '2000-01-01') %}
	<li>{{ user.name }}</li>
    {% endif %}
{% endfor %}
</ul>

W jednym pliku moge miec kilka takich petli, one sa zagniezdzone itd. Jakis pomysl jak moge taka migracje wykonac przez skrypt etc? Mam jakies 800 plikow do migracji nie chce tego recznie robic.

Czemu w szablonie filtrujesz po dacie? ... jeśli users to dane z bazy to profiltrowane już z bazy danych powinny być zwrócone do szablonu.

@szok ma rację. Lepiej będzie jak wywalisz wszelkie IF'y, a do widoku przekażesz konkretne dane np. pogrupowane wg przedziału czasowego.

Zgadzam sie w 100%. To jest jakas tam logika. Powina zostac przeniesionwa do PHP. Niestety w tym wypadku musi tak zostac i mam sporo miejsc, gdzie taka for if jest uzyty. Musze znalezc jakas paczke czy napisac swoj skrypt, zeby takie elementy migrowac do Twig v3.

Znalazlem kilka composer package, ktore np wykrywaja code standards, ale nic co mozna bylo by uzyc do przeprowadzenia migracji. Nie wydaje mi sie, zeby napisanie takiego skyptu bylo banalne.

szok napisał(a):

Jeśli logiki nie możemy zmienić, ale szablon już tak, to napisz sobie filtr któr pofiltruje CI userów i zmodyfikuj samego for'a

Toz to bardzo dobry pomysl. Dzieki.

Nie wiem jednak czy to bedzie takie proste. Niektore for petle maja if and and po 2 albo i 3 warunki.

Kilka warunkow jeszcze idzie ogarnac. Ale jest duzo rzeczy w tych ifach. Np user.name|default("no name") == 'no name'. Tego juz tak latwo nie idzie przerobic. I ciekaw jestem ile takich rzeczy jeszcze bedzie. Nie jestem tak w stanie sprawdzic kazdego templata.

Spytam z ciekawości. Czy migracja na nowszą wersję jest absolutną koniecznością?

Tak, jest konieczna. Nie mam innej opcji, dlaczego pytasz?

Twig w wersji 2 w grudni 2023 bedzie porzucona. Nikt nie bedzie juz dodawal zmian ani naprawial obecnych bledow.

poniatowski napisał(a):

Tak, jest konieczna. Nie mam innej opcji, dlaczego pytasz?

Napisałem dlaczego pytam - z ciekawości.

Czy zastanawiałeś się nad opcją dodania własnej klasy, która przenosi daną funkcjonalność z v2 do v3 jako rozszerzenie? Wtedy jedyne co musiałbyś zrobić to szybka zamiana (podmiana z pomocą reguł IDE) for na np. forV2 (to taka robocza nazwa). Rozwiązanie siekierą rąbane i wymagające pewnych przemyśleń, ale wg. jest to jedna z szybszych opcji.

ccwrc napisał(a):

poniatowski napisał(a):

Tak, jest konieczna. Nie mam innej opcji, dlaczego pytasz?

Napisałem dlaczego pytam - z ciekawości.

Czy zastanawiałeś się nad opcją dodania własnej klasy, która przenosi daną funkcjonalność z v2 do v3 jako rozszerzenie? Wtedy jedyne co musiałbyś zrobić to szybka zamiana (podmiana z pomocą reguł IDE) for na np. forV2 (to taka robocza nazwa). Rozwiązanie siekierą rąbane i wymagające pewnych przemyśleń, ale wg. jest to jedna z szybszych opcji.

W sumie to tez moze byc bardzo dobra opcja. Zaraz poczytam jak taka klase napisac i podpiac pod Twig. Widze, ze to bedzie Twig class extension. Moze to i nie jest zle. Niestety te Twig templates sa zapisane w bazie danych. User je pisze i dlatego nie ma dostepu do PHP.

W sumie to moze jest bardziej cos w rodzaju Twig tag a nie extension.

Chwila, chwila, to będzie jednokrotna migracja (nigdy wiecej nie zajdzie potrzeba migracji 800 templatek z twiga2 do twiga3), dlatego najpierw oszacowałby dane wejściowe.

Masz 800 plików do sprawdzenia, odpal szukanie tekstu {% if ew. {% for
Sprawdz najpierw przy ilu wystepuje ta wadliwa konstrukcja i mając wyniki - podejmij decyzje czy warto to automatyzować.

Ja dałbym sobie górny limit 50~100 plików - i przeleciał to ręcznie.
Jeśli taką ręczną migrację będziesz musiał wykonać wiele razy, to wtedy dopiero bym się zastanawiał nad automatyzacją. Z drugiej strony - migracja z automatu też może Ci stworzyć problemy, bo np detekcja może coś pominąć lub źle naprawić.

Napisz ile dokładnie masz tych wadliwych warunków/pętli.

Wszystkich plikow Twig mam okolo 8000. Pliki ktore maja to {% for if %} konstrukcje to rowno 1300k. Wszystkie pliki sa w bazie danych. To bedzie jednokrotna migracja. Recznie troche ciezko. Na razie zrzucilem wszsytkie 1,3k plikow do CSV i przegladam i fakt co rozne rzeczy. Tzn na razie znalazlem 4 i wszystkie 4 ogarnalem w 50-60 linjak kodu w PHP. Ale rozwazam kazda opcje.

Testuje teraz opcje z zamiana if na | filter(). Przyznam, ze przy uzywaniu wyrazen regularnych jest to dosc skomplikowany process. W ty warunkch moze byc doslownie wszystko, bardzo ciezko wstrzelic sie w dokladne wyrazenie reqularne.

W sumie migracja przy uzyciu forV2 tez wcale nie jest prosta. Bo jak znalezc wszsytkie for if w ponad 8000 plikow i wiedziec, gdzie zastapic ten kod, a gdzie nie? Ciekawy pomysl, ale tez wydaje sie mega ciezki.

Mimo wszystko musi istniec jakis sposob na ta migracje. Przeciez ludzie tez musieli przejsc taka migracje.

poniatowski napisał(a):

W sumie migracja przy uzyciu forV2 tez wcale nie jest prosta. Bo jak znalezc wszsytkie for if w ponad 8000 plikow i wiedziec, gdzie zastapic ten kod, a gdzie nie? Ciekawy pomysl, ale tez wydaje sie mega ciezki.

Mimo wszystko musi istniec jakis sposob na ta migracje. Przeciez ludzie tez musieli przejsc taka migracje.

No nie. Wręcz przeciwnie. Nie musisz wyszukiwać żadnych forif. Wystarczy zastąpić wszystkie 'for'. Skoro i tak będą działać tak samo. A nowe będziesz już pisać po nowemu. Może czasem zastąpisz jakiś forV2 nowym 'for' jak Ci przyjdzie ochota. Albo i nie, wolna wola ;)

ccwrc napisał(a):

poniatowski napisał(a):

W sumie migracja przy uzyciu forV2 tez wcale nie jest prosta. Bo jak znalezc wszsytkie for if w ponad 8000 plikow i wiedziec, gdzie zastapic ten kod, a gdzie nie? Ciekawy pomysl, ale tez wydaje sie mega ciezki.

Mimo wszystko musi istniec jakis sposob na ta migracje. Przeciez ludzie tez musieli przejsc taka migracje.

No nie. Wręcz przeciwnie. Nie musisz wyszukiwać żadnych forif. Wystarczy zastąpić wszystkie 'for'. Skoro i tak będą działać tak samo. A nowe będziesz już pisać po nowemu. Może czasem zastąpisz jakiś forV2 nowym 'for' jak Ci przyjdzie ochota. Albo i nie, wolna wola ;)

Ok, teraz rozumiem Cie. To ma sens. Postaram sie moze isc ta droga. Moze uda mi sie jakos skopiowac Twig klasy z ta for if logika.

@ccwrc Ok, przekopiwanie tych klas z Twig v2 to mega ciezka praca. Generalnie tam jest Node i Token klasy. To sa glowne, ale one uzywaja sporo innych klas. Teraz to wszystko pokopiwac i posprawdzac jak to dziala to bedzie pewnie mega duzo czasu.

Teraz pisac swoj Twig tag pod for it to jest jak wymyslanie kola na nowo. Wydaje mi sie, ze te podejscie jest dosc ciezkie do osiagniecia.

Można wiedzieć dlaczego te templatki macie w bazie, a nie w plikach?

W sumie to teraz mysle, zeby usunac te templates z bazy danych i poprzenosic na dysk. Wie ktos moze gdzie je przetrzymywac? Kumpel mi mowi, ze CDN, ale mi totalnie CDN nie pasuje, ale sam nie wiem, moze sie myle?

No nie CDN... Przecież PHP musi to przetworzyć. Masz tam w projekcie jakiś folder typu View. Tylko jak masz to zrobione w ten sposób to bym tego już nie ruszał. Samo przepisanie jakichś includów zajmie Ci mnóstwo czasu z dopasowaniem ścieżek i wszystkiego a realnie pewnie nie uzyskasz jakiegoś efektu typu przyspieszenie apliakacji.