[MVC] Indywidualne, globalne zmienne w szablonie, nick zalogowanego Opcje

[markonix]

Nie mam pomysłu gdzie umieścić dane globalne indywidualne dla zalogowanego użytkownika.
W dużym uproszczeniu chodzi np. o nick. Oczywiście można pakować w sesje ale powiedzmy, że tych danych jest więcej i mogą się zmieniać.

Zmienna ta jest globalna, jest w każdym widoku (w nagłówku, header) i na pewno nie widzi mi się, aby każdorazowo w każdym kontrolerze i jego akcji wysyłać "ręcznie" tą zmienną do widoku.

Jedyne co mi przychodzi do głowy to helper ale czy wolno w nim operować na modelu (model user, wykonanie zapytania, zwrócenie pożądanych danych)?

Ten post edytował markonix 15.04.2012, 11:03:37

[tolomei]

Może coś w stronę wzorca Registry?

[markonix]

Klasę registry mam do przechowywania globalnego chyba że mówimy o całkowicie innej filozofii.
Jeżeli chodzi o klasę to gdzie by wypadało zrobić te przypisanie? W bootstrap?

[tolomei]

Chcesz przechowywać globalne dane indywidualne dla każdego użytkownika. Jak nic nasuwa się tutaj sesja.
Dane mogą się zmieniać - nie widzę problemów.
Napisz sobie jakąś dobrą klasę dostępu do tych danych i bazuj na sesji w wydzielonej przestrzeni nazw.

Takie moje zdanie - może ktoś inny coś zaproponuje.

[markonix]

No to może troszkę na przeciw sesjom.
Jakiś box z statystykami użytkownika, które się zmieniają praktycznie są chwile gdy wykona jakąś akcje.
Tutaj sesje byłby totalnie nieprzydatne chyba, że bym je aktualizował przy każdej zmianie, a sesje jak dla mnie powinny być tylko przy logowaniu inicjowane.

[Orzeszekk]

Dziwny problem. Robisz sobie kontroler common ktory wywolujesz z widoku i ktory zwraca ci dane potrzebne do wyswietlenia nicku uzytkownika. z tego co pamietam to w asp.net i w symfony 1/2 mozna wywolywac akcje z poziomu widoku. A jak sie nie da to robisz helper ktory odpytuje ten kontroler albo od razu model, i zwraca dane ktore dalej sobie wyswietlasz w layoucie jak ci sie zywnie podoba.

w asp.net mvc jest cos takiego jak ViewBag - jest to globalny slownik ktory jest dostepny we wszystkich widokach uzytych do zrenderowania odpowiedzi dla danego requesta. Mozna sobie wczytac jakies dane akcją lub partial akcją, wrzucic to do viewBaga i nastepnie skorzystac z tego w innym widoku. moze tez sobie zaimplementuj cos takiego.

helper nie musi operowac na modelu - wystarczy ze wywola akcje kontrolera ktora mu dostarczy paczke danych. w koncu to kontroler jest od zlepiania modeli i widokow.

sorki ze podaje przyklad z innego jezyka ale teraz glownie na nim siedze a mvc niezaleznie od języka jest podobne wiec chodzi o samą idęę.

Ten post edytował Orzeszekk 15.04.2012, 12:23:16

[markonix]

Chyba zrobię helper z odwołaniem do modelu user, będzie najprościej.

[Pilsener]

Ja do personalizacji aplikacji polecam ciacha - przykład: zapisujesz informacje w co user klika i na tej podstawie generujesz mu np. menu podręczne jego ulubionych działów. Żeby coś takiego zrobić w bazie to raz - trzeba się napocić a dwa - po co obciążać bazę i parser? A gdy user ciacho zgubi czy zje to nic się nie dzieje.

[Fifi209]

Tutaj sesje byłby totalnie nieprzydatne chyba, że bym je aktualizował przy każdej zmianie, a sesje jak dla mnie powinny być tylko przy logowaniu inicjowane.

A jak są zrobione np. koszyki w sklepach internetowych?

Użytkownik klika, dodaje do koszyka (do sesji), strona się przeładowuje i robi tak ciągle, póki nie zadecyduje zrezygnować z czegoś lub zapłacić.

[viking]

Przykład jak można zrobić: http://framework.zend.com/manual/en/zend.auth.html

[by_ikar]

A czy nie prościej mieć dostęp do obiektu bezpośrednio z szablonu? W symfony masz coś takiego jak $app i z jego poziomu masz dostęp do obiektów, chociażby takich jak request. I nie widzę przeciwieństw aby i taki dostęp mieć w przypadku obiektu użytkownika

[markonix]

Ja do personalizacji aplikacji polecam ciacha - przykład: zapisujesz informacje w co user klika i na tej podstawie generujesz mu np. menu podręczne jego ulubionych działów. Żeby coś takiego zrobić w bazie to raz - trzeba się napocić a dwa - po co obciążać bazę i parser? A gdy user ciacho zgubi czy zje to nic się nie dzieje.

A jak są zrobione np. koszyki w sklepach internetowych?

Użytkownik klika, dodaje do koszyka (do sesji), strona się przeładowuje i robi tak ciągle, póki nie zadecyduje zrezygnować z czegoś lub zapłacić.

Wspomniałem, że chodzi o bazodanowe dane typu: imię, stan konta, jakieś alerty itp.
Nie widzę tu miejsca dla ciasteczek, które oczywiście wykorzystuje, nawet dokładnie tak jak piszesz, do obsługi menu.

Sesje musiałbym aktualizować przy każdej zmianie np. transakcji. Uważam, że ten pomysł jest zupełnie nietrafiony przy celu, o którym wspominam.

Ten post edytował markonix 16.04.2012, 11:28:18

[tehaha]

Sesja się tutaj właśnie idealnie nadaje, zwłaszcza, że część danych zostanie pobrana tylko raz i już się nie zmienią. Przecież w przypadku zmiany nie aktualizujesz całej sesji, a jedynie to co jest Ci potrzebne, czyli w tym przypadku możesz tylko dorzucić do tablicy transakcji dodatkową pozycję lub ją zaktualizować. Możesz sobie ładnie wszystko wrzucić do wielowymiarowej tablicy i trzymać to w sesji

[PHP] pobierz, plaintext 
$_SESSION['data'] = array
(
	'userData' => array
	(
		'name'=>'Jan',
		'surname'=>'Kowalski'
	),
	'accountData'=>array
	(
		'amount'=>34,54,
		'currency'=>'PLN',
		'lastTrans'=>'2012-04012 14:54:00'
	),
	'notifications' => array
	(
		array('type'=>'error', 'msg'=>'treść...'),
		array('type'=>'error', 'msg'=>'treść...'),
	)
);
[PHP] pobierz, plaintext 

Uwierz sesja nie służy tylko i wyłącznie do przechowywania tam jednej zmiennej $_SESSION['userLogged'] = 1, i jest bardzo wygodna jeśli chodzi o takie personalne dane pobierane tylko jeden raz, dane tymczasowe, komunikaty systemowe itd.

[markonix]

No ale wracając do modelu MVC to powiedzmy, że mam model użytkownika czy tam model transakcji.
I teraz przy metodzie "updateAccount($amount)" musiałbym oprócz aktualizacji w bazie dokonać aktualizacji sesji.
Nie wiem.. Jak ja bym takie coś zobaczył w cudzej aplikacji to bym się mocno zdziwił, nigdy nie widziałem takiej metody.

Zawsze uczono mnie (głównie te forum), że należy ograniczać ilość danych przechowywanych w sesji.
Dlatego też zawsze się tego trzymałem - nawet nie przechowuje typu konta (admin i nie admin) w sesji ale sprawdzam po ID zalogowanego czy ma admina..

[tehaha]

Zawsze uczono mnie (głównie te forum), że należy ograniczać ilość danych przechowywanych w sesji.
Dlatego też zawsze się tego trzymałem - nawet nie przechowuje typu konta (admin i nie admin) w sesji ale sprawdzam po ID zalogowanego czy ma admina..

Jesteś w stanie podać mi jakiś rozsądny argument stojący za tym, żeby nic nie trzymać w sesji? Czy mam rozumieć, że jak chcesz zrobić coś tak banalnego jak "Witaj, użytkownik" to przy każdym odświeżeniu strony pobierasz to z bazy i wykonujesz zbędę zapytania? Poza tym warto zdefiniować tą "ilość danych", przecież taka tablica to może będzie 5KB danych, nie mówimy tu o jakichś szalonych pomysłach przechowywania w sesji zrzutu całej tabeli tylko o kilkudziesięciu linijkach a to tyle co nic. Sesje są bardzo przydatne w nie których przypadkach i warto je używać i jak dla mnie to jest właśnie jeden z takich przypadków. Z kwestii bezpieczeństwa nie przechowuje się w sesji żadnych haseł, ale inne dane to już spokojnie można.

musiałbym oprócz aktualizacji w bazie dokonać aktualizacji sesji.
Nie wiem.. Jak ja bym takie coś zobaczył w cudzej aplikacji to bym się mocno zdziwił, nigdy nie widziałem takiej metody.

Nigdy nie widziałeś, żeby obiekt w swojej metodzie wywołał metodę innego obiektu?

Odwołując się jeszcze do jednego z Twoich poprzednich postów to to czy dane warto trzymać w sesji, zależy jeszcze od tego jak często będą aktualizowane - sesje świetnie się nadają do danych: spersonalizowanych, tymczasowych i obowiązujących w trakcie jednej sesji użytkownika. Ale np. do statystyk to już nie za bardzo, chyba, że są to takie statystyki, które nie zmienią się w czasie odwiedzin.

[viking]

Chyba mylisz pojęcia. Warto ograniczyć ilość danych po stronie klienta (choćby ze względu na rozmiar cookie 4kB i bezpieczeństwo takich danych). Ja osobiście trzymam wyłącznie ID sesji i nigdy więcej. Natomiast to jest Twój łącznik "stanowości". Po stronie serwera masz kontener z danymi zapisanymi w sesji.

[tehaha]

Chyba mylisz pojęcia. Warto ograniczyć ilość danych po stronie klienta (choćby ze względu na rozmiar cookie 4kB i bezpieczeństwo takich danych). Ja osobiście trzymam wyłącznie ID sesji i nigdy więcej. Natomiast to jest Twój łącznik "stanowości". Po stronie serwera masz kontener z danymi zapisanymi w sesji.

Szczerze mówiąc to nie zrozumiałem Twojej odpowiedzi, sesja nie trzyma danych po stronie użytkownika tylko w pliku na serwerze, użytkownik ma tylko ID sesji.

Ten post edytował tehaha 18.04.2012, 10:53:12

[viking]

To była odpowiedź do postu markonix

[markonix]

Sesja trzyma dane tam gdzie tego sobie życzymy, sesja wbudowana w PHP jak i własny mechanizm sesji.
Dlatego nie można tak ślepo myśleć, że trzymanie w sesji odciąża aplikację bo odczytanie z niej wartości to jest normalna operacja na pliku bądź zapytanie (oczywiście szybsze niż zwykłe bo zwykle trzyma się sesje w polach MEMORY).

[tehaha]

Dlatego nie można tak ślepo myśleć, że trzymanie w sesji odciąża aplikację bo odczytanie z niej wartości to jest normalna operacja na pliku bądź zapytanie

Tu nie o chodzi o to czy to odczyt pliku czy zapytanie do bazy (bo różnica jest w bezpieczeństwie i wygodzie obsługi a nie szybkości, bo przy takiej małej ilość danych to bez różnicy), tylko chodzi o ilość tych operacji, jeżeli będziesz do każdej byle informacji, która i tak się nie zmienia tworzył oddzielne zapytanie do bazy przy każdym odświeżeniu strony to generujesz sobie większe obciążenie niż jest to konieczne.