Usuwanie duplikatów z tablicy JavaScript

Prosta funkcyjka korzystająca z metody filter()  obiektu  Array

 

Renderowanie widoków Zend

Jeśli chcemy wykorzystać szablon widoku i wyrenderować go w celu późniejszego wykorzystania możemy skorzystać z następującego kodu

 
W ten sposób wynik renderowania trafi do zmiennej $bodyText. Kod html w niej zawarty możemy wykorzystać na przykład jako treść maila lub część innego widoku.

Jeśli natomiast chcemy w kontrolerze wyrenderować inny niż domyślny widok to postępujemy tak jak do tej pory z tym że na końcu kodu kontrolera określamy nazwę widoku który nas interesuje.

Więcej pod linkiem Manual

Zaszufladkowano do kategorii PHP

Ciekawe zagrywki w JS

2. Pętla z wywołaniem funkcji zwrotnej

Nieskończona pętla fadeInFadeOut

Kod który zmienia nagłówki jeden po drugim w nieskończonej pętli

 

Walidatory Zend

Numer telefonu

Adres email

Sprawdzamy czy mail jest w bazie. Np żeby wysłać na niego maila podczas resetu hasła:

Imię i nazwisko:

 

Przydatne wyrażenia regularne

1. Numer telefonu

 

Nawigacja a routing w ZF

Używanie Zend_Navigation i routingu w jednym projekcie może sprawić pewien problem. Mając zdefiniowane 6 odnośników do jednego postanowiłem napisać regułę routowania. Na moje nieszczęście wszystkie pozostałe odnośniki się zepsuły. Wskazywały dokładnie na to samo co odnośnik z routowaniem. Po kilku godzinach szukania znalazłem rozwiązanie. Okazuje się że Zend jeśli nie jest zdefiniowana żadna reguła to stosuje domyślną. Jednak jeśli mamy choć jedną i zostanie ona choć raz użyta to staje się ona aktualna dla wszystkich innych odnośników. Jedyne co należy zrobić to jawnie każdej stronie dodawanej do Zend_Navigation jawnie określać domyślny router. Przykład poniżej:

Bez opcji w linii 10 po kliknięciu w odnośnik “Home” zawsze trafialibyśmy na stronę postów (oczywiście jeśli najpierw klikniemy “Posty” i nadpiszemy domyślny router).

Formularze w Zend Framework

Podstawowy szablon potrzebny do obsługi formularzy w Zend.

Klasa formularza:

Podstawowa akcja kontrolera, który obsługuje dane z formularza:

A w miejscu gdzie ma być wyświetlony formularz:

Lub gdy chcemy sami decydować o jego strukturze w pliku html, to możliwe jest osobne renderowanie Etykiet, inputów i komunikatów błędu:

 

Dodatkowa walidacja – jeśli w kontrolerze stwierdzimy że coś jest nie tak z formularzem to możemy go jeszcze oznaczyć jako błędny i dodać stosowny komunikat do konretnego pola.
Dopiero gdy wszystko gra znajdziemy się w miejscu //process

Przyjazne URLe w Zend Framework. Routing i wyrażenia regularne

Standardowe adresy URL w ZF mają następującą postać: http://example.com/kontroler/akcja/parametr1/wartosc1/parametr2/wartosc2. Przy większej liczbie parametrów URLe stają się dosyć długie. Jednym z rozwiązań tego problemu jest zastosowanie routingu. W pliku application.ini możemy zdefiniować reguły, które będą odpowiednio interpretować adres i wywoływać odpowiedni kontroler potem akcję oraz przekażą do niej parametry. Najlepiej będzie to przedstawić na podstawie przykładu. W najprostszej formie wygląda to następująco:

Stary adres: http://example.com/index/onas
Nowy adres: http://example.com/o-nas

Stałym fragmentem każdej reguły jest resources.router.routes. Następnie pojawia się nazwa reguły i na końcu opcje. Pierwsza linijka określa jaki adres ma zostać przetworzony. Kolejne dwie odpowiadają za to jaki kontroler i jaka akcja zostaną wywołane.

Teraz przyjrzyjmy się jak przekazywać parametry:
Stary adres: http://example.com/index/portfolio/name/nazwa-projektu
Nowy adres: http://example.com/realizacje/nazwa-projektu

Mając taką regułę po wpisaniu w pasku adresu http://example.com/realizacje/nazwa-realizacji zostanie wywołana akcja portfolio kontrolera index z parametrem name równym nazwa-realizacji. Jeśli żaden parametr nie zostanie zdefiniowany to domyślnie będzie on równy wszystkie. Do tak zdefiniowanej reguły w widoku tworzymy linki następująco:

W pierwszym parametrze podajemy tablicę ze zmienną, a w drugim nazwę reguły. Gdyby w regule było więcej zmiennych to tablica miałaby po prostu więcej elementów.

Co ciekawe Zend pozwala również w regułach używać wyrażeń regularnych. Są możliwe dwa sposoby ich użycia:

Stary adres: http://example.com/archiwum/year/year/2012
Nowy adres: http://example.com/2012

Pierwszy sposób polega na wprowadzeniu zmiennej w regule. W naszym przykładzie jest to :year. Następnie przy pomocy opcji reqs.nazwaZmiennej określenie dla niej wyrażenia regularnego (Linia 4).

Drugi sposób polega na okresleniu wyrażeń regularnych w opcji route (linia 2), a następnie na mapowaniu poszczególnych częsci adresu do zmiennych (linie 5,6):

Stary adres: http://example.com/archiwum/month/year/2012/month/11
Nowy adres: http://example.com/2012/11

Third Party Cookies

Do czego służą ciasteczka w przeglądarkach każdy wie. Witryna ustawia ciastko, zapisuje w nim informację, a następnie jak użytkownik powraca to odczytuje te informacje. W takim przypadku mamy do czynienia z First Party Cookies. Są jednak sytuacje, gdy cookie jest ustawiany przez witrynę inną niż przeglądana. Ustawiane przez “osoby trzecie” ciastka nazywamy Third Party Cookies. Często taką trzecią stroną jest serwer który emituje reklamy. Aby później na stronie docelowej móc ocenić skąd pojawił się użytkownik sprawdza ciastka. W większości przeglądarek nie ma z tym problemu. Jednak w IE domyślne ustawienia prywatności zezwalają tylko na odczyt ciastek przez witryny, które je ustawiły. Prostym rozwiązaniem na to jest wysłanie do przeglądarki nagłówka, który zezwoli na pobieranie ciastek z innej domeny. W PHP wygląda to następująco: