Loading...

Във форума е въведено ограничение, което позволява на потребителите единствено да разглеждат публикуваните въпроси.

RoYaL avatar RoYaL Trainer 6849 Точки

PHP Web Development - Отговори на въпроси от sli.do

Здравейте,

Виждам, че има няколко въпроса във sli.do, бих ги отговорил и на лекцията, но някои от тях може да изисквам дискусия, а не съм сигурен колко от задалите ги са присъствени, за това ще дам отговори и във форума, в случай че някой иска да се включи

Малко се връщам назад ... може ли да обясниш както точно прави ::class и как можем да го заместим? Пр: \Core\MVC\MVCContextInterface::class

 

Псевдоконстантата class връща името на класа (пълното му име, включително и namespace) като стринг. Може да се замести с ръчно писане на стринга, но рискуваме при промяна на името на класа, да не променим стринга, докато така извиквайки го директно от класа трудно може да стане същия проблем. В тази статия има примерче и как се държи PHPStorm в двата сценария.

Как да добавим къстъм клас и action във fromBulder-a пробвах с $builder->setAttributes() и нестана

 

За да се сложи на самия <form> таг action се ползва $builder->setAction(); а за да се сложи class, id или някакъв друг атрибут става през HTML-a (Twig-a):  {{ form_start(form, {attr: {'class': 'my-form-class'}}) }}

Не разбрах защо се прави контролер, който не наследява предложения от Symfony. Бихте ли обяснили отново!

 

Истината е, че в 99% от случаите няма добра причина да се прави. Когато контролерът се изнесе като Service, в голяма част от случаите не може да наследява предложения от Symfony контролер. Понякога изнасяме контролер като Service когато се нуждае от това да му бъдат добавени (inject-нати) зависимости (dependency-та). Едното идва на цената на другото, аз лично предлагам да си наследявате стандартния Symfony контролер и когато дойде нуждата да се използва dependency injection-а на редица други обекти, то според ситуацията ще разберете трябва ли да спре да наследява държавния контролер или не.

Може ли в резюме да кажете отново как се завърта един цикъл от работата на един контролер в Symfony? ....  Как и къде се извиква Контролера? Как се вземат данните за модела и как се извиква Вю-то?

 

На този въпрос ще отговоря и на лекция нагледно, но с няколко думи тук - първо един полезен линк - https://symfony.com/doc/current/controller.html. Symfony сканира всички класове в Bundle-ите и търси за анотации @Route и евентуално @Method, над методите им. Ако присъстват такива, то за Symfony това са годни за извикване методи при определени събития. Като последните се контролират от това какво пише в @Route и @Method. В първото е URI шаблонът в адрес бара (пр. /users/register), а второто е HTTP метод (пр. POST, ако анотацията не е написана по подразбиране е GET). Та, ако настъпи събитието /uses/register и метод GET се извиква съответният метод, който има тези анотации. Той приема потребителските данни през URL-а, тъй като е GET. Т.е. ако шаблонът беше /users/{id} (т.е. /users/ и нещо след него), то методът щеше да приема като аргумент променливата $id. Тя щеше да се напълни с данните равни на тези в адрес бара, например ако потребителят беше извикал /users/4, променливата $id щеше да има стойност 4. Вю-то от своя страна го управлява контролера, той в края на изпълнението си трябва да върне някакъв HTTP Response, например redirect или View. Последното се рисува на екрана чрез функцията render().

Ако данните, които трябва да приеме един контролер са множество, то шансовете са, че искаме да вземем данни от формуляр чрез метод POST. Чрез специалните типове формуляри, които предоставя Symfony, можем да зададем бизнес правила на полетата в нашия формуляр и да кажем кой обект трябва да се напълни при валидно изпращане на формуляра в configureOptions() -> 'data_class'. Това означава, че трябва методът, който ще се извика при изпращане на формуляра да приема Request обект, с който формулярът ще взаимодейства (handle) за да напълни нашия data_class (иначе казано Binding model или какъв да е друг модел, например от базата данни).

В тази статия от cookbook-а на Symfony има стъпка по стъпка създаване на регистрационен формуляр - http://symfony.com/doc/current/doctrine/registration_form.html

Как в една конзола стартирахте едновременно и сървъра и doctrine? За да подкарам doctrine ми се налага да го пускам в друга конзола, така ли трябва?

 

Не съм. Или съм спирал сървъра с CTRL+C, писал съм doctrine команди и съм го пускал пак, или съм го правил от два отделни прозореца :)

За login ползваме ServiceController, а за Register - DefaultController. Защо различни?

 

ServiceController - не би трябвало да сме ползвали такова нещо. Но нямаме добра причина да ползваме два контролера. В повечето фреймуърци нещата свързани с оторизиране и други неща свързани със сигурност са изнесени в контролер наречен SecurityController, защото отговаря за сигурността. Затова и login е там. Докато регистрирането на потребител е просто INSERT операция на някакъв обект (в случая потребител - User), затова е и в контролерът, който отговаря за потребителите (UsersController).

 

Надявам се да съм отговорил. Ще си ги говорим нещата и утре на упражнението. Ако има нещо - не с колебайте да пишете в тази тема или да отворите нова :)

 

Поздрави,

Иван

Тагове:
1
PHP Web Development 06/12/2016 20:38:46
RoYaL avatar RoYaL Trainer 6849 Точки

Здравейте,

Малко насоки за защитите утре и на следващия ден :)

Тъй като имате ограничено време да защитавате ви предлагам следното нещо:

 

  1.  Намислете си какъв сценарий от проекта ще покажете
  2.  Подгответе си го разцъкан вече веднъж. Ако трябва регистрирайте потребители, създайте някакъв setup в играта
  3.  Като застанете отпред да защитавате - започнете с 30тина секунди контекст каква игра имате и какво се случва в нея и т.н. и дайте линк към GitHub.
  4.  Разкажете после през какъв сценарий ще ни прекарате за още 30тина сек, например "Ще регистрираме играч, ще влезем с друг играч и ще нападнем новорегистрирания......." и т.н.
  5.  Докато ни показвате сценария, пускайте от време на време IDE-то и показвайте части от кода на нещата, които показвате и смятате, че са интересни. Може предварително да си подготвите файловете, които ще покажете скролнати до фрагмента код, който ще покажете. Използвайте бялата тема на IDE-то и увеличете малко шрифта предварително.
  6.  В залата ползваме HDMI, ако се нуждаете от други adapter-и е хубаво да си носите. По принцип в сградата имаме, но има и други активности по това време и е възможно точно джаджата, която ви трябва да е заета.
  7.  Изтествайте си компютъра с HDMI или чрез adapter-а, вижте какви неща са нужни за да работи - резолюции, duplicate screen и други технически детайли. Идеята е да не се бавим с техническите детайли в часа на защитата, защото няма да ни стигне времето. Първия ден сме от 10:00 до 19:00 и това е в случай, че няма проблеми - иначе ще продължим до много късно, а университетът затваря по някое време, пък и няма да е приятно за хората след вас, ако се бавим :)
  8. Може да си оттренирате "talk"-а вкъщи, за да сте сигурни че се вмествате във времето (и че не говорите маловажни неща:)). Може някой да ви прекъсне с въпрос, имайте го предвид.
  9. Не пишете код 30 мин преди защитата ви, защото рискувате да счупите нещо :)

 

Успех на всички!

 

0
krazz avatar krazz 0 Точки

Би било добре ако може да предвидите адаптери от HDMI към VGA и HDMI към DisplayPort. Това са най-вероятните алтернативи за включване на тези които нямат HDMI порт или преходник към него.

0
16/12/2016 17:59:35
Можем ли да използваме бисквитки?
Ние използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Можете да се съгласите с всички или част от тях.
Назад
Функционални
Използваме бисквитки и подобни технологии, за да предоставим нашите услуги. Използваме „сесийни“ бисквитки, за да Ви идентифицираме временно. Те се пазят само по време на активната употреба на услугите ни. След излизане от приложението, затваряне на браузъра или мобилното устройство, данните се трият. Използваме бисквитки, за да предоставим опцията „Запомни Ме“, която Ви позволява да използвате нашите услуги без да предоставяте потребителско име и парола. Допълнително е възможно да използваме бисквитки за да съхраняваме различни малки настройки, като избор на езика, позиции на менюта и персонализирано съдържание. Използваме бисквитки и за измерване на маркетинговите ни усилия.
Рекламни
Използваме бисквитки, за да измерваме маркетинг ефективността ни, броене на посещения, както и за проследяването дали дадено електронно писмо е било отворено.