Czy istnieje jakieś przeciwskazanie, aby klasę User rejestrować jako service? Chodzi o to, że ustawiam w niej role użytkownika na podstawie różnych parametrów i niewielkich algroytmów. Dotychczas były to parametry zapisywane w bazie, w tabeli User, natomiast teraz chcę nadać rolę na podstawie parametru zapisywanego w configu, a żeby się do niego dostać, potrzebowałbym wstrzyknąć - sam jeszcze nie wiem co, ale choćby np. cały container. Ale czy to jest zalecane rozwiązanie?

A takie coś nie może być ? http://stackoverflow.com/questions/1033070...e-inside-entity

Ale to wtedy za każdym razem musiałbym nadawać rolę w miejscu, w którym jest ona sprawdzana. Więc równie dobrze mógłbym jej nie nadawać, tylko osobno sprawdzić warunki jej przydzielania i na tym poprzestać.

Encja zdecydowanie nie powinna być usługą. Jeżeli opisane rpzez Ciebie "algorytmy" masz w encji, to utwórz nową usługę i tam je umieść, a encje zostaw w spokoju. Encje są w warstwie data persistance i tam powinny pozostać.

Tak trochę może offtopowo bo w Symfony siedziałem chwilę ale miałem podobny problem do Twojego w ZF2, po prostu stworzyłem sobie klasę statyczną przy bootstrapie i ładuję tam wszystkie tego typu dane i funkcję pomocnicze. Dla przykładu onBootstrap ustawia mi w klasie użytkownika, kluczowe dane z configu o które często odpytuję, ustawiam też entityManagera tak że jest dostepny w każdym miejscu projektu czy też dodaję funkcje pomocnicze takie jak tworzenie sluga do tekstu czy też generowanie losowego ID o konkretnej składni.

Czyli wszystkie role powinny być zapisane w bazie, a nie tworzone "w locie"? Myślałem, że skoro w dokumentacji jest:

[PHP] pobierz, plaintext 
public function getRoles()
{
 
return ['ROLE_USER']; 
}
[PHP] pobierz, plaintext 

to można sobie tam zwracać role jakie się chce, w zależności od wartości innych pól Usera.

Tak, ale jeśli chcesz użyć usługi, to już musisz to zmienić. Encja nie może korzystać z usług i tyle. Encja reprezentuje to, co zapisane jest w bazie.

- zauważ, że musi być ta metoda, bo wymusza to interfejs.
Natomiast ten fragment kodu jest owszem, niefortunny - bo nawet jeśli coś hardkodujemy to powinniśmy to chociaż okomentować.

Można tak zrobić, jeśli każdy User ma mieć zawsze jedną i tą samą rolę - po co wtedy zapisywać to w bazie? Robi się wtedy stałą typu "USER_DEFAULT_ROLE" (albo "FIXED_ROLE") a metoda getRole zwraca tą stałą.

Jeśli natomiast rola ma się dla użytkownika zmieniać, to chyba oczywiste, że powinieneś ją przechowywać w bazie danych.

Natomiast jeśli potrzebujesz obiektu, który zawiera dane nie tylko z bazy oraz nie jest odwzwierciedleniem rekordu z tabeli bazodanowej to nie może to być encja - jednak w praktyce różnie bywa i nierzadko programiści wp.... do encji co popadnie. O tym co powinno być w encji a co nie decyduje zdrowy rozsądek - zazwyczaj drobna logika jest dopuszczalna (np. implementacja metody getFullName, która zwraca name + lastname lub inne takie).
Jednak trzeba pamiętać, że "czystej" encji oczekuje wiele komponentów (formularze, walidatory, menedżer encji etc.) i majstrując przy niej możesz wywalić pół aplikacji

Jak jesteśmy przy Encjach i Serwisach to mam takie pytanie. Hipotetycznie i w uproszczeniu.

Mam klasę Counter dla User, takich liczników/aktualizatorów będę miał sporo większość odpalanych przez AJAX.

Zaczynam z Symfony i nie bardzo ogarniam struktury do tej pory pisałem w MVC i miałem jedynie 3 foldery

1. Mam zrobione: podczas rejestracji Listener nasłuchuje czy rejestracja przebiegła prawidłowo i uruchamia Kontroler z metodą Init, która zakłada dla Usera pozycję z w tabeli Counter.
2. Teraz chce przy każdym odświeżeniu strony aktualizować Counter Usera
... i mam dylemat co do nazewnictwa Folderów a raczej poprawnego przypisania tej usługi bo raczej inkrementacja Coutera to usługa co nie ?

Podpowiedzcie gdzie mam umieścić taka klasą aktualizującą Counter
1. Model/Manager
2. Service/Manager
3. a może zrobić Fabrykę dla Countera i wywołanie przez Klasę jakiegoś Listenera podczas każdego przeładowania strony wywoływane przez Twiga

Że co? Bardziej się nie dało utrudnić sobie życia?


Czemu chcesz nazywać klasy z "Manager"?

Co do klasy, to powinna być ona usługą, jest wiele konwencji nazewnictwa, stosuj jak najbardziej naturalne nazwy, jak np. UserCounter (licznik użytkowników), chociaż pewnie nie o to Ci chodzi. Jeśli chcesz (mogę jedynie przypuszczać, bo wyraziłeś się nieprecyzyjnie) licznik odsłon serwisu przez danego usera, to nazwij taką klasę ViewsCounter (licznik odsłon) lub coś w tym rodzaju.


Fabryka dla Countera... wywoływane przez listenera i twiga... współczuję utrzymania takiego rozwiązania.

na razie4 specyzuję tylko pkt 1.

Korzystam z FOSa a on defaultowo przekierowuje mnie na index więc muszę mieć listenera aby przechwycić poprawnie zalogowanie i przekierować na swój routing, ale może da radę to zrobić inaczej?

@Lowiczak

http://stackoverflow.com/questions/1878338...after-logged-in

nie musisz mieć żadnych listinerów.. zrozumiałem że po zalogowaniu ma cię gdzieś przekierować?

- oczywiście, podstawowym Twoim problemem jest, że jak przypuszczam, użyłeś jakiegoś bundla z konkretną implementacją, natomiast potrzebujesz implementacji szczególnej. Dlatego zamiast coś instalować po czym natychmiast kombinować jak to obejść, powinieneś po prostu zaimplementować logowanie po swojemu.

Ewentualnie zrobić to na Voter'ach, definiować swoje uprawnienia i w nich je sprawdzać dokładnie tak, jak ma to miejsce w przypadku roli.

[PHP] pobierz, plaintext 
//controller
$this->isGranted('ROLE_ADMIN');
[PHP] pobierz, plaintext 

A tak jakiś custom:

[PHP] pobierz, plaintext 
//controller
$this->isGranted(MojVoter::MOJE_SUPER_UPRAWNIENIE, $this->getUser());
[PHP] pobierz, plaintext 

I wtedy Voter wygląda tak:

[PHP] pobierz, plaintext 
 
<?php
 
namespace MojBundle\Security\Voter;
 
use Doctrine\ORM\EntityManager;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Authorization\Voter\Voter;
 
/**
 * Class MojVoter
 */
class MojVoter extends Voter
{
	const MOJE_SUPER_UPRAWNIENIE = 'MOJE_SUPER_UPRAWNIENIE';
 
	/**
	 * Determines if the attribute and subject are supported by this voter.
	 *
	 * @param string $attribute An attribute
	 * @param mixed  $subject   The subject to secure, e.g. an object the user wants to access or any other PHP type
	 *
	 * @return bool True if the attribute and subject are supported, false otherwise
	 */
	protected function supports($attribute, $subject)
	{
		if (self::MOJE_SUPER_UPRAWNIENIE !== $attribute) {
			return false;
		}
 
		return $subject instanceof UserInterface; // Lub co tam sobie chcesz
	}
 
	/**
	 * Perform a single access check operation on a given attribute, subject and token.
	 * It is safe to assume that $attribute and $subject already passed the "supports()" method check.
	 *
	 * @param string         $attribute
	 * @param mixed          $subject
	 * @param TokenInterface $token
	 *
	 * @return bool
	 */
	protected function voteOnAttribute($attribute, $subject, TokenInterface $token)
	{
	//Twoja logika która określa czy masz uprawnienie, zwracasz (boolean)
	}
}
[PHP] pobierz, plaintext 

Dzięki za info, jestem mądrzejszy o kilka postów , przekierowanie zrobiłem w configu co do fabryki to jednak jeszcze nie dorosłem do tematu.

Na razie mam tylko kilka serwisów. Co do Voter przyda się bo aktualnie wziąłem się za uprawnienia.