Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [SF2][Symfony][Symfony2]Manipulacja polami formularza w zależności od akcji
Forum PHP.pl > Forum > PHP > Frameworki
daniel1302
Witam, zacząłem uczyć się Symfony 2. Mam taki problem:
Mam formularz generowany przez klasę UserType:

W Klasie UserType posiadam generowane 3 kontrolki:
  1. $builder
  2. ->add('name', 'text', array(
  3. 'label' => 'Imię'
  4. ))
  5. ->add('mail', 'text', array(
  6. 'label' => 'Adres email'
  7. ))
  8. ->add('password', 'text', array(
  9. 'label' => 'Hasło'
  10. ));



I teraz wszystko ok, formularz przy akcji tworzenia użytkownika generuję sobię tak:

  1. $form = $this->createForm(new UserType(), $entity, array(
  2. 'action' => $this->generateUrl('user_create'),
  3. 'method' => 'POST',
  4. ));
  5.  
  6. $form->add('submit', 'submit', array('label' => 'Create'));
  7.  
  8. return $form;




I wszystko jest ok.
A tutaj mam problem bo chciałbym zrobić edycję użytkownika i nie pozwolić użytkownikowi edytować raz wpisanego imienia. Puki co tak generuję formularz:
  1. $form = $this->createForm(new UserType(), $entity, array(
  2. 'action' => $this->generateUrl('user_update', array('id' => $entity->getUserId())),
  3. 'method' => 'PUT',
  4. ));
  5.  
  6. $form->add('submit', 'submit', array('label' => 'Edytuj użytkownika'));
  7.  
  8. return $form;


Czy prościej utworzyć nowy formularz pod tą samą Encję Doctrina, czy jest jakiś inny sposób? Mam czas i uczę się frameworka więc zależy mi na tym, aby rozwiązanie było eleganckie, ponieważ chcę sie go dobrze nauczyć.


Pozdrawiam.
ohm
Stwórz formularz bez imienia ('name') i użyj do tego form events -> http://symfony.com/doc/current/cookbook/fo...dification.html
W PreSetData sprawdzisz czy imienia nie ma (lub czy jeszcze nie było edytowane) i dodasz sobie wtedy do tego formularza oczekiwane pole "name"
Forti
przy rejestracji proś o podanie imienia (required => true) a do edycji po prostu używaj innego *type, bez pola imienia wink.gif albo zostaw, ale daj disabled => true i po problemie.
daniel1302
Prostrze wyjście od obu znalazłem tylko nie wiem czy jest eleganckie. Mam podstawowy formularz tylko w klasie Type a pole name dodaje w kontrolerze w zależności od tego czy chcę czy nie. Encję mam tak ustawioną, żeby puste pola domyślnymi nadpisywła.
Forti
Tak też można. Symfony daje spore pole do popisu formularzami gdy tylko zrozumiemy je. Ja na poczatku strasznie ich nie lubiłem i narzekałem lecz w gruncie rzeczy są bardzo użyteczne.
ohm
Cytat(Forti @ 19.03.2015, 08:53:07 ) *
Ja na poczatku strasznie ich nie lubiłem i narzekałem lecz w gruncie rzeczy są bardzo użyteczne.

Offtop:
Fakt, jak zacząłem używać formularzy na dobre, to przy powrocie do dłubania ręcznego w pewnym projekcie, to niemalże jak dłubanie literek w tablicach kamiennych wink.gif

Cytat
Mam podstawowy formularz tylko w klasie Type a pole name dodaje w kontrolerze w zależności od tego czy chcę czy nie.

Też tak możesz, ale wg mnie Controller powinien przyjmować i przekazywać dane dalej, raczej bez ingerencji w te dane (czasem trzeba, wiadomo) a form builder powinien zarządzać formularzem i podejmować decyzje co i gdzie ma być.
M4ver7071
Trochę offtop a nie chce zakładać nowego tematu. Do sprawdzenia czy użytkownik to administrator czy zwykły user lepiej do tego użyć pliku security.yml czy adnotacji ?
Forti
$this->isGranted('role_admin') w controller id wersji 2.6.

A języku chodzi o zabezpieczenie pojedynch route/controller to ja preferuje annotacje.
M4ver7071
A mam pytanie. Bo mam formularz i dodałem jedno pole które nie znajduje się w Entity. I jak wysyłam ten formularz to jest możliwość to jedno (osobne dodane pole) nie było brane pod uwagę ? Bo wyświetla mi się, że brakuje metod get i set, a ja z tego pola dane chce do pliku zapisać.. Jak to zrobić ?
Forti
Jak dodajesz do forma

  1. ->add('some_name');


to zrób tak:

  1. ->add('some_name', null, array(
  2. 'mapped' => false
  3. );


Później w controllerze tylko pobierasz to pole z tablicy $request->request->get('some_name'); i robisz z nim co chcesz wink.gif W encji nie musi być w żaden sposób zdefiniowane.
M4ver7071
Powiedz mi, jeżeli chodzi o content danej podstrony lepiej go wrzucić do pliku widoku czy raczej trzymać to bazie a razie wywołania wrzucić to do ogólnego pliku i tam formatować?
Forti
w bazie trzymasz tylko tekst. Pobierasz ów tekst w kontroller / jakaś sobie custom serwis, i wrzucasz do widoku

  1. public function indexAction()
  2. {
  3. $entities = $this->getDoctrine()->getRepository('FortiCoreBundle:Article')->findBy(array(), array('created' => 'DESC'));
  4.  
  5. $this->breadcrumbs(array(array('Artykuły')));
  6.  
  7. return $this->render('FortiAdminBundle:Article:index.html.twig', array(
  8. 'entities' => $entities
  9. ));
  10. }


a w widoku po prostu:

  1. <head>
  2. </head>
  3. <body>
  4. <ul>
  5. {% for entity in entities %}
  6. <li>{{ entity.content }}</li
  7. {% endfor %}
  8. </ul>
  9. </body
  10. </html>


I to tyle z podstawowego użycia symfony wink.gif
M4ver7071
Okej ale skrypt powinnien robić dla każdej podkategorii widok i osobny plik z widokiem? Czy tylko jedne plik i ew. wrzucać do trgo pliku dane?
Forti
Cytat(M4ver7071 @ 30.03.2015, 12:06:35 ) *
Okej ale skrypt powinnien robić dla każdej podkategorii widok i osobny plik z widokiem? Czy tylko jedne plik i ew. wrzucać do trgo pliku dane?


Tak na szybkiego:

Jak zmienia się struktura html to osobny widok. Jak nie zmienia to oczywiście ten sam widok, prawda? ;]
M4ver7071
Okej, chce zrobić tak że część danych jest w bazie a cześć danych odczytuje z pliku.. Problem polega na tym, że jak próbuje to zrobić to SF2 krzyczy mi, że nie ma metod get itd. zastanawiam się czy ta droga budowy jest prawidłowa.

Czy nie lepiej by było mimo wszystko trzymać danych w bazie, utworzyć plik z danym szablonem i tam przekazywać wszelki kontent..



Również z drugiej strony nasuwa się problem bezpieczeństwa, czy jeżeli w bazie będą znaczniki HTML będzie to prawidłowe rozwiązanie czy tez nie.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.