To do czego WebSockets mają służyć idzie opisać jednym zdaniem:
” Strony internetowe za pomocą protokołu WebSockets mogą nawiązać DWUSTRONNE połączenie ze zdalnym serwerem.”

Do tej pory, komunikacja była jednostronna. Ze strony zostało wysyłane zapytanie i serwer zwracał odpowiedź. Wprowadzenie technologii AJAX zautomatyzowało trochę ten proces, uruchomiony w przeglądarce javascript automatycznie wysyłał zapytanie i obsługiwał nadesłaną odpowiedź. Mimo iż to przypomina dwustronną komunikację – nadal jest ona jednostronna.
Czasami takie zapytania są powtarzane w bardzo krótkich okresach czasu (20-30 sekund) – nazywa się to HeartBeating (bicie serca). Główny problem jednak pozostaje taki sam: generowane jest wiele zapytań, które serwer musi obsłużyć. Na szczęście AJAX pozwala na minimalizację pytania i aktualizację tylko części strony, a nie pobieranie całej strony co kilkadziesiąt sekund, jednak problem pozostaje problemem.

Wspomniany wyżej protokół rozwiązuje ten problem poprzez wykorzystanie komunikacji dwustronnej. Ma ty wyglądać w ten sposób, że przeglądarka nawiązuje połączenie ze zdalnym hostem, a gdy informacje na tym hoście się zmienią zostaną wysłane z powrotem do przeglądarki. Nie trzeba już odpytywać serwera o zmiany co kilkadziesiąt sekund.

Z punktu widzenia użytkownika nic się nie zmieni, jednak z punktu widzienia developera bardzo dużo: wydajność, prostota użycia to główne zalety tego rozwiązania.

Trochę bardziej techniczniej

Konstruktor otwieranego obiektu WebSocket posiada dwa elementy:
- pierwszym z nich jest URL z jaki należy się połączyć,
- drugi to protokół, który ma być użyty do komunikacji.

Jeżeli występują jakieś błędy, np. URL jest nieprawidłowy lub użyto w nim niedozwolonych znaków, port jest zablokowany, protokół nie obsługiwany to serwer zwróci błąd. W przeciwnym przypadku jest generowany nowy obiekt WebSocket.

Z obiektem tym komunikujemy się za pomocą poniższych metod:
- url – zwraca nam url połączenia użyty w konstruktorze,
- readyState – zwraca nam stan połączenia, który może przyjać jedną z poniższych wartości:
(wartości te są numeryczne, dodatkowo podaję ich tekstowy odpowiednik)
1 – CONNECTING – połączenie nie zostało jeszcze zrealizowane,
2 – OPEN – połączenie zostało zrealizowane i możliwa jest komunikacja z serwerem,
3 – CLOSING – połączenie jest w trakcie rozłączania,
4 – CLOSED – połączenie zostało zamknięte lub nie zostało otworzone.

W momencie utworzenia obiektu status musi być zmieniony na CONNECTING.

W celu przesłania danych używamy metody send(data). W rezultacie wywołania tej metody uzyskamy wartość boolean oznaczającą czy wysyłka była pomyślna czy nie.

Wysyłane dane, są bufforowane po stronie serwera. Wielkośc tego buffera można sprawdzić za pomocą metody bufferedAmount. Sprawdzanie tego bufera jest przydatne zwłaszcza przy wykorzystaniu połączeń asynchronicznych – gdzie jedno połączenie wysyła dane, a drugie pobiera obliczenia na podstawie tych danych. W przypadku, gdy zostanie wysłane zapytanie o rezultat a nie wszystkie dane zostaną już przesłane to rezultat ten może być błędny. Warto zatem opatrzeć tą metodę sprawdzeniem czy bufferedAmount jest równe 0 co oznacza że wszystkie dane są już wysłane.

WebSockets muszą także implementować kilka rodzajów zdarzeń na które muszą reagować:
Zdarzenia które występują to: open, close, message i error, natomiast metody nasłuchujące wystąpienia tych zdarzeń to :onopen, onclose, onmessage i onerror.

Resume

Jeżeli kogoś interesuje bardziej temat polecam wgłębienie się w API tego ciekawego protokołu, który IMO może przynieść kolejną rewolucję w internecie. Na dzień dzisiejszy jednak nie jest on do końca wspierany przez wszystkie przeglądarki. Pomimo, że Chrome, Safari i Firefox implementują go w mniejszej lub większej skali, to pozostaje jeszcze najpopularniejsza przegląrka – Internet Explorer, która nie implementuje tej funkcjonalności wogóle. Mam nadzieję, że to się zmieni.

Losowe Wpisy:

• 09.02.2009 -- Wzorce projektowe: Iterator
• 08.02.2009 -- Wzorce projektowe: Bridge
• 03.09.2010 -- Recenzja książki “Enterprise Rails”

Dobrym przykładem jest narzędzie Drush. Jest to narzędzie, które pozwala nam z konsoli zainstalować drupala, moduły do niego, łączyć się z bazą danych i w pewnym stopniu administrować witryną z poziomu konsoli. Możliwości jest wiele, polecam zatem do samodzielnego ich sprawdzenia.

Pierwszym krokiem, który musimy uczynić jest zainstalowanie drusha. Musimy go pobrać z tej strony, oraz rozpakować w dowolnym folderze. Następnie utworzyć link symboliczny do takiego miejsca, aby był w zasięgu zmiennej PATH.

# cd /opt/devel
# wget http://ftp.drupal.org/files/projects/drush-6.x-3.1.tar.gz
# tar -zxvf drush-6.x-3.1.tar.gz
# sudo ln -s /opt/devel/drush/drush /usr/local/bin/

Po wykonaniu powyższych czynności wykonując komendę ‘drush’ w dowolnym miejscu, powinniśmy otrzymać listę dostępnych komend.

Aby zainstalować drupala przechodzimy do folderu w którym chcemy to zrobić i wywołujemy komendę:

# drush dl drupal

Drupal zostanie pobrany ze strony i rozpakowany w bieżącym folderze. Instalacji dokonujemy w normalny sposób. Od wersji 7 Drupala będzie także możliwa instalacja z lini poleceń, jednak na dzień dzisiejszy najświeższa wersja to 6.17 więc musimy instalacji dokonać w tradycyjny sposób.

Po zainstalowaniu drupala, czas na kilka modułów. Za pomocą Drusha nie musimy szukać ich w witrynie drupala, tylko znając ich nazwy automatycznie pobrać i zainstalować. Dla przykładu gdy korzystamy z modułu “Views” wykonujemy komendy:

# drush dl views
# drush en views
> views was enabled successfully.

Gdy po dłuższej pracy na projektem drupal, lub niektóre używane moduły pojawią się w nowej wersji, wystarczy, że skorzytamy z komendy

# drush up

aby zaktualizować wszystko do najnowszych wersji.

Drush ma jeszcze więcej możliwości polecam zapoznać się z jego dokumentacją.

Podobne wpisy:

• 06.09.2010 -- RVM, gemset dla projektu
• 01.06.2010 -- To że Windows jest…

- inicjuje repozytorium Git, dodaje niektóre miejsca i pliki do ignore’a po czym zatwierdza resztę.

- instaluje platformę testową RSpec, RSpec-Rails, Cucumber, Factory_Girl i Webrat.

- instaluje authologic i declarative_authorization,

- tworzy model do dodawania artykułów oraz cruda do niego.

- tworzy model użytkownika, ról  i sesji

- tworzy widoki dla artykułów, panel logowania i edycja profilu.

- tworzy dwie początkowe role: user i admin.

- nadaje uprawnienia:

- gość może czytać artykuły, założyć konto i się zalogować,

- użytkownik może się wylogować, dodać artykuł, edytować lub usunąć własny artykuł, edytować swój profil,

- admin może wszystko.

Planuję jeszcze nad kilkoma dodatkami, ale nie wiem jeszcze dokładnie co i jak. Muszę to przemyśleć. Jak na razie szablon tworzy to, co w prawie każdej aplikacji istnieje. Modele można rozbudować wg własnych potrzeb ale mamy już dobry punkt początkowy.

Zapraszam do testowania i wyrażania swoich uwag.

Podobne wpisy:

• 12.12.2009 -- Automatyczny start czyli Rails Templates
• 16.07.2010 -- Pickle na Rails3
• 11.12.2009 -- Objęcie kontrolą wersji Git nowej aplikacji Rails

rails my_app -m ~/szablon_startowy.rb

tak samo jak URI, możemy uzywać URL:

rails my_app -m http://marioosh.5dots.pl/szablon.txt

(powyższy plik nie istnieje więc nie testujcie )
ostatnim sposobem jest inicjacja szablonu przed odpowiednie zadanie rake z ustawienie zmiennej LOCATION:

rake rails:template LOCATION=~/szablon_startowy.rb

Jakie operacje możemy wykonywać w przygotowanym języku DSL? Może zacznemy od przykładu.
Zacznijmy od wykonania kilku operacji opisanych w poprzednim artykule, mówiącym o wprowadzeniu aplikacji rails pod kontrolę Git.
Przygotujmy nasz plik szablonu, ja go utworzłem w katalogu domowym i zapisałem go jako 5dots_template.rb
Kroki które powinniśmy wykonać:
- inicjalizacja Git,
- utworzenie pliku .gitignore w folderach tmp i log
- dodaniu kilku wpisów w głównym .gitignore.
Plik powinien wyglądać tak:

# 5dots_szablon.rb
git :init
git :add => "."
# teraz dodajemy pliki .gitignore do folderów tmp i log.
run "touch tmp/.gitignore log/.gitignore"
#oraz tworzymy plik .gitignore w głównym folderze z zawartością:
file '.gitignore', <<-GITIGNORE_FILE
.DS_Store
log/*.log
tmp/**/*
config/database.yml
db/*.sqlite3
doc/app
doc/api
GITIGNORE_FILE
 
# teraz pozostaje tylko zatwierdzenie zmian do repozytorium:
git :commit => "-a -m 'Initial commit'"

W powyższym przykładnie poznaliśmy kilka komend języka DSL dla szablonów, wyjaśniam po kolei:
- git odpowiada za komendy systemu kontroli wersji git,
- run uruchamia polecenia konsolowe.

run "rm -rf *"

(komenda ta robi porządki w folderze )
- file – odpowiada za tworzenie plików i operacje na nich.

Mając podstawy za sobą możemy przejść do szczegółowego opisania wszystkich poleceń, w końcu te trzy powyższe, może i zrobią dużo, to i tak nie wszystko.

Polecenie rake

Za wykonywanie zadań rake jest odpowiedzialna komenda o tej samej nazwie ,dodatkowo możemy uruchomić skrypt jako superużytkownik, wtedy musimy podać parametr :sudo => true. Dodatkowo możemy podać parametry, których możemy używać podczas ręcznego użycia komendy rake.

rake "gem:install"
# lub jako superuser
rake "gem:install", :sudo => true
# jeszcze jeden przykład:
rake "gem:install", :env => 'production'

Operacje na gemach

Komenda gem odpowiada za dodawanie gemów. Komenda dodaje odpowiedni wpis do pliku config/envoirnment.rb. Parametry, które mają być również dopisane (takie jak :version, :lib, :source) podajemy na końcu.
Komenda nie istaluje gema, do tego celu musimy użyć odpowiedniego zadania rake (zgadnijcie którego )
Kilka przykładów:

gem 'thoughtbot-factory_girl', :lib => 'factory_girl', :source => 'http://gems.github.com'
gem "hpricot", :version => '0.6', :source => "http://code.whytheluckystiff.net"
gem "RedCloth"

Instalowanie wtyczek (inaczej zwanymi pluginami)

Aby zainstalować pluginy używamy z komendy plugin(mam wrażenie, że się domyślaliście – ot taki prosty ten język, wszystko jest domyślnie proste)
Pluginy możemy instalować z svn, z gita lub z gita jako submoduły:

# instalowanie ze starego dobrego subversion:
plugin 'svnowy_plugin', :svn => 'svn://repozytorium/scieżka_do_plugina/trunk'
# albo z nowego, jeszcze lepszego gita:
plugin 'git_plugin', :git => 'git://github.com/scieżka_do_plugina.git'
# lub nawet jako submoduł gitowy (o tym będzie w następnym artykule)
plugin 'git_plugin', :git => 'git://github.com/scieżka_do_plugina.git', :submodule => true

Inicjalizery- czyli automatory, wewnątrz automatora

Jeżeli korzystamy z inicjalizerów, czyli skryptów, które są uruchamiane podczas startu aplikacji używamy komendy initialize. Właśnie ona, tworzy plik w folderze cofnig/initializers

initialize "nowy_object.rb", <<NOWY_OBJECT_CONTENT
class Object
    def nowa_metoda
        puts "Fajna ta nowa metoda, dobrze, że mogę z niej korzystać, zanim railsy się odpalą! ";
    end
end
NOWY_OBJECT_CONTENT

Dokładnie na tej samej zasadzie działają komendy lib i vendor, które tworzą pliki w folderach (odpowiednio) /lib i /vendor.

Pliki

Tworzenie nowych plików tworzymy na podobnej zasadzie jak poprzednia metoda, główną różnicą jest, że plik zostanie utworzony, wg folderu RAILS_ROOT a nie wewnątrz initailizers.

file "app/components/Klasa.rb", <<KLASA
class Klasa
end
KLASA

Komenda powyższa utworzy foldery app/components i umieści w nim plik Klasa.rb.

Zadania Rake

Komenda rakefile tworzy plik w folderze /lib/tasks

rakefile "clear_all.rake" do
    namespace :clear do
        task :all do
            puts "Usuwamy wszystko!!!!! "
        end
    end
end

Teraz to zadanie możemy uruchomić po wydaniu komendy: rake clear:all.

Generatory

Generatory możemy uruchomić komendą generate i podając listę argumentów. Możemy uzywać wszystkie generatory, które są standardowo w railsach, lub które uprzednio zainstalowaliśmy w formie pluginów lub gemów.

generate(:scaffold, "person", "name:string", "email:string", "password:string"
generate("rspec")

Uruchamianie skryptów powłoki

Jak już wspomniałem można tego dokonać za pomocą komendy run

run "rm -rf *"

Dodawanie rutingów

Jeżeli potrzebujemy dodatkowych wpisów w pliku /config/routes.rb wykonujemy je uruchamiając komendę route

route "map.root :controller => :person"

Zmiana folderu

Czasami wygodne jest przejście do innego folderu i w nim wykonanie kilku operacji, możemy to zrobić za pomocą komendy inside. Jako parametr podajemy folder docelowy i potem block.

inside "config" do
    run "cp database.yml database.orig.yml"
# linkowanie ustawień z innego projektu, bo oba mają działać na tej samej bazie
    run "ln -s /projekty/super_rails_app/config/database.yml database.yml"
end

Działanie zależne od odpowiedzi

Podczas wykonywania skryptu, możemy wprowadzić małą intekerakcję, np. zadać pytanie i zależnie od odpowiedzi wykonać dalej skrypt.
Na przykład możemy zapytać o nazwę pliku. W tym celu wykonujemy komendę ask.
W poniższym przykładzie pytamy sie o nazwę pliku dla pliku konfiguracji .yml. Skrypt również sprawdza, czy rozszerzenie zostało podane czy nie. jeżeli nie, to dodaje je do nazwy pliku.

file_name = ask("Podaj nazwę pliku konfiguracyjnego")
file_name << ".yml" unless file_name.index(".yml")
 
file "/config/" << filename, <<FILE_CONTENT
global_settings:
    color: #e343f3
    font-size: 14px
FILE_CONTENT

Istnieją również uproszczone wersje powyższej metody, jedna oczekuje na odpowiedź “yes” druga na “no”

gem "RedCloth" if yes?("Zainstalować gem Red Cloth?")
 
if no?("Zainstalować gem Blue Cloth?") 
    gem ask("Podaj nazwę gemu z edytorem, którym ma być użyty zamiast BlueCloth:")
else
    gem "BlueCloth"
end
# po wpisaniu 'no' zostanie uruchomione zapytanie o nazwe gem'a, w każdej innej sytuacji zostanie dodany BlueCloth

GIT – kochaj albo rzuć

Komenda git wykonduje komendy systemu kontroli wersji Git – jak nie trudno się domyśleć.

git :init
git :add => "."
git :commit => "-a -m 'Initial commit'"
git :submodule => "init"

Rezume

Lista komend do wykorzystania:

 
gem(nazwa, options={})
plugin(nazwa, options={})
initializer(nazwa_pliku, data=nil, &block)
lib(nazwa_pliku, data=nil, &block)
vendor(nazwa_pliku, data=nil, &block)
rakefile(nawa_pliku, data=nil, &block)
generate(co_generować, argumenty)
run(komenda)
rake(komenda, options={})
route(routing_code)
inside(folder)
ask(pytanie)
yes?(pytanie)
no?(pytanie)
git(parametry)

Teraz znająć już wszystkie komendy, możemy tworzyć własne szablone jako startowe ustawienia aplikacji. Jeżeli stworzymy coś nowego i fajnego warto się tym podzielić. Moża dodać je do projektu: Rails Templates, który takie szablony zbiera. Możemy również skorzystać z instniejących tam szablonów.

Podobne wpisy:

• 05.03.2010 -- Rails Template
• 16.07.2010 -- Pickle na Rails3
• 11.12.2009 -- Objęcie kontrolą wersji Git nowej aplikacji Rails

W sumie nic dziwnego, języki rozwijają się, dołączone do nich biblioteki rosną w postępie logarytmicznym. Poza tym znajomość języka to raz, a znajomość konkretnego frameworka to dwa. Dając ogłoszenie o programisty JSF jakoby normalny staje się fakt, że potrafi on Javę samą w sobie.

Można by było przypuszczać, że obecny trend zmierza do jeszcze większej specjalizacji. Jednak tak nie jest. Znajomość frameworka czy narzędzia nadal pojawia się w ogłoszeniach. Jednak oprócz nich pojawiają się wymagania dotyczących technologii nie związanych bezpośrednio z językiem, np. AJAX. Przecież możemy wykorzystywać go zarówno w aplikacjach javowych, php-owych, rails-owych czy też innych. Poniżej przedstawiam listę nowych wymagań stwianych w ofertach pracy. Wg mnie technologie te staną się w ciągu kilku najbliższych lat bardzo ważne, więc zapoznanie się znimi już dziś może nam ułatwić poszukiwania pracy.

1. Widgety, Gadgety

Wiele stron i mechanizmów umożliwia wykorzsytywanie tych mini aplikacji. Widgety to jakby aplikacje wewnątrz innych aplikacji, które potrafią żyć własnym cyklem nie ingerując w mechanikę strony. Za to dodają witrynie wiele nowych finkcjonalności, których napisanie zajęłoby nam sporo czasu.

2. Integracja z serwisami społecznościowymi

Serwisy społecznościowe rosną jak grzyby po deszczu. Jedne bardziej popularne drugie mniej. Jedne oferują więcej usług i możliwości inne odwrotnie. W każdym razie już coraz mniej witryn można spotkać, które nie mają chociaż jednej malutkiej integracji z takim portalem społecznościowy. Wiele takich integracji z resztą polega na dodaniu do strony widgetu wspomnianego w punkcie pierwszym. Przeglądając witrynę spójrzmy, czy nie ma tam linka do takich serwisów jak Twitter, Blip, Flakier, Wykop, Dig-it, delicious czy też innych.

3. SEO

SEO jest ważnym elementem pozycjonowania strony więc wiedza na ten temat jest coraz bardziej wymagana.

4. Aplikacje mobilne IPhone & Android

iPhone zrewolucjonizował rynek telefonów, uczynił rewolucję, która podłączyła wielu użytkowników do internetu. Przeglądamy strony jadąc tramwajem, słuchamy radia internetowego, czy też gramy w gry online. Oferty pracy dla programistów iPhone’a czy Androida pojawiają się coraz częściej. Moim zdaniem Android będzie się rozwijał szybciej bo nie jest blokowany jak to ma się z telefonem od Apple.Dostęp do tej technologi jest łatwiejszy, więc rynek będzie szedł w tą stronę.

Losowe Wpisy:

• 06.07.2010 -- Jak powinna wyglądać dobra historyjka użytkownika?
• 25.08.2010 -- Vim – tryb rozszerzony (ex)
• 25.08.2010 -- Vim – przesuwanie w zakresie okna

Wygląd wytryny wordpress.org

Jak obiecałem w poprzednim artykule pokażę jak praktycznie można wykorzystać framework 960gs. Do tego celu będę się wzorował na layoucie witryny wordpress.org .

Spójrzmy jak rozkłada się layout witryny wordpress.org. Gdy nałożymy na nią siatkę (użyłem modelu 12 kolumnowego) przygotowaną przez twórców systemu 960gs to otrzymamy coś takiego:

Nałożona siatka na layout

Patrząc teraz widzimy jak poszczególne elementy nakładają się z kolumnami systemu 960gs. Wystarczy jest teraz dokładnie zdefinionwać i okreslic ich szerokość.

Zobaczmy:

Podział layout na elementy

Teraz widać wyraźnie poszczególne elementy. Cały layout dzieli się na 5 poziomych sekcji – header składający się z logo (1) pola wyszukiwania (2) oraz menu górnego (3).
Następna sekcja to treść podzielona na dwie równe części (4 i 5), od razu pod nim znajduje się obszar komunikatów zajmujący całą szerokość (6). Kolejna sekcja została symetrycznie podzielona na cztery części – z przeznaczeniem na ogłoszenia i komunikaty (elementy 7 – 10). Na samym dole znajdujemy footer, który podzielony został na dwie części – po lewej: standardowy footer (10), po prawej: widoczny jest slogan witryny (11).

Sprawdźmy teraz jak można zreplikować ten layout za pomocą systemu 960gs. Na początku zajmiemy się headerem. Zauważmy, że elementy 2 i 3 są jeden po drugim i nie są tej samej szerokości. Musimy je zgupować razem w jednym elemencie i umieścić w tym samym rzędzie co logo.

Rozpoczynamy od zdefiniowania kontenera 12-to kolumnowego:

 ...
<div class="container_12">
 
</div>
...

Teraz czas na header:

  ...
<div id="logo" class="grid_4">LOGO</div>
<div class="grid_8">
  <div class="prefix_5 grid_3 alpha omega">
    <div id="search"> SEARCH</div>
  </div>
  <div id="menu" class="grid_8 alpha omega"> MENU</div>
</div>
...

Następnie dodajemy drugi wiersz zawierający dwie kolumny:

 ...
<div class="grid_6">CONTENT 1</div>
<div class="grid_6">CONTENT 2</div>
...

Obszar powiadomień:

  ...
<div id="messages" class="grid_12">MESSAGES</div>
...

i reszta:

  ...
<div class="grid_2">CONTENT 2 a</div>
<div class="grid_4">CONTENT 2 b</div>
<div class="grid_4">CONTENT 2 c</div>
<div class="grid_2">CONTENT 2 d</div>
 
<div id="footer" class="grid_10">FOOTER</div>
<div id="footerlogo" class="grid_2">Footer logo</div>
...

Gotowe, a tak wygląda to co zrobiliśmy:

Czyż nie podobny to tego z wordpress.org?

Oczywiście system 960gs nie rozwiąże wszytkich naszych problemów związanych z przygotowaniem layoutu, ale na pewno nam to ułatwi. Nie musimy się martwić jak on będzie wyglądał w danej przeglądarce bo w każdej z nowych witryna będzie wyglądała tak samo.

Pobierz gotowy plik

Podobne wpisy:

• 02.12.2008 -- 960 grid system

Czym jest 960 grid system?

960gs jest prostym szablonem CSS wykorzystywanym do tworzenia layoutów. Zaprojektowano go w tym celu, aby pomagał w projektowaniu układu kolumnowego. Szablon opiera sie na szerokości 960px – stąd nazwa. Dlaczego akurat 960px? Z dwóch powodów. Pierwszym z nich jest to, że zgodnie ze satystykami W3C naczęściej używaną rozdzielczością przy przeglądaniu stron internetowych jest 1024X768px. Mając to na uwadze projektanci budują tak strony aby ich szerokość nie była większa niż 1024px. Ale dlaczego akurat 960? a nie np. 980 albo 1000? Otóż 960 jest podzielne przez liczby: 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40, 48, 60, 64, 80, 96, 120, 160, 192, 240, 320 i 480. Daje to bardzo duże pole do popisu w dostosowywaniu szerokości.

Zasada działanie systemu 960 jest banalnie prosta. Projekt jest dzielony na równe kolumny i każdy element na stronie jest dostosowany do odpowiedniej ilości kolumn we wierszu. 960Gs wspiera dwa układy: 12 kolumn oraz 16 kolumn.

W pierwszym z nich kolumna ma szerokość 60px w drugim 40px. Marginesy są równe 10px po obu stronach co daje nam razem 20px na kolumnę. Warto zerknąć na stronę demo gdzie pokazane są różne możliwe układy. Oczywiście nie są przedstawione wszystkie możliwości, ale jest ich dość aby zobaczyć ogólną zasadę działania.

Co w paczce?

System 960gs możemy pobrać tutaj. W środku otrzymujemy pliki css składające się na system (960.css, reset.css oraz text.css) w wersji skompresowanej jak i nie. Plik 960.css jest esencją systemu. W nim znajdują sie deklaracje wyglądu kolumn. Plik reset.css zeruje wszystkie podstawowe tagi html. Plik text.css jest przykładowym dodatkowym szablonem który nadaje wielkość i wygląd czcionek w pragrafach i nagłówkach. Jest to plik opcjonalny i nie musimy z niego korzystać.

Obok plików CSS w paczce znajdują się sketch_sheets w formie pliku PDF. Są to gotowe szablony gotowe do wydrukowania – można je wykorzystać przy projektowaniu szablonu za pomocą ołówka na kartce.

W paczce także możemy znaleźć gotowe szablony do programów graficznych które wykorzystujemy jako plik bazowy do projektowania layoutu.

Jak to działa?

Pierwszym krokiem jest wybranie wariantu zgodnie, z którym będziemy budować nasz layout. mamy do wyboru 12 lub 16 kolumn.

Tworzymy div z klasą container_12 (albo container_16), w którym umieścymy całą naszą treść.
Dalsze projektowanie polega na tym, że układamy elementy we wierszach, gdzie zwracamy uwagę na to ile kolumn poszczególny element zajmuje. Pamiętać należy że każdy wiersz powinien mieć zdefinione co w której kolumnie się znajduje i nie można zapomnieć o żadnej z nich. Błędem jest np. zdefinowanie dwóch elementów po 5 kolumn (dających razem 10) w układzie 12-to kolumnowych. Dwie brakujące kolumny mogą (aczkowlkiek nie muszą) narobić potem zamieszania. Szerokość elementów określa się bardzo łatwo. Nadaje się klasę grid_xx gdzie xx – określa ilość kolumn które element ma zająć. Dla przykładu:

<div class="container_12"> <!-- wybieramy wielkość 12 kolumn -->
<div class="grid_3"> menu left</div>
<div class="grid_6"> content</div>
<div class="grid_3"> menu right</div>
<!-- koniec wiersza --></div>
<!-- koniec głównego div'a -->

W przykładzie widzimy, że nasz wiersz został podzielony na trzy sekcje prawa i lewa po 3 kolumny, oraz środkowy element 6 kolumn.

Co jednak gdy będziemy chcieli zostawić puste miejsca w układzie? Używamy wtedy w elemencie dodatkowo klasy prefix_x lub suffix_x. Klasy te tworzą puste przestrzenie przed (gdy użyjemy prefix) lub po (suffix>) wybranym elemencie. “x” oznacza ilość kolumn pustego miejsca.

<div class="container_12"> <!-- wybieramy wielkość 12 kolumn -->
<div class="grid_2 prefix_1"> menu left</div>
<div class="grid_6"> content</div>
<div class="grid_2 suffix_1"> menu right</div>
<!-- koniec wiersza --></div>
<!-- koniec głównego div'a -->

W tym przykładzie tworzymy podobny układ do poprzedniego, z tym, że lewy i prawy element mają szerokość 2 kolumn, content – jak poprzednio 6, a z lewej i prawej strony są marginesy szerokości 1 kolumny.

W powyższych przykładach można zauważyć, że w każdym wierszu ostatni div posiada klasę clear. Kolumny są rozmieszczane jako opływające (’float’) i nadanie takiego atrybutu pozwoli “złamać wiersz”. Korzystanie z tej klasy jest zalecane aby zachować dobry układ.
Nie jest wymagane korzystanie z tag’u div. Można używać także tagu: span.
Istnieje także możliwość wpisywania elementów wewnątrz innych elementów. Nic nie stoi na przeszkodzie na stworzenie takiego kodu:

<div class="container_12">
<!-- wybieramy wielkość 12 kolumn -->
<div class="grid_3"> menu left</div>
<div class="grid_6">
<div class="grid_3 suffix_1"> content</div>
<div class="grid_2"> image</div>
</div>
<div class="grid_3"> menu right</div>
<!-- koniec wiersza --></div>
<!-- koniec głównego div'a -->

Niestety nie jest on do końca poprawny. Pamiętajmy, że każda kolumna ma margines 10px z lewej i prawej storny. W sytuacji jak powyższa, gdy dwa elementy umieszczamy bezpośrednio w drugim elemencie zajdzie sytuacja że marginesy lewy i prawy będą miały wartość 20px. (10px margines elementu nadrzędnego i 10px elementu potomnego). Gdy będziemy chcieli nasz layout zagłębić jeszcze poziom w dół to nasz margines wyniesie jeszcze więcej. Rozwiązaniem w takich sytuacjach jest użycie klas alpha i omega, które ustawiają margines na 0. alpha zeruje lewy margines, omega zaś prawy.
Poprawnym, więc zapisem będzie:

<div class="container_12">
<!-- wybieramy wielkość 12 kolumn -->
<div class="grid_3"> menu left</div>
<div class="grid_6">
<div class="grid_3 suffix_1 alpha"> content</div>
<div class="grid_2 omega"> image</div>
</div>
<div class="grid_3"> menu right</div>
<!-- koniec wiersza --></div>
<!-- koniec głównego div'a -->

Reasumując:
Projektując nasz layout z wykorzystaniem 960gs wykorzystujemy klasy:

container_12
container_16
grid_xx
prefix_xx
suffix_xx
alpha
omega
clear

W następnym artykule pokażę praktyczne zastosowanie frameworku 960gs.

Podobne wpisy:

• 05.12.2008 -- 960gs – praktyczne zastosowanie