diff --git a/02-getting-started.md.erb b/02-getting-started.md.erb index 98d43ea..00369f6 100644 --- a/02-getting-started.md.erb +++ b/02-getting-started.md.erb @@ -25,7 +25,7 @@ Jeżeli nie możesz (albo nie chcesz) instalować Meteor'a lokalnie, polecamy sp Nitrous.io to serwis pozwalający Ci uruchamiać aplikacje i edytować ich kod w twojej przeglądarce, napisaliśmy [krótki poradnik](https://www.discovermeteor.com/2013/10/04/meteor-nitrous/) aby pomóc ci w konfiguracji. -Możesz także wykonwać tę instrukcję aż do sekcji "Instalacja Meteor'a i Meteorite" (włącznie), i następnie przejść przez książkę ponownie rozpoczynając od sekcji "Tworzenie prostej aplikacji" z tego rozdziału. +Możesz także wykonać tę instrukcję aż do sekcji "Instalacja Meteor'a i Meteorite" (włącznie), i następnie przejść przez książkę ponownie rozpoczynając od sekcji "Tworzenie prostej aplikacji" z tego rozdziału. <% end %> @@ -42,7 +42,7 @@ Musisz się upewnić że node i git są zainstalowane na twoim komputerze. Zains - [strona do pobrania Node](http://nodejs.org/download/) - [strona do pobrania Git](http://git-scm.com/downloads) -Następnie, zainstalujmy Meteorite. Jest to pakiet [npm](https://npmjs.org/) (ang Node Package Module, standarowy format modułów Node'a), instalujemy go za pomocą: +Następnie, zainstalujmy Meteorite. Jest to pakiet [npm](https://npmjs.org/) (ang Node Package Module, standardowy format modułów Node'a), instalujemy go za pomocą: ~~~bash $ npm install -g meteorite @@ -50,7 +50,7 @@ $ npm install -g meteorite <% note do %> -### Błedy uprawnień? +### Błędy uprawnień? Na niektórych komputerach możesz potrzebować uprawnień root'a aby zainstalować Meteorite. Aby uniknąć problemów, upewnij się że używasz `sudo -H`: @@ -70,7 +70,7 @@ Notka: nie ma jeszcze obsługie Meteorite dla Windows, ale możesz spojrzeć na ### `mrt` vs `meteor` -Meteorite zainstaluje komendę `mrt`, którą będziemy używać do isntalacji pakietów dla naszej aplikacji. Jednakże kiedy chcemy uruchomić nasz serwer, nadal używamy komendy `meteor`. +Meteorite zainstaluje komendę `mrt`, którą będziemy używać do instalacji pakietów dla naszej aplikacji. Jednakże kiedy chcemy uruchomić nasz serwer, nadal używamy komendy `meteor`. <% end %> @@ -100,7 +100,7 @@ $ cd microscope $ meteor ~~~ -Teraz wpisz w swojeje przeglądarce adres `http://localhost:3000/` (lub odpowiednik `http://0.0.0.0:3000/`) i powinieneś zobaczyć mniej więcej coś takiego: +Teraz wpisz w swojej przeglądarce adres `http://localhost:3000/` (lub odpowiednik `http://0.0.0.0:3000/`) i powinieneś zobaczyć mniej więcej coś takiego: <%= screenshot "2-1", "Meteor's Hello World." %> @@ -111,7 +111,7 @@ Gratulacje! Twoja pierwsza aplikacja w Meteor'ze działa. Przy okazji, aby ją z ### Dodawanie pakietu -Użyejmy teraz Meteorite, aby dodać smart package, który pozwoli na dołączenie =[Bootstrap](http://getbootstrap.com/) do projektu: +Użyjemy teraz Meteorite, aby dodać smart package, który pozwoli na dołączenie =[Bootstrap](http://getbootstrap.com/) do projektu: ~~~bash $ mrt add bootstrap @@ -125,9 +125,9 @@ $ mrt add bootstrap Kiedy mówimy o pakietach w kontekście Meteor'a, warto pomówić o szczegółach. Meteor używa pięciu typów pakietów: -- Rdzeń Meteor'a jako takie jest podzielone na **rdzenne pakiety**. Są one zawarte w każdej aplikacji Meteor'a i pradopobonie nigdy nie będziesz musiał się o nie martwić. +- Rdzeń Meteor'a jako takie jest podzielone na **rdzenne pakiety**. Są one zawarte w każdej aplikacji Meteor'a i prawdopodobnie nigdy nie będziesz musiał się o nie martwić. - Meteor **pakiety smart** (ang. smart packages) są grupą [około 37 pakietów](http://docs.meteor.com/#packages) (możesz zobaczyć całą listę za pomocą `meteor list`), które są dostarczane razem z Meteor'em i możesz je opcjonalnie zaimportować do swojej aplikacji. Możesz dodać je nawet, gdy nie używasz Meteorite, za pomocą `meteor add packagename`. -- **Pakiety lokalne** to pakeity które możesz swtorzyć sam i włożyć je do katalogu `/packages`. Także nie potrzebujesz Meteorite by z nich korzystać. +- **Pakiety lokalne** to pakiety które możesz stworzyć sam i włożyć je do katalogu `/packages`. Także nie potrzebujesz Meteorite by z nich korzystać. - **pakiety smart Atmosphere** to pakiety do Meteor'a trzecich firmy znajdujące się na [Atmosphere](http://atmosphere.meteor.com). By je importować i używać potrzebny jest Meteorite. - **pakiety NPM** (Node Packaged Modules) to pakiety Node.js. Mimo, iż nie współpracują one od razu z Meteorem w stanie w jakim są dostarczane, *mogą* być używane przez wyżej wymienione typy pakietów. @@ -158,7 +158,7 @@ Jeżeli chcesz poznać więcej szczegółów, zachęcamy by zapoznać się z [of Jeżeli używałeś wcześniej innych frameworków, takich jak Ruby on Rails, możesz się zastanawiać czy Meteor zaadoptował wzorzec MVC -Krótka odpowiedź to: nie. W przeciwieństwie do Rails'ów, Meteor nie narzuca żadnej predefiniowanej struktury dla Twojej aplikacji. Także w tej książce poprostu układamy kod w sposób, który ma dla nas największy sens, nie martwiąc się przy tym za bardzo o akronimy. +Krótka odpowiedź to: nie. W przeciwieństwie do Rails'ów, Meteor nie narzuca żadnej predefiniowanej struktury dla Twojej aplikacji. Także w tej książce po prostu układamy kod w sposób, który ma dla nas największy sens, nie martwiąc się przy tym za bardzo o akronimy. <% end %> @@ -166,11 +166,11 @@ Krótka odpowiedź to: nie. W przeciwieństwie do Rails'ów, Meteor nie narzuca Ok, skłamaliśmy. Nie potrzebujemy katalogu `public/` z tego prostego powodu że Microscope nie potrzebuje żadnych statycznych zasobów. Ale odkąd większość aplikacji napisanych w Meteor'ze zawiera co najmniej kilka obrazków, uznaliśmy że warto poruszyć ten temat. -Przy okazji, mogłeś już zauważyć ukryty katalog `.meteor`. To jest miejsce w którym Meteor przechowuje swój własny kod - modyfikacja rzeczy znajdujących się tam to zazwyczaj bardzo zły pomysł. Prawdę ówiąc nie potrzebujesz nigdy zaglądać do tego katalogu. Jedynym wyjątkiem są pliki `.meteor/packages` and `.meteor/release`, które odpowiednio są używane do wylistowania twoich pakietów i wersji Meteor'a którą używasz. Kiedy dodajesz pakiet albo zmieniasz wersję Meteor'a, może być pomocne sprawdzenie zmian w tych plikach. +Przy okazji, mogłeś już zauważyć ukryty katalog `.meteor`. To jest miejsce w którym Meteor przechowuje swój własny kod - modyfikacja rzeczy znajdujących się tam to zazwyczaj bardzo zły pomysł. Prawdę mówiąc nie potrzebujesz nigdy zaglądać do tego katalogu. Jedynym wyjątkiem są pliki `.meteor/packages` and `.meteor/release`, które odpowiednio są używane do wylistowania twoich pakietów i wersji Meteor'a którą używasz. Kiedy dodajesz pakiet albo zmieniasz wersję Meteor'a, może być pomocne sprawdzenie zmian w tych plikach. <% note do %> -### Podkreślenia vs CamelCase +### Podkreślenia vs. CamelCase Jedyne co mamy do powiedzenia na temat debaty pomiędzy podkreśleniami (`my_variable`) kontra camelCase (`myVariable`) jest to że naprawdę nie ma znaczenia którą konwencję przyjmiesz, jeżeli tylko się do niej konsekwentnie stosujesz. @@ -182,7 +182,7 @@ Jedynym wyjątkiem do tej reguły są nazwy plików, które będą używały pod ### Zatroszcz się o CSS -To nie jest książka o CSS. Aby nie zwalniać zajmując się szczegółami styli, zdecydowaliśmy zrobić cały zestaw styli dostępny od początku, tak żebyś nie musiał się nim przejmować od początku. +To nie jest książka o CSS. Aby nie zwalniać zajmując się szczegółami stylów, zdecydowaliśmy zrobić cały zestaw stylów dostępnych od początku, tak żebyś nie musiał się nim przejmować od początku. CSS automatycznie jest zminimalizowany i załadowany przez Meteor'a, i w odróżnieniu do innych statycznych zasobów idzie do katalogu `/client`, a nie `/public`, także włóż do pliku `style.css`: diff --git a/02s-deploying.md.erb b/02s-deploying.md.erb index ae0ba60..90a2f5b 100644 --- a/02s-deploying.md.erb +++ b/02s-deploying.md.erb @@ -20,7 +20,7 @@ Nauczymy się jak opublikować aplikację Meteora na kilka różnych sposobów. Jest to rozdział poświęcony **Sidebars**. Bardziej szczegółowo jest opisany w dalszej części książki. -Jeżeli wolisz kontynuwać pracę nad Microscope, możesz przeskoczyć ten rozdział i wrócić do niego w dowolnym momencie. +Jeżeli wolisz kontynuować pracę nad Microscope, możesz przeskoczyć ten rozdział i wrócić do niego w dowolnym momencie. <% end %> @@ -88,7 +88,7 @@ Właśnie opublikowaliśmy aplikację na serwerach Modulusa. Aby uzyskać więce Mimo tego, że nowe firmy hostingowe pojawiają się jak grzyby po deszczu, często napotkasz problemy związane z konkretnym hostingiem i jego ograniczeniami. Na dzień dzisiejszy publikacja aplikacji na własnym serwerze jest najlepszym sposobem na umieszczenie aplikacji Meteora w internecie. Jedyną przeszkodą może być to, że publikacja na własnym serwerze nie jest prosta, szczególnie gdy szukasz środowiska produkcyjnego o wysokiej jakości. -[Meteor Up](https://github.com/arunoda/meteor-up) (lub w skrócie `mup`) jest kolejną próbą poradzenia sobie z tym problemem. Jest to narzędzie konsolowe, które zajmuje się ustawieniem i publikacją aplikacji za ciebie. Zobaczmy zatem jak apublikować Microscope używając Meteor Up. +[Meteor Up](https://github.com/arunoda/meteor-up) (lub w skrócie `mup`) jest kolejną próbą poradzenia sobie z tym problemem. Jest to narzędzie konsolowe, które zajmuje się ustawieniem i publikacją aplikacji za ciebie. Zobaczmy zatem jak opublikować Microscope używając Meteor Up. Zanim będziemy mogli kontynuować, potrzebujemy serwer na który możemy opublikować aplikację. Polecamy [Digital Ocean](http://digitalocean.com), gdzie hosting zaczyna się od 5$ miesięcznie lub [AWS](http://aws.amazon.com/), który ma darmowe instancje Micro (szybko napotkasz problemy związane ze skalowaniem aplikacji, ale jeżeli chcesz się pobawić, na początek powinno wystarczyć). @@ -116,7 +116,7 @@ $ mup init <% note do %> -### Wspóldzielenie ustawień za pomocą Dropbox +### Współdzielenie ustawień za pomocą Dropbox Świetnym sposobem na współdzielenie ustawień przez Ciebie i cały Twój zespół jest stworzenie folderu z konfiguracjami w twoim DropBoxie lub podobnym serwisie. @@ -155,7 +155,7 @@ Następnym krokiem jest konfiguracja pliku `mup.json`. Poniżej znajdziesz domy ~~~ <%= caption "mup.json" %> -Zapoznajmu się po kolei z każdym z ustawień. +Zapoznajmy się po kolei z każdym z ustawień. **Server Authentication** @@ -171,7 +171,7 @@ Jeżeli zdecydowałeś się użyć MongoHQ, ustaw pole `setupMongo` na `false` i **Ścieżka Aplikacji Meteora** -Ponieważ nasza konfiguracja Meteor Up jest umieszczona w innym folerze, musimy wskazać Meteorowi z powrotem na naszą aplikację używając pola `app`. Wpisz lokalną ścieżkę, którą możesz otrzymać po wpisaniu `pwd` w konsoli w głównym folderze danej aplikacji. +Ponieważ nasza konfiguracja Meteor Up jest umieszczona w innym folderze, musimy wskazać Meteorowi z powrotem na naszą aplikację używając pola `app`. Wpisz lokalną ścieżkę, którą możesz otrzymać po wpisaniu `pwd` w konsoli w głównym folderze danej aplikacji. **Zmienne Środowiskowe** @@ -179,7 +179,7 @@ Możesz określić wszystkie zmienne środowiskowe aplikacji (takie jak `ROOT_UR ### Ustawienia i publikacja aplikacji -Zanim będziemy mogli opublikować aplikację, musimy przygotować serwer, aby był gotowy na hosting aplikacji Meteora. Na szczęście ten skomplikowany proces został uproszczony do zawołania pojedyńczej komendy! +Zanim będziemy mogli opublikować aplikację, musimy przygotować serwer, aby był gotowy na hosting aplikacji Meteora. Na szczęście ten skomplikowany proces został uproszczony do zawołania pojedynczej komendy! ~~~bash $ mup setup diff --git a/03-templates.md.erb b/03-templates.md.erb index 31e0937..283ba85 100644 --- a/03-templates.md.erb +++ b/03-templates.md.erb @@ -44,9 +44,9 @@ Stwórzmy folder `/views` w folderze `/client`. Będzie to miejsce wstawienia ws ### Znajdowanie plików -Meteor doskonale radzi sobie ze znajdowaniem plików. Nieważne gdzie wstawisz kod w folderz `/client`, Meteor go znajdzie i odpowiednio skompiluje. Oznacza to, że nigdy nie będziesz musiał wstawiał ścieżek 'include' do plików JavaScript czy CSS. +Meteor doskonale radzi sobie ze znajdowaniem plików. Nieważne gdzie wstawisz kod w folderze `/client`, Meteor go znajdzie i odpowiednio skompiluje. Oznacza to, że nigdy nie będziesz musiał wstawiał ścieżek 'include' do plików JavaScript czy CSS. -Oznacza to również, że mógłbyś równie dobrze wstawić wszystkie pliki w jeden folder, czy nawet cały kod w jeden plik. Ponieważ Meteor i tak skompiluje wszystko w jeden pojedyńczy skompresowany plik, chcielibyśmy raczej trzymać porządek i dobrze zorganizować strukturę plików. +Oznacza to również, że mógłbyś równie dobrze wstawić wszystkie pliki w jeden folder, czy nawet cały kod w jeden plik. Ponieważ Meteor i tak skompiluje wszystko w jeden pojedynczy skompresowany plik, chcielibyśmy raczej trzymać porządek i dobrze zorganizować strukturę plików. <% end %> @@ -118,9 +118,9 @@ Mówiąc inaczej, rola szablonów jest ograniczona do wyświetlania lub iterowan Gdy zapytaliśmy programistów, jakie nazwy nadają managerom szablonu, połowa nazwała je "kontrolery", a druga połowa "te pliki, w których umieszczam kod JavaScript". -Manager nie jest tak naprawdę kontrolerem (przynajmniej w sensie kontrolera MVC) a termin "TFWIPMJSC" (przyp. tlum. ang. akronim od 'te pliki,...') nie dawał się łatwo zapamiętać, więc odrzuciliśmy obie propozycje. +Manager nie jest tak naprawdę kontrolerem (przynajmniej w sensie kontrolera MVC) a termin "TFWIPMJSC" (przyp. tłum. ang. akronim od 'te pliki,...') nie dawał się łatwo zapamiętać, więc odrzuciliśmy obie propozycje. -Nadal potrzebowaliśmy nadać nazwę czemuś, nad czym pracujemy i wymyśliśmy nazwę "manager", która wcześniej nie miała swojego odpowiednika w innych frameworkach webowych. +Nadal potrzebowaliśmy nadać nazwę czemuś, nad czym pracujemy i wymyśliliśmy nazwę "manager", która wcześniej nie miała swojego odpowiednika w innych frameworkach webowych. <% end %> @@ -156,7 +156,7 @@ Jeżeli wszystko zostało wpisane poprawnie, powinieneś zobaczyć w przeglądar <%= commit "3-1", "Dodany szablon listy postów i statyczne dane szablonu." %> -Osiągneliśmy tutaj dwie rzeczy. Po pierwsze ustawiliśmy dane początkowe prototypu aplikacji w talbice `postsData`. Dane te normalnie zostałyby pobrane z bazy danych, ale ponieważ jeszcze się tego nie nauczyliśmy (poczekaj do kolejnego rozdziału), "oszukujemy" przez wprowadzenie statycznych danych. +Osiągnęliśmy tutaj dwie rzeczy. Po pierwsze ustawiliśmy dane początkowe prototypu aplikacji w tablice `postsData`. Dane te normalnie zostałyby pobrane z bazy danych, ale ponieważ jeszcze się tego nie nauczyliśmy (poczekaj do kolejnego rozdziału), "oszukujemy" przez wprowadzenie statycznych danych. Po drugie, użyliśmy funkcję `Template.myTemplate.helpers()` Meteora, aby zdefiniować helper szablonu o nazwie `posts` który zwraca tablicę `postsData`. @@ -196,11 +196,11 @@ Tym razem wartością helpera `domain` nie jest tablica, ale funkcja anonimowa. <%= screenshot "3-2", "Wyświetlenie domen dla każdego linku." %> -Helper `domain` ma URL jako paramter i zwraca jego domenę używając kilku sztuczek JavaScript. Ale skąd bierze się sam url? +Helper `domain` ma URL jako parametr i zwraca jego domenę używając kilku sztuczek JavaScript. Ale skąd bierze się sam url? -Aby odpowiedzieć na to pytanie, musimy wrócić do szablonu `posts_list.html`. Block helper `{{#each}}` nie tylko iteruje po tablicy, are również **ustawia wartość `this` w środku bloku odpowiadającego iterowanemu obiektowi**. +Aby odpowiedzieć na to pytanie, musimy wrócić do szablonu `posts_list.html`. Block helper `{{#each}}` nie tylko iteruje po tablicy, ale również **ustawia wartość `this` w środku bloku odpowiadającego iterowanemu obiektowi**. -Oznacza to, że pomiędzy tagami `{{#each}}`, każdy post po kolei jest równoznaczny z `this` i jest to zastosowane w każdym wstawioym managerze szablonu (`post_item.js`). +Oznacza to, że pomiędzy tagami `{{#each}}`, każdy post po kolei jest równoznaczny z `this` i jest to zastosowane w każdym wstawionym managerze szablonu (`post_item.js`). Rozumiemy teraz dlaczego `this.url()` zwraca URL bieżącego posta. Co więcej, jeżeli użyjemy `{{title}}` i `{{url}}` w środku szablonu `post_item.html`, Meteor rozpozna co oznacza `this.title` i `this.url` i zwróci poprawne wartości. diff --git a/03s-using-github.md.erb b/03s-using-github.md.erb index 8513b72..84e544e 100644 --- a/03s-using-github.md.erb +++ b/03s-using-github.md.erb @@ -14,7 +14,7 @@ Ten rozdział zakłada, że nie jesteś zaznajomiony z Git i GitHub. Jeżeli zna ### Praca z commitami -Podstawowym narzędziem, zmianą części pliku jest *commit*. Możesz myślić o commit jak o zrzucie stanu bazy plików w danym momencie czasu. +Podstawowym narzędziem, zmianą części pliku jest *commit*. Możesz myśleć o commit jak o zrzucie stanu bazy plików w danym momencie czasu. Zamiast dostarczenia całego kodu Microcope, robiliśmy takie zrzuty w trakcie pisania książki i możesz je zobaczyć online na GitHub. @@ -54,7 +54,7 @@ GitHub nie pokazuje wielu wizualizacji tego, co obserwujemy patrząc na commit, ### Lokalny dostęp do commita -Zobaczyliśmy przed chwilą, jak przeglądać kod danego commita online na GitHub. Ale co jeśli chciałbyć osiągnąć to samo lokalnie? Przykładowo, mógłbyś mieć ochotę na uruchomienie aplikacji lokalnie na danym commicie, aby zobaczyć jak ma się zachowywać w danym momencie czasu. +Zobaczyliśmy przed chwilą, jak przeglądać kod danego commita online na GitHub. Ale co jeśli chciałbyś osiągnąć to samo lokalnie? Przykładowo, mógłbyś mieć ochotę na uruchomienie aplikacji lokalnie na danym commicie, aby zobaczyć jak ma się zachowywać w danym momencie czasu. Aby to osiągnąć, przejdziemy przez pierwsze kroki (przynajmniej w tej książce) z konsolową aplikacją `git`. Dla początkujących, [upewnij się, że zainstalowałeś Git](http://git-scm.com/downloads). Następnie **sklonuj** (inaczej mówiąc, pobierz z serwera kopię) repozytorium Microscope za pomocą: @@ -94,7 +94,7 @@ Git poinformował, że jesteśmy obecnie w stanie “detached HEAD”, co oznacz (Uwaga: Git posiada w swoim arsenale również komendy pozwalające na *zmianę* poprzednich commitów. Tu mógłbyś wyobrazić sobie podróżnika w czasie zmieniającego przeszłość, ale jest to poza zakresem tego krótkiego wstępu do Gita). -Powodem, dla którego mogłeś wpisać `chapter3-1` jest to, że otagowaliśmy wszystkie commity Microscope poprawnym znacznikiem rozdziału. Gdybyśmy tego nie zrobili, konieczne byłoby odnalezienie **hasha** lub mówiąc inaczej unikalnego idetyikatora danego commita. +Powodem, dla którego mogłeś wpisać `chapter3-1` jest to, że otagowaliśmy wszystkie commity Microscope poprawnym znacznikiem rozdziału. Gdybyśmy tego nie zrobili, konieczne byłoby odnalezienie **hasha** lub mówiąc inaczej unikalnego identyfikatora danego commita. Ponownie w takim przypadku GitHub ułatwia pracę. Można znaleźć tag commita w dolnym prawym rogu niebieskiego przycisku nagłówka, jak pokazano poniżej: @@ -138,4 +138,4 @@ Uporządkowany widok informuje kto i w jakim commicie modyfikował dany plik (in <%= screenshot "s3-11", "Widok Blame w GitHub." %> -Ponieważ Git oraz GitHub są całkiem skomplikowanymi narzędziami, nie mamy zamiaru przedstawić wszystkich informacji na ich temat w pojedyńczym rozdziale. Tak naprawdę dotknęliśmy tylko czubka góry lodowej, ale mamy nadzieję, że przedstawiona wiedza okaże się przydatna podczas dalszego czytania tej książki. +Ponieważ Git oraz GitHub są całkiem skomplikowanymi narzędziami, nie mamy zamiaru przedstawić wszystkich informacji na ich temat w pojedynczym rozdziale. Tak naprawdę dotknęliśmy tylko czubka góry lodowej, ale mamy nadzieję, że przedstawiona wiedza okaże się przydatna podczas dalszego czytania tej książki. diff --git a/04-collections.md.erb b/04-collections.md.erb index 4cfe0f4..24c4617 100644 --- a/04-collections.md.erb +++ b/04-collections.md.erb @@ -15,7 +15,7 @@ Budujemy aplikację społeczonościową wyświetlającą wiadomości, zatem pier Oczywiście potrzebujemy te posty gdzieś przechowywać. Meteor domyślnie pracuje z bazą danych MongoDB, która jest uruchomiona po stronie serwera i jest twoim stałym magazynem danych. -Z tego względu, mimo to, że przeglądarka może przechowywać pewien stan aplikacji (na przykład bieżącą stronę, lub aktualnie wpisywany komentarz), serwer, a szczególniej Mongo zawiera stały, kanoniczny magazyn danych. Przez *kanoniczny* rozumiemy, że jest taki sam dla wszystkich użytkowników: każdy użytkownik może być na innej stronie, ale główna lista postów jest taka sama dla wszystkich użykowników. +Z tego względu, mimo to, że przeglądarka może przechowywać pewien stan aplikacji (na przykład bieżącą stronę, lub aktualnie wpisywany komentarz), serwer, a szczególniej Mongo zawiera stały, kanoniczny magazyn danych. Przez *kanoniczny* rozumiemy, że jest taki sam dla wszystkich użytkowników: każdy użytkownik może być na innej stronie, ale główna lista postów jest taka sama dla wszystkich użytkowników. Te dane są przechowane w **Kolekcji** Meteora. Kolekcja jest specjalną strukturą danych, która poprzez publikacje i subskrypcje troszczy się o synchronizację danych w czasie rzeczywistym między każdą podłączoną przeglądarką po stronie klienta i bazą danych Mongo. Przyjrzyjmy się temu bliżej. @@ -34,17 +34,17 @@ Kod, który nie znajduje się ani w folderze `client/` ani w `server/` będzie u ### Używać Var czy nie? -W Meteorze słowo kluczowe `var` ogranicza zagres obiektu do bieżącego pliku. Ponieważ chcemy udostępnić kolekcję `Posts` całej aplikacji, *nie* używamy słowa kluczowego `var`. +W Meteorze słowo kluczowe `var` ogranicza zakres obiektu do bieżącego pliku. Ponieważ chcemy udostępnić kolekcję `Posts` całej aplikacji, *nie* używamy słowa kluczowego `var`. <% end %> -Po stronie serwera kolekcja kontaktuje się z bazą danych Mongo, czyta i zapisuje dowolne zmiany. W ten sposób może być porównana do standardowej biblioteki bazy danych. Po stroni klienta kolekcja jest *bezpieczną* kopią *pozdbioru* prawdziwej, kanonicznej kolekcji. Kolekcja po stronie klienta jest na bieżąco i (w większości) niewidowicznie uaktualniana w czasie rzeczywistym z oznaczonym podzbiorem danych. +Po stronie serwera kolekcja kontaktuje się z bazą danych Mongo, czyta i zapisuje dowolne zmiany. W ten sposób może być porównana do standardowej biblioteki bazy danych. Po stroni klienta kolekcja jest *bezpieczną* kopią *pozdbioru* prawdziwej, kanonicznej kolekcji. Kolekcja po stronie klienta jest na bieżąco i (w większości) niewidocznie uaktualniana w czasie rzeczywistym z oznaczonym podzbiorem danych. <% note do %> -### Konsola vs Konsola vs Konsola +### Konsola vs. Konsola vs. Konsola -W niniejzym rozdziale zaczniemy korzystać z **konsoli przeglądarki**, której nie należy mylić z **terminalem** czy **konsolą Mongo**. Poniżej znajdziesz szybkie wprowadzenie do każdej z nich. +W niniejszym rozdziale zaczniemy korzystać z **konsoli przeglądarki**, której nie należy mylić z **terminalem** czy **konsolą Mongo**. Poniżej znajdziesz szybkie wprowadzenie do każdej z nich. #### Terminal @@ -101,7 +101,7 @@ Możesz również przeczytać logi aplikacji przez wpisanie polecenia `meteor lo <% end %> -Składnia Mongo wydaje się być znajoma, pownieważ używa interfejsu Javascript. Nie będziemy przeprowadzali kolejnych zmian w konsoli Mongo, ale od czasu do czasu sprawdzimy czy oczekiwane dane faktycznie znajdują się w bazie. +Składnia Mongo wydaje się być znajoma, ponieważ używa interfejsu Javascript. Nie będziemy przeprowadzali kolejnych zmian w konsoli Mongo, ale od czasu do czasu sprawdzimy czy oczekiwane dane faktycznie znajdują się w bazie. ### Kolekcje po stronie klienta @@ -125,7 +125,7 @@ Kluczowym zagadnieniem jest sposób, w jaki kolekcja po stronie klienta synchron Zamiast wyjaśniać to szczegółowo zobaczmy co dzieje się podczas synchronizacji. -Otwórz dwa okna przeglądarki i uruchom konsolę przeglądarki w każdej z nich. Następnie uruchom konsolę Mongo z linii komend. W tym momencie, powinieneś zobaczyć w każdym z trzech miejsc pojedyńczy dokument, który utworzyliśmy wcześniej. +Otwórz dwa okna przeglądarki i uruchom konsolę przeglądarki w każdej z nich. Następnie uruchom konsolę Mongo z linii komend. W tym momencie, powinieneś zobaczyć w każdym z trzech miejsc pojedynczy dokument, który utworzyliśmy wcześniej. ~~~bash > db.posts.find(); @@ -160,7 +160,7 @@ Bez większych niespodzianek post został dodany do lokalnej kolekcji. Sprawdźm ~~~ <%= caption "Konsola Mongo" %> -Jak widać, post został przeniesiony z powrotem do bazy danych Mongo po stronie serwera bez potrzeby pisania pojedyńczej linii kodu (tak naprawdę to napisaliśmy _jedną_ linię kodu: `new Meteor.Collection('posts')`). Ale to nie wszystko! +Jak widać, post został przeniesiony z powrotem do bazy danych Mongo po stronie serwera bez potrzeby pisania pojedynczej linii kodu (tak naprawdę to napisaliśmy _jedną_ linię kodu: `new Meteor.Collection('posts')`). Ale to nie wszystko! Przejdź do drugiej instancji przeglądarki i wpisz w konsoli: @@ -262,7 +262,7 @@ W obrębie aplikacji Meteor jest sprytny na tyle, aby iterować po kursorze bez <% end %> -Teraz, zamiast wczytywać statyczną tablicę z listą postów za pomocą zmiennej, zwracamy kursor do helpera `posts`. Ale co tym sposobem osiągneliśmy? Jeżeli wrócimy do przeglądarki, zobaczymy: +Teraz, zamiast wczytywać statyczną tablicę z listą postów za pomocą zmiennej, zwracamy kursor do helpera `posts`. Ale co tym sposobem osiągnęliśmy? Jeżeli wrócimy do przeglądarki, zobaczymy: <%= screenshot "4-3", "Użycie zmiennych danych" %> @@ -291,11 +291,11 @@ Właśnie pierwszy raz byłeś naocznym świadkiem działania reaktywności. Gdy W tym przypadku, najprostszą zmianą było dodanie kolejnego `
...
`. Jeżeli chcesz się upewnić, że to się na pewno wydarzyło, otwórz DOM inspector i zaznacz element `
` odpowiadający jednemu z istniejących postów. -Teraz, w konsoli JavaScript, wstaw kolejny post. Jeżeli przejdziesz z powrotem do inspectora DOM, zobaczysz dodatkowy element `
` odpowiadający nowemu postowi, ale nadal będzie zaznaczony *ten sam* element `
` co poprzednio. Jest to użyteczny sposób na sprawdzenie, kiedy elementy zostały przerenderowane i kiedy nie ulegają zmianie. +Teraz, w konsoli JavaScript, wstaw kolejny post. Jeżeli przejdziesz z powrotem do inspektora DOM, zobaczysz dodatkowy element `
` odpowiadający nowemu postowi, ale nadal będzie zaznaczony *ten sam* element `
` co poprzednio. Jest to użyteczny sposób na sprawdzenie, kiedy elementy zostały przerenderowane i kiedy nie ulegają zmianie. <% end %> -### Łączenie kolekcji: Publikacje i Subsrkrypcje +### Łączenie kolekcji: Publikacje i Subskrypcje Do tej pory używaliśmy pakietu `autopublish`, który nie jest zamierzony do użycia w środowisku produkcyjnym. Jak nazwa wskazuje, pakiet ten automatycznie publikuje w całości wszystkie kolekcje każdemu podłączonemu klientowi. Nie jest to, co chcemy osiągnąć, więc wyłączmy to. @@ -305,9 +305,9 @@ Otwórz nowe okno terminala i wpisz: $ meteor remove autopublish ~~~ -Ma to efekt natychmiastowy. Jeżeli będziesz obserwował przeglądarkę, zobaczysz, że wszystkie posty zniknęły! Dzieje się tak, poniewaź polegaliśmy na pakiecie `autopublish`, który tworzył lustrzane odbicie wszystkich postów z bazy danych w kolekcji po stronie klienta. +Ma to efekt natychmiastowy. Jeżeli będziesz obserwował przeglądarkę, zobaczysz, że wszystkie posty zniknęły! Dzieje się tak, ponieważ polegaliśmy na pakiecie `autopublish`, który tworzył lustrzane odbicie wszystkich postów z bazy danych w kolekcji po stronie klienta. -W końcu będzieli musieli się upewnić, że przesyłamy wyłącznie te posty, które użytkownik będzie miał zobaczyć (biorąc również po uwagę np. dzielenie dokumentu na strony). Na teraz, ustawimy publikację kolekcji `Posts` w całości. +W końcu będziemy musieli się upewnić, że przesyłamy wyłącznie te posty, które użytkownik będzie miał zobaczyć (biorąc również po uwagę np. dzielenie dokumentu na strony). Na teraz, ustawimy publikację kolekcji `Posts` w całości. Aby to osiągnąć, utworzymy prostą funkcję `publish()`, która zwraca kursor posiadający referencję do wszystkich postów: @@ -329,6 +329,6 @@ Meteor.subscribe('posts'); Jeżeli ponownie sprawdzimy przeglądarkę, zobaczymy ponownie nasze posty. Świetnie! -### Konluzja +### Konkluzja Co zatem osiągnęliśmy? Pomimo tego, że jeszcze nie posiadamy interfejsu użytkownika, mamy funkcjonalną aplikację webową. Moglibyśmy wystawić aplikację na zewnętrznym internetowym serwerze i (używając konsolę przeglądarki) zacząć dodawać posty, które byłyby widziane w każdej podłączonej do strony przeglądarki na całym świecie. diff --git a/04s-publications-and-subscriptions.md.erb b/04s-publications-and-subscriptions.md.erb index c88f6db..a834c3a 100644 --- a/04s-publications-and-subscriptions.md.erb +++ b/04s-publications-and-subscriptions.md.erb @@ -24,7 +24,7 @@ Gdy dane zostały znalezione, kolejnym zadaniem aplikacji jest przetłumaczenie Używając metafory księgarni, można to skojarzyć z opakowaniem właśnie zakupionej książki i wrzucenie jej do torby. Jest to część nazywana "View" w znanym modelu MVC (Model-View-Controller). -Ostatecznie, aplikacja wysyła wygenerowany kod HTML do przeglądarki. Praca aplikacji jest zakończona i kontrola zostaje przekazana z dala od jej wirtualnych rąk, oczekująć na kolejny dostęp. +Ostatecznie, aplikacja wysyła wygenerowany kod HTML do przeglądarki. Praca aplikacji jest zakończona i kontrola zostaje przekazana z dala od jej wirtualnych rąk, oczekując na kolejny dostęp. ### Jak to robi Meteor @@ -50,7 +50,7 @@ Wróćmy do Microscope. Poniżej znajdziesz wszystkie posty znajdujące się w b Co prawda taka funkcjonalność nie istnieje w aplikacji Microscope, ale wyobraźmy sobie, że niektóre z postów zostały zaznaczone jako posiadające obraźliwe słownictwo. Mimo to, że chcemy je dalej przechowywać w bazie danych, nie powinny być udostępniane użytkownikom (tj. wysyłane do klienta). -Naszym pierwszym zadaniem będzie przekazanie Meteorowi które dane *chcemy* wysłać klientowi. Bedą **publikowane** wyłącznie te posty, które nie zostały oznaczone flagą jako obraźliwe. +Naszym pierwszym zadaniem będzie przekazanie Meteorowi które dane *chcemy* wysłać klientowi. Będą **publikowane** wyłącznie te posty, które nie zostały oznaczone flagą jako obraźliwe. <%= diagram "collections-2", "Wyłączenie zaznaczonych postów.", "pull-center" %> @@ -109,7 +109,7 @@ Okazuje się, że post Boba jest przyporządkowany do kliku kategorii (np. “Ja <%= diagram "collections-4", "Zaznaczanie podzbioru dokumentów po stronie klienta.", "pull-center" %> -Tak, jak po stronie serwera, użyjemy funkcję `Posts.find()` do zaznaczenia pozdbioru danych. +Tak, jak po stronie serwera, użyjemy funkcję `Posts.find()` do zaznaczenia podzbioru danych. ~~~js // po stronie klienta @@ -134,7 +134,7 @@ Jak to działa? Przyjmijmy, że posiadasz aplikację `'posts'` po stronie serwer Jeżeli zatem używasz pakietu `autopublish`, nie musisz się troszczyć o publikacje. Dane są wszechobecne i wszystko jest proste. Oczywiście możesz napotkać oczywiste problemy związane z utrzymywaniem kompletnej kopii bazy danych po stronie klienta na każdej maszynie po stronie klienta. -Z tego powodu użycie autopublish jest odpowiednie wyłącznie wtedy gdy zaczynasz implementację i nie uzwględniłeś publikacji. +Z tego powodu użycie autopublish jest odpowiednie wyłącznie wtedy gdy zaczynasz implementację i nie uwzględniłeś publikacji. ### Publikowanie całych kolekcji @@ -170,7 +170,7 @@ Jeżeli czytałeś [dokumentację publikacji Meteora](http://docs.meteor.com/#pu Jest to spowodowane bardzo ważnym ułatwieniem, które dostarcza Meteor: metodą `_publishCursor()`. Nie widziałeś również tej metody? Może nie bezpośrednio, ale jeżeli zwracasz [kursor](/chapter/meteor-vocabulary/) (np. `Posts.find({'author':'Tom'})`) w funkcji dokonującej publikacji, to Meteor używa właśnie tej funkcji. -Gdy Meteor rozpoznaje, że publikacjia `somePosts` zwraca kursor, woła metodę `_publishCursor()` aby -- tak, zgadłeś -- automatycznie publikować powyższy kursor. +Gdy Meteor rozpoznaje, że publikacja `somePosts` zwraca kursor, woła metodę `_publishCursor()` aby -- tak, zgadłeś -- automatycznie publikować powyższy kursor. Pokrótce opiszmy sposób działania `_publishCursor()`: diff --git a/05-routing.md.erb b/05-routing.md.erb index 6a05272..bebd4b4 100644 --- a/05-routing.md.erb +++ b/05-routing.md.erb @@ -7,7 +7,7 @@ contents: o routingu w Meteorze.|jak tworzyć stronę z dyskusją o postach, z u paragraphs: 72 --- -Teraz skoro mamy listę postów (która w końcu będzie wysłana) potrzebujemy stronę dla każdego posta, na której użytkownicy będą mogli prowadzić dyskuję. +Teraz skoro mamy listę postów (która w końcu będzie wysłana) potrzebujemy stronę dla każdego posta, na której użytkownicy będą mogli prowadzić dyskusję. Chcielibyśmy, żeby te strony były dostępne za pomocą *permanentnego linka*, URLa w formie `http://myapp.com/posts/xyz` (gdzie `xyz` jest identyfikatorem MongoDB `_id`), który jest unikalny dla każdego posta. @@ -39,11 +39,11 @@ Poruszymy wiele różnych tematów routera w tym rozdziale. Jeżeli masz doświa - **Routes** (trasy): Trasa jest fundamentalnym pojęciem routera. Jest to zbiór instrukcji, który wskaże aplikacji gdzie się kierować i co robić po napotkaniu danego URL. - **Paths** (ścieżki): Ścieżka jest dowolnym URLem dostępnym w Twojej aplikacji. Może być statyczna (`/terms_of_service`) lub dynamiczna (`/posts/xyz`) i może nawet zawierać parametry zapytań (`/search?keyword=meteor`). - **Segments** (segmenty): części ścieżki rozdzielone slashem (`/`). -- **Hooks** (haki): Hak jest akcją, którą chciałbyć wykonać przed, po, lub podczas wykonywania procesu routowania. Typowym przykładem może być sprawdzenie, czy użytkownik ma wystarczające prawa, aby obejrzeć daną stronę. +- **Hooks** (haki): Hak jest akcją, którą chciałbyś wykonać przed, po, lub podczas wykonywania procesu routowania. Typowym przykładem może być sprawdzenie, czy użytkownik ma wystarczające prawa, aby obejrzeć daną stronę. - **Filters** (filtry): Filtry to globalne haki, które definiuje się dla jednej lub więcej tras. - **Route Templates** (szablony trasy): Każda trasa musi wskazywać na szablon. Jeżeli nie określisz konkretnego szablonu, router będzie domyślnie szukał szablonu o tej samej nazwie, co trasa. - **Layouts**: (układy) Możesz pomyśleć o układach jak o ramce na zdjęcia. Zawierają cały kod HTML, który opakowuje bieżący szablon i pozostanie nienaruszony po zmianach szablonu. -- **Controllers** (kontrolery): Czasami zdasz sobie sprawę, że wiele Twoich szablonów używa tych samych parametrów. Zamiast duplikować kod, możesz sprawic aby wszystkie takie trasy dziedziczyły z jednego *kontrolera trasy*, który będzie zawierał logikę routingu. +- **Controllers** (kontrolery): Czasami zdasz sobie sprawę, że wiele Twoich szablonów używa tych samych parametrów. Zamiast duplikować kod, możesz sprawić aby wszystkie takie trasy dziedziczyły z jednego *kontrolera trasy*, który będzie zawierał logikę routingu. Aby dowiedzieć się więcej o Iron Router, sprawdź [pełną dokumentację na GitHub](https://github.com/EventedMind/iron-router). @@ -103,7 +103,7 @@ Router.map(function() { ~~~ <%= caption "lib/router.js"%> -Osiągneliśmy dwie ważne sprawy. Po pierwsze, wskazaliśmy routerowi, aby używał layout, który właśnie utworzyliśmy jako domyślny layout dla wszystkich tras. Po drugie, zdefiniowaliśmy nową trasę o nazwie `postLists` i powiązaliśmy ją ze ścieżką `/`. +Osiągnęliśmy dwie ważne sprawy. Po pierwsze, wskazaliśmy routerowi, aby używał layout, który właśnie utworzyliśmy jako domyślny layout dla wszystkich tras. Po drugie, zdefiniowaliśmy nową trasę o nazwie `postLists` i powiązaliśmy ją ze ścieżką `/`. <% note do %> @@ -307,7 +307,7 @@ Nazwaliśmy ścieżkę posta `postPage`, zatem możemy użyć helpera `{{pathFor ~~~ <%= caption "client/views/posts/post_item.html"%> <%= highlight "6" %> -<%= commit "5-3", "Przekierowanie na pojedyńczą stronę posta." %> +<%= commit "5-3", "Przekierowanie na pojedynczą stronę posta." %> Ale chwila, skąd dokładnie router wie, skąd wziąć część `xyz` z `/posts/xyz`? W końcu nie przekazujemy tu żadnego `_id`. diff --git a/05s-the-session.md.erb b/05s-the-session.md.erb index 013c176..3a3781e 100644 --- a/05s-the-session.md.erb +++ b/05s-the-session.md.erb @@ -139,7 +139,7 @@ Jeżeli mielibyśmy ręcznie przeładować stronę, nasze zmienne Session natura Jeżeli zatem używamy zmiennych sesji do śledzenia tego, co użytkownik właśnie robi, HCR powinien być prawie transparentny dla użytkownika, ponieważ zachowa wartość wszystkich zmiennych sesji. Pozwala to na instalację nowej wersji produkcyjnej naszej aplikacji Meteora mając pewność, że nasi użytkownicy będą w minimalnym stopniu zdezorganizowani. -Rozważ to przez chwilę. Jeżeli możemy trzymać cały stan w URL i sesji, możemy transparetnie zmieniać _uruchomiony kod źródłowy_ każdej aplikacji klienta nie przeszkadzając im zbytnio. +Rozważ to przez chwilę. Jeżeli możemy trzymać cały stan w URL i sesji, możemy transparentnie zmieniać _uruchomiony kod źródłowy_ każdej aplikacji klienta nie przeszkadzając im zbytnio. Sprawdźmy co dzieje się, gdy ręcznie odświeżymy stronę: diff --git a/06-adding-users.md.erb b/06-adding-users.md.erb index 44b63bc..a9771d0 100644 --- a/06-adding-users.md.erb +++ b/06-adding-users.md.erb @@ -101,7 +101,7 @@ Teraz wyloguj się i ponownie utwórz konto z inną nazwą użytkownika. `Meteor ❯ Meteor.users.find().count(); 1 ~~~ -<%= caption "Konsola przeglądarkiu" %> +<%= caption "Konsola przeglądarki" %> Konsola zwraca wartość 1. Czy nie powinna mieć wartości 2? Czy pierwszy użytkownik został usunięty? Jeżeli spróbujesz zalogować się jako pierwszy użytkownik, zobaczysz, że tak się nie stało. @@ -127,7 +127,7 @@ Pakiet `accounts` publikuje wyłącznie *bieżącego* użytkownika. Wyjaśnia to Publikacja zatem publikuje wyłącznie jeden obiekt użytkownika dla każdego zalogowanego użytkownika (i nie publikuje żadnego, gdy nie jesteś zalogowany). -Co więcej, dokumenty w naszej kolekcji użytkownika nie zawierają tych samych pól po stronie klienta i serwera. W Mongo, użytkownik posiada wiele danych. Aby to zobaczyć, wróc do terminala Mongo i wpisz: +Co więcej, dokumenty w naszej kolekcji użytkownika nie zawierają tych samych pól po stronie klienta i serwera. W Mongo, użytkownik posiada wiele danych. Aby to zobaczyć, wróć do terminala Mongo i wpisz: ~~~bash > db.users.findOne() diff --git a/06s-reactivity.md.erb b/06s-reactivity.md.erb index ee801c7..0a287bc 100644 --- a/06s-reactivity.md.erb +++ b/06s-reactivity.md.erb @@ -47,7 +47,7 @@ W takich przypadkach będziesz musiał używać callbacków `observe()` aby zmus ### Podejście deklaratywne -Meteor daje nam lepsze rozwiązanie: reaktywność, która jest samym jądrem podejścia **deklaratywnego**. Bycie deklaratywnym pozwala na zdefiniowanie związku między obiektami raz i poźniej poleganie na tym, że będą automatycznie synchronizowane zamiast ustawiać akcje reagujące na każdą możliwą zmianę. +Meteor daje nam lepsze rozwiązanie: reaktywność, która jest samym jądrem podejścia **deklaratywnego**. Bycie deklaratywnym pozwala na zdefiniowanie związku między obiektami raz i później poleganie na tym, że będą automatycznie synchronizowane zamiast ustawiać akcje reagujące na każdą możliwą zmianę. Jest to bardzo mocny koncept, ponieważ system reagujący w czasie rzeczywistym ma wiele wejść, które mogą zmieniać się w nieoczekiwanych momentach. Przez deklaratywne określenie jak renderujemy bazowane na HTML lub jakiekolwiek inne źródła danych o które się troszczymy, Meteor może przejąć pracę monitorowania źródeł danych i w sposób niewidoczny uaktualniać interfejs użytkownika. diff --git a/07-creating-posts.md.erb b/07-creating-posts.md.erb index 79e7edc..1f20645 100644 --- a/07-creating-posts.md.erb +++ b/07-creating-posts.md.erb @@ -110,7 +110,7 @@ Uwaga: jest tu wiele znaczników pochodzących z Bootstrap Twittera. Podczas gdy <%= screenshot "7-1", "Formularz dodawania posta" %> -Jest to prosty formularz. Nie musimy się martwić o wykonanie konkretnej akcji, ponieważ będziemy przechwytywali zdarzenie `wyślij` na forumlarzu i uaktualniali dane za pomocą JavaScript. (Nie ma sensu dostarczać na wszelki wypadek rozwiązania nie-JavaScript, gdy weźmiesz pod uwagę, że aplikacja Meteora jest całkowicie niefunkcjonalna po wyłączeniu obsługi JavaScript). +Jest to prosty formularz. Nie musimy się martwić o wykonanie konkretnej akcji, ponieważ będziemy przechwytywali zdarzenie `wyślij` na formularzu i uaktualniali dane za pomocą JavaScript. (Nie ma sensu dostarczać na wszelki wypadek rozwiązania nie-JavaScript, gdy weźmiesz pod uwagę, że aplikacja Meteora jest całkowicie niefunkcjonalna po wyłączeniu obsługi JavaScript). ### Tworzenie postów @@ -138,9 +138,9 @@ Template.postSubmit.events({ Powyższa funkcja używa [jQuery](http://jquery.com) do parsowania wartości różnych pól formularza i tworzenia nowego obiektu posta z wyników parsowania. Musimy się upewnić, że używamy `preventDefault` na parametrze `event` naszego handlera aby upewnić się, że przeglądarka nie będzie kontynuowała i próbowała wysłać formularza. -Ostatecznie, możemy przekierować uzytkownika to strony nowego posta. Funkcja kolekcji `insert` zwraca wygenerowany `id` dla obiektu, który został wstawiony do bazy danych, który użyje funkcja Routera `go()` aby utworzyć docelowy URL. +Ostatecznie, możemy przekierować użytkownika to strony nowego posta. Funkcja kolekcji `insert` zwraca wygenerowany `id` dla obiektu, który został wstawiony do bazy danych, który użyje funkcja Routera `go()` aby utworzyć docelowy URL. -Końcowym rezultatem jest to, że po wciśnieciu przycisku `wyślij` przez użytkownika, tworzony jest post i użytkownik jest natychmiastowo zabierany do strony z dyskusją na temat tego nowego posta. +Końcowym rezultatem jest to, że po wciśnięciu przycisku `wyślij` przez użytkownika, tworzony jest post i użytkownik jest natychmiastowo zabierany do strony z dyskusją na temat tego nowego posta. ### Dodanie kilku środków bezpieczeństwa @@ -155,7 +155,7 @@ $ meteor remove insecure ~~~ <%= caption "Terminal" %> -Po wykonaniu tej komendy zauważyszm że formularz posta przestanie działać. Dzieje się to, ponieważ bez pakietu `insecure`wstawianie danych po stronie klienta _przestaje być dozwolone_. Musimy dodać Metorowi wyraźne zasady pozwalające na wstawianie postów przez klienta lub wstawiać posty po stronie serwera. +Po wykonaniu tej komendy zauważysz że formularz posta przestanie działać. Dzieje się to, ponieważ bez pakietu `insecure`wstawianie danych po stronie klienta _przestaje być dozwolone_. Musimy dodać Metorowi wyraźne zasady pozwalające na wstawianie postów przez klienta lub wstawiać posty po stronie serwera. ### Zezwolenie na wstawianie postów @@ -186,7 +186,7 @@ Zdołaliśmy upewnić się, że musisz być zalogowany, aby móc tworzyć posty. Jednakże, wciąż musimy dać sobie radę z kilkoma problemami: - - Wylogowani użytkownicy nadal mają dostę do formularza tworzenia posta + - Wylogowani użytkownicy nadal mają dostęp do formularza tworzenia posta - Post nie jest związany z użytkownikiem w żaden sposób (i nie ma żadnego kodu po stronie serwera, który by to obsługiwał). - Można utworzyć wiele postów, które będą wskazywały na ten sam URL. @@ -304,7 +304,7 @@ Helper `currentUser` jest dostarczony przez pakiet `accounts` i jest odpowiednik ### Serwerowe metody Meteora: Większy stopień bezpieczeństwa i abstrakcji -Zdołaliśmy zabezpieczyć dostęp do strony nowych postów dla niezalogowanych użytkowników, i odmówić takim użytkownim możliwość dodawania postów nawet jeżeli oszukują i używają konsoli przeglądarki. Jest jednak jeszcze kilka rzeczy, o które musimy się zatroszczyć: +Zdołaliśmy zabezpieczyć dostęp do strony nowych postów dla niezalogowanych użytkowników, i odmówić takim użytkownikom możliwość dodawania postów nawet jeżeli oszukują i używają konsoli przeglądarki. Jest jednak jeszcze kilka rzeczy, o które musimy się zatroszczyć: - Dodanie znacznika czasu do posta. - Upewnienie się, że ten sam URL nie można dodać więcej, niż jeden raz. @@ -344,7 +344,7 @@ Template.postSubmit.events({ ~~~ <%= caption "client/views/posts/post_submit.js" %> -Funkcja `Meteor.call` woła Metodę o nazwie określonej w pierwszym parametrze funkcji. Możesz dodać parametry do wywołania funkcji (w tym przypadku obiekt `post` skonstruowany na podstawie formularza) i ostatecznie dodać callback, który zostanie uruchomiony po zakończeniu Metody. Tutaj po prostu ostrzegamy użytkownika czy wystąpił jakiś problem lub przekierowujemy go nowoutworzonej strony dyskusji konkretnego posta. +Funkcja `Meteor.call` woła Metodę o nazwie określonej w pierwszym parametrze funkcji. Możesz dodać parametry do wywołania funkcji (w tym przypadku obiekt `post` skonstruowany na podstawie formularza) i ostatecznie dodać callback, który zostanie uruchomiony po zakończeniu Metody. Tutaj po prostu ostrzegamy użytkownika czy wystąpił jakiś problem lub przekierowujemy go nowo utworzonej strony dyskusji konkretnego posta. Następnie zdefiniujemy Metodą w pliku `collections/posts.js`. Usuniemy blok `allow()` z `posts.js`, ponieważ Metoda Meteora i tak go ominie. Pamiętaj, że Metody są wykonywane po stronie serwera, więc Meteor uważa, że można im ufać. @@ -390,15 +390,15 @@ Meteor.methods({ Metoda ta jest trochę skomplikowana, ale mamy nadzieje że możesz nadążyć. -Na początkek definiujemy zmienną `user` i sprawdzamy, czy post z tym samym linkiem już nie istnieje. Następnie sprawdzamy, czy użytkownik jest zalogowany, rzucając błąd (który końcowo będzie wyświetlony w przeglądarce), jeżeli nie jest. Przeprowadzamy także prostą walidację obiektu posta, aby upewnić się, że post zawiera tytuł. +Na początek definiujemy zmienną `user` i sprawdzamy, czy post z tym samym linkiem już nie istnieje. Następnie sprawdzamy, czy użytkownik jest zalogowany, rzucając błąd (który końcowo będzie wyświetlony w przeglądarce), jeżeli nie jest. Przeprowadzamy także prostą walidację obiektu posta, aby upewnić się, że post zawiera tytuł. -Następnie, jeżeli istnieje już post z tym samym URL, rzucamy błąd `302` (który oznacza przekierowanie), przekazaując użytkownikowi, że powinien sprawdzić poprzednio tworzony post. +Następnie, jeżeli istnieje już post z tym samym URL, rzucamy błąd `302` (który oznacza przekierowanie), przekazując użytkownikowi, że powinien sprawdzić poprzednio tworzony post. Klasa `Error` Meteora ma trzy parametry. Pierwszy, (`error`) będzie numerycznym kodem `302`, drugi (`reason`) zawiera wyjaśnienie zrozumiałe dla człowieka i trzeci (`details`) może być jakąkolwiek użyteczną informacją. W naszym przypadku, użyjemy trzeci argument aby przekazać ID posta, który właśnie znaleźliśmy. Uwaga: użyjemy tego później aby przekierować użytkownika do jeszcze nieistniejącego posta. -Jeżeli wszystkie kroki są sprawdzone i przechodzą poprawnie, bierzemy pola, które chcemy wstawić (upewniając się, że użytkownik wołający tą Metodę w konsoli przeglądarki nie może dodać fałszywych danych do bazy) i dodajemy pewne informacje o uzytkowniku dodającym posta -- jak również bieżący czas -- do posta. +Jeżeli wszystkie kroki są sprawdzone i przechodzą poprawnie, bierzemy pola, które chcemy wstawić (upewniając się, że użytkownik wołający tą Metodę w konsoli przeglądarki nie może dodać fałszywych danych do bazy) i dodajemy pewne informacje o użytkowniku dodającym posta -- jak również bieżący czas -- do posta. Ostatecznie, wstawiamy post do bazy danych i zwracamy nowy `id` użytkownikowi. diff --git a/07s-latency-compensation.md.erb b/07s-latency-compensation.md.erb index 017175e..fc7b0cb 100644 --- a/07s-latency-compensation.md.erb +++ b/07s-latency-compensation.md.erb @@ -12,7 +12,7 @@ W ostatnim rozdziale wprowadziliśmy nowy koncept w świecie Metora: **Metody**, <%= diagram "latency1", "Bez kompensacji lagów", "pull-right" %> -Metoda w Meteorze umożliwia uruchomienie serii komand na serwerze w uporządkowany sposób. W naszym przykładzie, użytliśmy Metody ponieważ chcieliśmy upewnić się, że nowe posty zostaną otagowane imieniem autora i jego id oraz bieżącym czasem serwera. +Metoda w Meteorze umożliwia uruchomienie serii komand na serwerze w uporządkowany sposób. W naszym przykładzie, użyliśmy Metody ponieważ chcieliśmy upewnić się, że nowe posty zostaną otagowane imieniem autora i jego id oraz bieżącym czasem serwera. Gdyby jednak Meteor uruchamiał Metody w sposób najbardziej podstawowy, mielibyśmy problem. Rozważ następującą sekwencję zdarzeń (uwaga: znaczniki czasu są losowymi wartościami, wybranymi wyłącznie dla celów demonstracyjnych): @@ -128,6 +128,6 @@ Gdy definujesz kolekcję po stronie serwera o nazwie `posts`, definiujesz pośre Jeżeli nadążasz, mogłeś zdać sobie sprawę, że nasza metoda `post` podczas wstawiania postów wywołuje inną metodę (`posts/insert`). Jak to działa? -Gdy uruchamiana jest symulacja (wersja metody po stronie klienta), wykonujemy symulację `insert` (zatem wprowadzamy dane do koelekcji po stronie klienta), ale *nie wołamy* prawdziwej metody `insert` po stronie serwera, ponieważ oczekujemy, że wykona to *serwerowa* wersja metody `post`. +Gdy uruchamiana jest symulacja (wersja metody po stronie klienta), wykonujemy symulację `insert` (zatem wprowadzamy dane do kolekcji po stronie klienta), ale *nie wołamy* prawdziwej metody `insert` po stronie serwera, ponieważ oczekujemy, że wykona to *serwerowa* wersja metody `post`. Co za tym idzie, gdy serwerowa metoda `post` woła `insert`, nie ma potrzeby o martwienie się o symulację i wprowadzenie danych przebiega płynnie. diff --git a/08-editing-posts.md.erb b/08-editing-posts.md.erb index 2ae2805..f34a70b 100644 --- a/08-editing-posts.md.erb +++ b/08-editing-posts.md.erb @@ -7,7 +7,7 @@ contents: jak dodać formularz umożliwiający edytowanie postów.|jak ustawić paragraphs: 29 --- -Teraz skoro możemy tworzyć posty, następnym krokiem będzie umożliwienie edycji i usuwanie postóœ. Kod UI który to umożliwi jest releatywnie prosty i jest to dobry moment na podjęcie tematu zarządzania praw użytkowników. +Teraz skoro możemy tworzyć posty, następnym krokiem będzie umożliwienie edycji i usuwanie postów. Kod UI który to umożliwi jest relatywnie prosty i jest to dobry moment na podjęcie tematu zarządzania praw użytkowników. Zacznijmy od podłączenia routera. Dodamy ścieżkę, która umożliwi dostęp do strony modyfikacji posta i ustawi jej kontekst danych: @@ -52,7 +52,7 @@ Router.before(requireLogin, {only: 'postSubmit'}); ### Szablon edytowania posta -Możemy teraz skoncetrować się na szablonie. Nasz szablon `postEdit` będzie miał całkiem standardową formę: +Możemy teraz skoncentrować się na szablonie. Nasz szablon `postEdit` będzie miał całkiem standardową formę: ~~~html