[Symfony]Twig czy PHP Opcje

[viking]

Dla mnie ideałem od lat jest PHPTAL i nie wyobrażam sobie pracy na zwykłym kodzie PHP w widoku, a szablony typu Twig wcale się nie różnią w składni od gołego PHP. Jeszcze robią problemy kiedy trzeba sobie dodatkowo oprogramować np. wyświetlanie formularza z jakiegoś systemu. Ten przykład który podał !*! jest fajny do czasu gdy na wszystkich danych trzeba robić htmlentities().

[Pyton_000]

PHPTal nie wygląda na taki superaśny. Wrzucanie pierdyliard atrybutów do znacznikow strasznie zaciemnia obraz szablonu.

Twig, Smarty, PHP czy inne twory... Każdy używa czego chce i w czym mu wygodnie. Ja wiem że do Smarty nie wrócę nigdy, Twig ew. php i starczy.

[viking]

Ale w gratisie dostajesz wyjątek przy źle zamkniętych znacznikach (super ważna dla mnie kwestia dzięki którym nie ma źle zamkniętego kodu) i autoescape dla wszystkich danych. Zresztą PHPowa wersja i tak jest mocno okrojona o funkcje w stosunku do Pythonowego.

Dla mnie przykładowo:

[HTML] pobierz, plaintext 
<div i18n:translate="test">?</div>
<ul tal:repeat="row rows">
  <li tal:content="row/id">domyślne dane, pojawią się przy braku contentu</li>
</ul>
[HTML] pobierz, plaintext 

Jest super czytelne, umożliwia dodatkowo testowe ostylowanie albo pracę na JS.

A już z Twiga:

[HTML] pobierz, plaintext 
<ul>
    {% for user in users %}
        <li>{{ user.username|e }}</li>
    {% endfor %}
[HTML] pobierz, plaintext 

To zwykła sieczka i równie dobrze można gołe PHP używać. Szansa że się pomylisz w kodzie jest jeszcze większa.

Ten post edytował viking 4.07.2016, 14:37:59

[event15]

Z chęcią, już nieco spokojniej odpowiadam.

Większość aplikacji, jakie piszę jest w metodyce DDD. Kod jest dzielony na 4 główne warstwy. W rzeczywistości każda z tych warstw jest ODDZIELNYM projektem i służy do zgoła innych rzeczy.

Górną warstwą jest Prezentacja. Jest to czysty HTML+CSS + JavaScript w dowolnej formie. Ajax, Angular, React, cokolwiek co obsługuje komunikację po API REST.

Poniżej jest warstwa Aplikacji, która najczęściej wykorzystuje mikroframework, w moim przypadku najczęściej jest to Slim. Nie mam w nim żadnej logiki aplikacji. Odbieram requesty z prezentacji wysyłam je do niższych warstw i wysyłam response. Ten projekt można prowadzić zupełnie równolegle do wszystkich innych, tak samo jak projekt prezentacji.

Poniżej jest warstwa modelu dziedziny - nie ma tutaj zapytań do baz danych, nie ma też obsługi requestów z prezentacji. To tuaj dzieje się wszystko, co decyduje o działaniu aplikacji w zakresie wiedzy.

Infrastruktura to ostatnia warstwa, w której zapewnia się repozytoria i ich obsługę oraz serwisy, które wykorzystuje model dziedziny, czasami aplikacja.

W takim podziale warstw nie ma mowy o mieszaniu kodu dwóch języków. Dla mnie jest to naturalne podejście. Dzięki temu zespół grafików i front-endowców jest w 100% niezależny od zespołu backendowców - może mockować zasoby tak, aby później spokojnie podłączyć już istniejący, gdy będzie gotowy.

Tak samo zespół projektujący API może sobie zaprojektować całą aplikację niespecjalnie przejmując się warstwą prezentacji, czy domeny, bo aplikacja nie posiada przecież najmniejszej wiedzy o domenie i nie potrzebuje żadnej wiedzy o prezentacji.

Infrastruktura również nie wymusza na nas w takim podejściu wyboru bazy danych - storage może być wszystkim. Inmemory, postgres, mysql - można zaimplementować różne bazy do odczytu i zapisu.

[nospor]

No i super. Czyli wszystko jasne. Przyszedles na forum by sie pochwalic ze uzywasz Angular a kazdy kto nie uzywa to jest be. Ok, dziekujemy, przyjelismy, mozesz teraz isc na inne forum i tam tez sie pochwalic (IMG:style_emoticons/default/smile.gif)

[event15]

Przyszedles na forum by sie pochwalic ze uzywasz Angular a kazdy kto nie uzywa to jest be. Ok, dziekujemy, przyjelismy, mozesz teraz isc na inne forum i tam tez sie pochwalic

Nie złapałeś.
Nawet nie wiem czy zrozumiałeś w ogóle, co napisałem. Przetraw sobie jeszcze raz. Napisałem, że rozdzielenie warstwy prezentacji jest kluczowe. To czy jest to framework jsowy, czy jest to GUI desktopowe nie powinno być przedmiotem dyskusji. Aplikacja powinna być napisana tak, aby ani jeden, ani drugi nie miał problemu wdrożyć swój projekt.

[nospor]

Ok, to rodziel mi warstwe prezentacji w standardowym modelu gdzie nie masz angulara ani innych tego typu zabawek. Chetnie poslucham.

[Pyton_000]

@event15 ale co ma do tematu to w jaki sposób pracujesz? Tu się rozchodzi o Twig czy PHP jako narzędzie do budowania widoków.

Oba się nadają, obu się używa.

[Turson]

@event15, a w aplikacji nie-RESTowej w MVC jak będziesz drukował dane?
Tak można iść karcić Javowców za JSP, bo mieszają Javę z HTML. Litości

[event15]

Ok, to rodziel mi warstwe prezentacji w standardowym modelu gdzie nie masz angulara ani innych tego typu zabawek. Chetnie poslucham.

Oczywiście Twig.

@event15 ale co ma do tematu to w jaki sposób pracujesz? Tu się rozchodzi o Twig czy PHP jako narzędzie do budowania widoków.

Oba się nadają, obu się używa.

Twig IMO jest rozwiązaniem lepszym. Nadaje abstrakcję w kontrolerze na dane wysyłane do widoku. Jego pobranie to jedna komenda w composerze, użycie to kilka kliknięć. Stosując IDE, które wspiera budowanie widoków za pomocą wtyczki do Twiga sprawia, że jest to naturalny wybór.

@event15, a w aplikacji nie-RESTowej w MVC jak będziesz drukował dane?
Tak można iść karcić Javowców za JSP, bo mieszają Javę z HTML. Litości

Jeżeli już mam pisać nie-RESTową aplikację to oczywiście moim wyborem jest Twig.

[com]

Ale twig i wszystkie tego typu to itak html w php, tylko dodajesz dodatkowa nad nim abstrakcje wiec na jedno wychodzi. I to, że robisz DDD jakie to ma znaczenie? Też robie i co z tego. Można używać, ale nie trzeba tak samo jak DDD można zrobić z fw, a nie trzeba, czy nawet z ORMem.

Turson DDD to wcale nie musi być REST, a MVC to już trochę przeżytek, tym bardziej że na HTTP, to się go kaleczy.

[LowiczakPL]

W przypadku PHP nie ma mowy o "kompilacji".

... i tu się mylisz PHP można kompilować!

[com]

@up to bardziej sztuka dla sztuki (IMG:style_emoticons/default/wink.gif)

[destroyerr]

Tylko, że źródłowa wypowiedź dotyczyła kompilacji szablonów, tylko nasz narwany kolega źle doczytał i stąd pojawił się problem.