Plugin pubsub, którego pierwowzorem była funkcjonalność frameworka Dojo. Służy do rejestracji i publikacji zdarzeń w naszej aplikacji (nie chodzi o eventy DOM). Dzięki czemu w niektórych przypadkach może udać się zmniejszyć ilość ścisłych powiązań w kodzie (coupling). Zresztą trudno to wyjaśnić pisząc tekst po polsku… zachęcam zatem do obejrzenia filmy Rebeki Murphey z nettuts (polecam jakość HD i fullscreen):

Pozwala na zorganizowanie aplikacji intensywnie wykorzystującej Ajax tak, żeby nie tracić działania przycisku wstecz i w ogóle historii przeglądania.

Mnie ostatnio przydało się, gdy musiałem dorobić stronę w stronie i nie bardzo miałem ochotę grzebać w mechanizmach php, które tam zachodzą. Po prostu każdy link w podmenu ładuje treść ajaxem i każda taka strona ma swój własny link.

Polecam super krótki tutorial na nettuts, który pokaże Wam jak zacząć:
http://net.tutsplus.com/tutorials/javascript-ajax/quick-tip-an-introduction-to-sammy-js/

Załóżmy, że nie wiem jak napisać taką funkcję, żeby była elastyczna, po prostu we wnętrzu mam zaszyte id pól formularza:

function count_gros_value(){
   $("#Invoice[gros]").val(
      parseFloat($("#Invoice[net]").val()) *
      parseFloat($("#Invoice[vat]").val())
   );
}
// wywołanie
count_gros_value();

(nie sprawdzałem tego kodu, służy jako przykład i nie mam pojęcia czy dobrze działa).

Oprócz wielkiej nieelastyczności kodu (o czym teraz pisał nie będę) istnieje problem polegający na tym, że nie wiem czy jakiś inny programista nie zdefiniował funkcji count_gros_value gdzieś w layoucie. Oczywiście dostanę error jeśli tak jest, więc poprawię ją na my_count_gros_value() (sic!). Ok, wszystko działa. Jednak przychodzi inny programista i odczuwa potrzebę zdefiniowania funckji my_count_gros_value() w layoucie (no bo count_gros_value() już istnieje, a jego robi coś inaczej/lepiej więc trzeba ją zaimplementować). W ten sposób rozwala twój zaimplementowany fragment i nikt tego nie zauważa.

Jak tego uniknąć? Można zacząć nazywać takie “lokalne” funkcje invoices_index_count_gros_value() ale to zaczyna wyglądać nieestetycznie i aż się ciśnie na usta magiczne słowo “namespace”.

W Javascript nie ma przestrzeni nazw, ale możesz użyć obiektów:

var invoices = {
   index: {
      count_gros_value: function(){
         $("#Invoice[gros]").val(
            parseFloat($("#Invoice[net]").val()) *
            parseFloat($("#Invoice[vat]").val())
         );
      }
   }
}
// wywołanie
invoices.index.cunt_gros_value();

to jest już fajniejsze, ale ma dwa problemy:

1. ciągłe definiowanie obiektów dla namespace’ów jest równie uciążliwe jak nazwa funkcji invoices_index_count…
2. gdy ktoś przed nami zdefiniuje zmienną var invoices = “invoices”; to mu ją nadpiszemy

Dlatego proponuję taką funckję, która definiuje dowolnie głębokie obiekty udające namespace’y i do tego tworzy je wszytkie w zmiennej o pseudolosowej nazwie (w stylu: Namespace12883495048110.1425782083547854):

function Namespace(namespace_path){
	var w = window;

	window.namespaceFrameworkNamespaceName =
		window.namespaceFrameworkNamespaceName ||
		"Namespace"+ new Date().getTime() + new Math.random();

	var arr  = (window.namespaceFrameworkNamespaceName + namespace_path).
						split(".");

	for(i in arr){
		w[ arr[i] ] = w[ arr[i] ] || {};
		w = w[ arr[i] ];
	}
	return w;
}

Ok, jakiś uparciuch mógłby się uprzeć, że ktoś może w aplikacji zmiennej ‘namespaceFrameworkNamespaceName’ – takiego problem nie rozwiązywałbym na poziomie kodu, ale personalnym (zwiałbym z projektu) ;)

tak wygląda definiowanie funkcji w namespace:

Namespace("app.users.index").check_form = function(){
	document.write("my_check_form()");
};

a tak jej wywołanie:

Namespace("app.users.index").check_form();
// lub gdy mamy zamiar wywołać wiele funkcji z danego namespace:
with(Namespace("app.users.index")){
 check_form();
}

Można by z tego zrobić tez fajne rozszerzenie jQuery,
$().nspc(“app.invoices.index”) (pisałem już o rozszerzaniu jQuery w tutorialu “longPolling”)

ajax

Problem jest następujący: użytkownik wpisuje kod. My sprawdzamy go na serwerze i jeśli jest prawidłowy, to zwracamy pewne powiązane z nim właściwości (np. wysokość rabatu) i pewien komunikat, który musi być wyświetlony na stronie (np. w przypadku błędnego kodu “kod promocyjny jest niepoprawny”. Dodatkowe wymaganie jest takie: wysokość rabatu ma się pojawić koło ceny całkowitej, cena ma się zmniejszyć o ten rabat, a komunikat ma się pojawić nad przyciskiem “Zamów”, które jest w fizycznie w innym miejscu niż cena. Dobrze by było, gdyby w wypadku nieprawidłowego kodu przycisk zamów był nieaktywny.

Jeśli o Ajaxie myślisz tylko jak o sposobie na podmienianie fragmentów strony bez przeładowania to możesz skończyć z takim dziwadłem:

Wysyłasz trzy ajaxy – jeden update’uje jakiś element z rabatem, drugi pole z wiadomością, a trzeci (o zgrozo) przesyła kod html przycisku (raz disabled, raz enabled). No i jeszcze parsujesz, tniesz i sklejasz zwrócony rabat, żeby odjąć go od ceny.

Teraz zacznij myśleć o Ajaxie, który jest sposobem na komunikację z serwerem bez potrzeby przeładowania strony (przeładowanie strony to też komunikacja z serwerem – my pytamy, on odpowiada, o coś prosimy, serwer coś robi). Do tego po otrzymaniu odpowiedzi z serwera możemy z nią zrobić co chcemy – nie musi się automatycznie i bezmyślnie ładować do diva #ajaxResponseToParse ;) I w końcu, jeśli jeszcze nie wiesz, dowiedz się co to znaczy JSON.

Jeśli dodasz te trzy składniki to możesz skończyć z takim rozwiązaniem:

$.getJSON("http://example.com/check_code/XXX", function(data){
   $("#discount-ammount") = data.discount;
   $("#price").html(data.new_price); // *
   $("#message").html(data.message);
   $("#submit").get(0).disabled = data.submit_disabled;
});

(*) myślę, że dobrze takie rzeczy liczyć w jednym miejscu po stronie serwera.

Albo jednym słowem – wyjdź poza wygodne schematyczne myślenie i rozejrzyj się wokół. Możliwe, że wbijasz wkręt obcasem siedząc na młotku i gwoździe mając w kieszeni.

var Klasa = function(){
  this.x = 1;  //definicja pól
}
//definicja metod
Klasa.prototype.setX = function(parametr){
  this.x = parametr;
}

Po pierwsze potrzebujesz zdefiniować swoją klasę:

function myClass(params){
}

Prościzna ;) Spróbujmy teraz obsłużyć callback beforeInit, który odpali się “najsampierw” przy tworzeniu obiektu:

function myClass(params){
    if(params.beforeInit){
        console.log("beforeInit");
        params.beforeInit();
    }
    console.log("Init complete")
}
console.log("=============");
var a = new myClass(
  {
    beforeInit: function(){console.log("My message!");}
  }
);

Włącz firebuga i sprawdź działanie ;)

=============
beforeInit
My message!
Init complete

Oczywiście Twoja klasa może zechcieć coś zrobić oprócz stworzenia siebie samej ;) Callbacki mogą zachowywać się różnie w zależności od stanu obiektu. Do klasy dodałem metodę doSth i callback beforeRun (który wykonuje się przed wykonaniem metody doSth)

Wypróbuj następujący kod:

function myClass(params){
    if(params.beforeInit){
        console.log("#beforeInit");
        params.beforeInit();
    }

    this.doSth = function() {
        if(params.beforeRun){
            params.beforeRun(this.state);
        }
        console.log("#doSth");
    }

    if(params.state) {
        this.state = params.state;
    }else{
        this.state = false;
    }

    console.log("Init complete")
}
console.log("=============");
var a = new myClass(
  {
    state: 1,
    beforeRun: function(state){
        if(state != false) {
            console.log("Extended! state = " + state);
        }else {
            //do nothing
        }
    }
  }
);
a.doSth();
console.log("=============");
var b = new myClass(
  {
    beforeRun: function(state){
        if(state != false) {
            console.log("Extended! state = " + state);
        }else {
            //do nothing
        }
    }
  }
);
b.doSth();

wynik:

=============
Init complete
Extended! state = 1
#doSth
=============
Init complete
#doSth

Możesz też uzależnić wykonanie metody doSth w zależności od warunków wewnętrznych (parametr state) lub zewnętrznych:

function myClass(params){
    if(params.beforeInit){
        console.log("#beforeInit");
        params.beforeInit();
    }

    this.doSth = function() {
        if(params.beforeRun){
            if(!params.beforeRun(this.state)){
                return;
            }
        }
        console.log("#doSth");
    }

    if(params.state) {
        this.state = params.state;
    }else{
        this.state = false;
    }

    console.log("Init complete")
}
console.log("=============");
var a = new myClass(
  {
    state: 1,
    beforeRun: function(state){
        if(state != false) {
            console.log("Extended! state = " + state);
        }else {
            return false
        }
    }
  }
);
a.doSth();
console.log("=============");
var b = new myClass(
  {
    beforeRun: function(state){
        if(state != false) {
            console.log("Extended! state = " + state);
        }else {
            return false
        }
    }
  }
);
b.doSth();
console.log("=============");
var c = new myClass(
  {
    beforeRun: function(state){
        if( (new Date().getTime())%2  ) {
            console.log("Extended! state = " + state);
        }else {
            return false
        }
    }
  }
);
c.doSth();

Wynik (zależy od aktualnego czasu, więc może okazać się konieczne uruchomienie go kilka razy, zanim otrzymasz identyczny):

=============
Init complete
Extended! state = 1
=============
Init complete
=============
Init complete
Extended! state = false

W przypadku obiektu c metoda run odpali się tylko, jeśli aktualny timestamp jest podzielny przez 2 ;)

To tyle. Mam nadzieję, że pozwoli Wam to wymyślać ciekawsze i bardziej użyteczne fragmenty kodu javascript, nawet tego używanego prywatnie.

Sprytnie zaprojektowana klasa ze sprytnymi callbackami jest bardzo przyjemna – możliwe jest modyfikowanie jej zachowania bez modyfikacji klasy bazowej. To samo podejście znacie pewnie z Behaviors cake’a.

Mam formularz wyszukiwania, który wygląda różnie w różnych widokach, jednak na jego podstawie jest budowany url tak samo dla każdego widoku. Na przykład:

// some view
echo $form->create("Model");
echo $form->input("field1");
echo $form->input("field2");
echo $form->input("field3");
echo $form->end("submit");

W zdarzeniu onsubmit chcę wygenerować taki url:
“/field1:value1/field2:value2/field3:value3″
Gdzie valueX to oczywiście wartość danego pola.

Pobranie interesujących nas pól:

$("form input[type!=submit][name!=_method], form select");

Tak można wytargać nazwę pola z “name” inputów (zakładając, że w zmiennej string mamy cały name):

// string.substr(
//   string.indexOf("[", string.indexOf("]"))
// ).slice(1, -1);
// nowa, lepsza, prostsza wersja:
string.substr(
   string.lastIndexOf("[")
).slice(1, -1)

Całość tworzenia linków:

var params = "";

$("form input[type!=submit][name!=_method], form select").each(
   function(index,element) {
      params +=
         element.name.substr(
            element.name.lastIndexOf("[")
         ).slice(1, -1)+
         ":"+
         element.value+
         "/";
   }
);

Przydaje się, jeśli pracujesz z parametrami “named”