Ikonki, paski, klepsydry - wszystko o czekaniu (waiting icons)

W każdej aplikacji webowej potrzeba animowanych elementów przedstawiających proces ładowania. Albo potrzeba ikon, które nie mówią nic o procesie ładowania poza enigmatycznym zapewnieniem, że jakoweś tajne informacje przetwarzane są po stronie serwera.
Na tej stronce mamy wybór: http://mentalized.net/activity-indicators/

Kilka sztuczek w modelach Ruby on Rails

Przedstawiam kilka ciekawych "chwytów" dla modeli w Ruby on Rails. Dla jednych bardzo odkrywcze, a dla innych może już nie.

Polskie nazwy dla atrybutów

Rails z "automatu" fajnie wyświetla błędy dla modelu. Fajnie tylko pod warunkiem, że się spolonizowało aplikację. Pozostało oczywiście to, że atrybuty wyświetlają się nadal w swojej oryginalnej formie.
Jest na to rada. Umieszczamy to w modelu:

HUMANIZED_ATTRIBUTES = {
  :last_name => "Nazwisko",
  :first_name => "Imię",
  .
  .
  .
  :gender => "Płeć"
}
def self.human_attribute_name(attr)
  HUMANIZED_ATTRIBUTES[attr.to_sym] || super
end

No i już wszędzie pojawi się zamiast "last_name" napis "Nazwisko".

Walidacje dla grupy atrybutów (pól)

Załóżmy, że mamy kilka pól dla których należy nanieść ograniczenie. Warto zbudować dla nich stałą, aby później (po latach) zmieniając kod aplikacji rozumieć co artysta (ja) miał na myśli :-)
Mogłoby to wyglądać mniej więcej tak:

class DayPayment < ActiveRecord::Base
  SHORT_FIELD_LENGHT = 4 
  SHORT_FIELDS = %w(morning afternoon midnight)
  .
  .
  .
  validates_lenght_of SHORT_FIELDS, :maximum => SHORT_FIELD_LENGHT
  .
  .
  .
end 

Proste typy wyliczeniowe wymagane w polach

Załóżmy, że chcielibyśmy aby w bazie zapisywana była płeć użytkownika w formacie tekstowym jako "mężczyzna" albo "kobieta". Możemy to zrobić tak:

class User < ActiveRecord::Base
  VALID_GENDERS = ["mężczyzna", "kobieta"]
  .
  .
  .
  validates_inclusion_of :gender,
                         :in => VALID_GENDERS,
                         :allow_nil => true,
                         :message => 'tylko "mężczyzna" albo "kobieta"'
  .
  .
  .
end

opis:
VALID_GENDERS -  jak zwykle wykorzystywanie stałych, aby później rozumieć co się pisało;
:allow_nil => true - bo użytkownik nie musi wypełniać pola "płeć";

Wykorzystanie zakresu jako ograniczenia

Ruby udostępnia przejrzysty w swej składni i bardzo prosty w użyciu system zakresów. Można go użyć w modelu na przykład do ograniczenia wprowadzanych dat. Wejdą wtedy tylko te akceptowane. Można to zrobić na przykład tak:

class User < ActiveRecord::Base
  YEAR_FROM = 1939
  VALID_DATES = DateTime.new(YEAR_FROM)..DateTime.now
  .
  .
  .
  validates_inclusion_of :birth_date,
                         :in => VALID_DATES,
                         :allow_nil => true,
                         :message => "jest nieprawidłowa"
  .
  .
  .
end

opis:
VALID_DATES - zakres dopuszczalnych dat
:allow_nil => true - bo użytkownik nie musi wypełniać daty

Więcej informacji w książce Hartla i Prohazki "RailsSpace".

Ciekawy artykuł - stronicowanie, sortowanie tabel w Ruby on Rails

Stronicowanie i sortowanie tabel to bardzo popularne zagadnienie w każdej aplikacji webowej, czyli również w Rails. Dodatkowo autor porusza problem wyszukiwania w tabelach.
Całość artykułu znajduje się pod adresem:
http://dev.nozav.org/rails_ajax_table.html

Jak w jQuery wywołać funkcję z parametrami

JQuery w bardzo wielu miejscach używa funkcji bezimiennej jako parametru.
Na przykład jeśli chcemy zareagować na zmianę w polu "#name":

jQuery("#name").change(function(){
  //tu jakieś operacje
});

Wszystko fajnie do momentu, gdy te wewnętrzne funkcje nie zaczynają się rozrastać i ciągnąć za sobą nowe funkcje. Kod staje się całkowicie nieczytelny i bałagan z każdą chwilą się pogłębia.
Częściowym rozwiązaniem jest osadzanie funkcji nazwanych jako parametru.
W poprzednim przykładzie funkcję bezimienną moglibyśmy zastąpić nazwaną, jak choćby:

function makeChanges() {
  //tu kod z funkcji nienazwanej
}

którą osadzamy w poprzednim przykładzie:

jQuery("#name").change(makeChanges);

Zwróć uwagę na brak nawiasów!

Taaa... wygląda nieźle.  Wygląda nieźle, ale tylko do momentu, w którym musimy użyć funkcji makeChanges() w jakimś innym miejscu kodu. Po to przecież ją wyekstrahowaliśmy (pamiętasz zasadę DRY?). Potrzebny wtedy jakiś parametr, a najczęściej dwa... albo i trzy.
Niestety coś takiego w sposób prosty nie zadziała:

jQuery("#name").change(makeChanges(paramOne, paramTwo));

Aby zadziałało funkcja makeChanges() musi zwrócić funkcję gdyż tego wymaga jQuery. Zróbmy więc tak:

function makeChanges(paramOne, paramTwo) {
  return function() { 
    // tu dopiero kod z funkcji nienazwanej
    // z wykorzystaniem parametru paramOne
    // i parametru paramTwo
  } 
}

Teraz działa!

Miłej zabawy :-)