Clicky

Skocz do zawartości


Zdjęcie
- - - - -

[K3] Notification - moduł powiadomień.

6 odpowiedzi w tym temacie

  • Zaloguj się, aby dodać odpowiedź

#1 phpion

phpion

    Senior Mastah

  • Użytkownik
  • PipPipPip
  • 774 postów
  • Skąd:Sosnowiec, Dąbrowa Górnicza

Napisano 01 wrzesień 2012 - 13:01

Heja,
w wolnych chwilach zacząłem powoli ogarniać K3, a także Githuba. W wyniku tego powstał moduł do tworzenia powiadomień (informacja o błędzie, potwierdzenie itp.). Całość znajduje się na Githubie:

https://github.com/phpion/notification

Wszelkie uwagi mile widziane :)
Notifero - Technologie Informatyczne | Warsztat: Kohana 3.x/2.x + PostgreSQL/MySQL | Programista Kohana

#2 mck

mck

    Jestę Blogerę

  • Admin
  • 1544 postów

Napisano 01 wrzesień 2012 - 13:41

Generalnie jestem za, a nawet przeciw.

IMHO zamiast tego:
$notification = Notification::instance();
$key = $notification->error('Error!');

powinno być tak:
$key = Notification::error('Error!');

:)

#3 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 01 wrzesień 2012 - 18:53

1. W konfiguracji nie trzymaj HTML ani komunikatow bledow. Od tego pierwszego sa widoki, a od tego drugiego pliki jezykowe.
2. Zamiast self:: uzywaj static:: (wiecej w manualu). W przyszlosci unikniesz "dziwnego" zachowania obiektow.

Jak wiadomo subiektywnie.

#4 phpion

phpion

    Senior Mastah

  • Użytkownik
  • PipPipPip
  • 774 postów
  • Skąd:Sosnowiec, Dąbrowa Górnicza

Napisano 01 wrzesień 2012 - 20:22

@mck:
Dlaczego widziałbyś tu metodę jako statyczną? Osobiście wydaje mi się, że lepiej mieć to jako zwykły obiekt, a nie operować na składowych i metodach statycznych. Poza tym w tym momencie odpadłaby nam możliwość tworzenia powiadomień z administracji do części użytkowej (teraz możemy to zrobić poprzez parametr dla metody instance()). Jakoś nie jestem przekonany do klas, których większość to metody statyczne (poza helperami, których pojedyncze metody mają konkretne zadania).

@lukaskolista:
1. Zastanawiałem się czy wydzielić "szablonu" do pliku widoku, jednak wydawało mi się to sztuką dla sztuki. Kodu HTML jest tutaj jak na lekarstwo, więc chyba byłoby to zbędne. Co do komunikatów: zakładam, że masz na myśli "Hey man!" - to tylko przykład :) Tak samo wiem, że generowanie formularza w kontrolerze to kiepski pomysł, ale chodziło mi o maksymalną przejrzystość przykładu.
[chyba jednak wydzielę to do osobnych widoków :)]
2. Czy chodzi Ci o:
http://php.net/manua...ic-bindings.php
? Szczerze mówiąc nie wiedziałem o tym, dzięki za cynk. Czy przejście z self:: na static:: tyczy się wszystkiego (tj. odniesienia do stałych, metod statycznych tej samej klasy)? Na razie nie mam chwilki by dokładnie zapoznać się z tym tematem.
Notifero - Technologie Informatyczne | Warsztat: Kohana 3.x/2.x + PostgreSQL/MySQL | Programista Kohana

#5 mck

mck

    Jestę Blogerę

  • Admin
  • 1544 postów

Napisano 01 wrzesień 2012 - 21:49

1. W konfiguracji nie trzymaj HTML ani komunikatow bledow. Od tego pierwszego sa widoki

Jaki jest sens tworzenia widoków dla 1 znacznika? Taka sztuka dla sztuki?
Pozwolę sobie zacytować klasyka:

MVC Cię nie wykarmi, fanatyzm Ci ZUSu nie opłaci ;)


Dlaczego widziałbyś tu metodę jako statyczną? (...) Poza tym w tym momencie odpadłaby nam możliwość tworzenia powiadomień z administracji do części użytkowej (teraz możemy to zrobić poprzez parametr dla metody instance()).

Tak jakoś mam ostatnim czasem ;) Oczywiście nie oznacza to, żeby całość robić na statycznych, raczej chodzi mi o wyprowadzenie takiego skrótu. A dodatkowe ustawienia lubię sobie przekazać jako tablicę w kolejnym parametrze.

2. Czy chodzi Ci o:
http://php.net/manua...ic-bindings.php
? Szczerze mówiąc nie wiedziałem o tym, dzięki za cynk. Czy przejście z self:: na static:: tyczy się wszystkiego (tj. odniesienia do stałych, metod statycznych tej samej klasy)? Na razie nie mam chwilki by dokładnie zapoznać się z tym tematem.

LSB fajna sprawa. Static pozwala ci na dostanie się do własności i funkcji klasy z poziomu klasy nadrzędnej.
Dla przykładu możesz stworzyć fabrykę, która zadziała we wszystkich dziedziczących klasach:
public static function factory($name)
{
return new static($name);
}


#6 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 02 wrzesień 2012 - 08:44

Szczerze mówiąc nie wiedziałem o tym, dzięki za cynk. Czy przejście z self:: na static:: tyczy się wszystkiego (tj. odniesienia do stałych, metod statycznych tej samej klasy)? Na razie nie mam chwilki by dokładnie zapoznać się z tym tematem.

Tak, o ile chcesz, aby podczas przeciazenia metody w potomku wykonywana byla wlasnie ta przeciazona metoda. Jezeli chcesz "zablokowac" przeciazanie metod, to wtedy wlasnie uzywa sie self::

mck@
implementacja factory() i instance() to raczej pod traits podchodzi, niestety 5.4 nie jest dostepne na wiekszosci serwerow.

#7 Zepco

Zepco

    Senior Mastah

  • Moderator
  • 1583 postów
  • Skąd:Kielce

Napisano 02 wrzesień 2012 - 21:45

IMHO helper do tego typu zadań nadaje się dużo lepiej niż singleton. Ma łatwiejsze i bardziej przejrzyste użycie (krótszy zapis). Poza tym i tak operujesz na jednych i tych samych danych, więc po co bardziej kombinować.
Co do HTML, to widoki są bardziej elastyczne, bo dostają tylko suche dane, a jak to będzie reprezentowane, to już zależy od wymogów projektu. W Twoim przypadku jak będzie kilka błędów, to będą się one wyświetlały jako DIV jeden po drugim. A co jeśli ma to zapisane jako listę UL? Wtedy nie masz możliwości dodania kontenera, który będzie przechowywał wszystkie elementy listy (LI).
Tak samo z metodami typu error, success. Lepiej zastosować __callStatic() i nazwa metody będzie jednocześnie typem wiadomości, tak jak to podał @mck. Oczywiście możesz w konfiguracji ograniczyć liczbę klas i jeśli ktoś wpisze niewłaściwą metodę, to wywali wyjątek.

Do czego używasz timestamp dla wiadomości?

OŚWIADCZENIE: Ja, niżej podpisany, świadomy wszystkich konsekwencji tego posta postanawiam go dopuścić do użytku publicznego, albowiem bo gdyż aczkolwiek uważam, że nie wyrządzi on (znaczy: post) krzywdy nikomu innemu niźli mnie samemu (czyli autorowi posta).
-- Zepco --





Użytkownicy przeglądający ten temat: 0

0 użytkowników, 0 gości, 0 anonimowych