Wypowiedzi
-
Ok, bo rozdmuchaliśmy prosty temat do niebotycznych rozmiarów :). Trzeba podsumować i zamknąć:
1. Literały obiektów i tablic (a także stringów, bo różne rzeczy już widziałem...) są w 99% jedynym słusznym wyborem.
2. Kodu nie zaciemniamy sami. Jeśli nie chcemy by jakiś pseudokoder pracujący w oparciu o zasadę kopiegopejsta skorzystał z naszego rozwiązania, to używamy programów typu UglifyJS, YUI Compressor, czy Google Closure. Choć tak naprawdę to używamy ich głównie po to, żeby zmniejszych objętość kodu.
-
-
-
-
Piotr L.:
Piotr Koszuliński:
Piotr L.:
Piotr Koszuliński:
Po co w ogóle się XHTML-em zajmować? To wynalazek dla lubiących tworzyć niepoprawny kod.
Ciekawa teoria... Skąd takie wnioski? Mówisz z własnego doświadczenia?
Z wiedzy, z obserwacji i z powyżej zacytowanych artykułów. Przeczytałeś?
Czytałem już jakiś czas temu... Dziwi mnie tylko takie bezpośrednie porównanie: ktoś używa XHTMLa = ktoś nie potrafi tworzyć poprawnego kodu... Umiejętności tworzenia poprawnego syntaktycznie i semantycznie kodu HTML nie jest IMHO wprost zależna od tego, jakiej specyfikacji się używa... Owszem - z HTML5 jest łatwiej, co nie znaczy, że nie zdarzają się buble...
Porównanie było skrótem myślowym, dlatego poparłem je dwoma linkami, aby nie powtarzać bez sensu świetnej pracy wykonanej przez Kornela.
Nie miałem w żadnym wypadku na myśli semantyki, ponieważ semantyka XHTML-a (w zasadzie jej brak, bo jest ona kopią tej z HTML-a) jest o wiele mniej złożona niż semantyka HTML-a 5. Problem w tym, że semantyka to nie wszystko. XHTML nakłada dodatkowe ograniczenia na kod (więcej tutaj: http://pornel.net/xhtml#sec20) których 99% twórców stron nie przestrzega, ponieważ te ograniczenia są oderwane od rzeczywistości - jak i cała gałąź XHTML-ów. W dodatku jeszcze ten skopany validator...
Tak więc, jako że znam realia wiem, że 99% frontendowców ("piszących" w XHTML-u) wypuszcza niepoprawne strony, z czego pewnie 75% o tym nie wie.
-
-
Po co w ogóle się XHTML-em zajmować? To wynalazek dla lubiących tworzyć niepoprawny kod. Więcej:
http://pornel.net/xhtml i http://pornel.net/html5
-
-
-
-
-
Marcin Skurski:
odnoszę wrażenie, że goldenline to nie najlepsze miejsce jeśli chodzi o porady związane z programowaniem. Pytanie zadałem konkretnie i wprawdzie dostałem konkretne odpowiedzi, ale co niektórzy chyba przywykli do rozkazów i najwyraźniej właśnie tak potraktowali ten wątek, zapominając że jak nie chcą pomóc to nie powinni się udzielać.
Możliwe, że niektórzy uważają swój czas za zbyt cenny, ale jeszcze nie nauczyli się nim zarządzać. Wchodzą na GL tracąc czas, chcą odpowiedzieć bo przecież wiedzą, ale w trakcie przypominają sobie, że czas to pieniądz ;>
Albo myślą, że pracodawcy z przyklaskiem potraktują kogoś, kto pokazuje innym swą wyższość :).
-
Akurat moim zdaniem strasznie marudzicie. Bo problemem na moje oko nie była nieznajomość API, a ogólna nieznajomość JS. W tym wypadku odsyłanie człowieka do specyfikacji jest śmieszne. Coś w stylu:
tutaj poczytasz sobie 2h, zrozumiesz API, później przejdź do zagadnień związanych z XYZ, jakieś 4h, a później jeszcze doczytaj o ZĆB - zdążysz w 2h. Na koniec 2 linie kodu i masz to co chciałeś.
To nie było pytanie w stylu forumweb.pl, gdzie dzieciaki wklejają 500 linii kodu i mówią "nie działa". Było ~10 linii i odpowiedni komentarz w czym problem.
Tak więc jeszcze raz - marudzicie.
-
Innymi słowy, interesuje Cię coś co nazywamy callbackami. Funkcja, którą najczęściej przekazujemy do jakiejś metody, a która zostaje przez tę metodę wykonana z parametrami, które są efektem działania jakiejś asynchronicznej akcji.
Swoją drogą, nie:
var cords = new Object();
a po prostu:
var cords = {};
-
Wojciech Mazurek:
Piotr Koszuliński:
Jako że sam język mocno odbiega od większości innych, to trzeba się sporo dowiedzieć, bo go nie kaleczyć.
No wlasnie sie czegos ciekawego ($%@%^#@) dowiedzialem ;(
Przygotowalem sobie procedurke - dzialala - poszedlem na kolacje wrocilem i nie dzialala.
$.Get - "Obiekt nie obsługuje tej właściwości lub metody"
Tylko czemu przedtem dzialalo ? A moze mi sie zdawalo....
Musiało Ci się zdawać. Nie mogło działać. To podstawowa i ŚWIETNA cecha JS - rozróżnia wielkość znaków.
I szczerze mówiąc nie wiem jak można na to narzekać i na to, że jest charAt, a nie charat. Taka konwencja została przyjęta i raz, że uważam że jest dobra, dwa że nie widzę żadnego argumentu przeciw.
-
1) Pamiętaj, że w JS nie musisz czyścić pamięci. Więc "samobójstwo" obiektu Image nie jest Ci potrzebne. GC to wyczyści.
2) Jeśli masz ciąg wywołań asynchronicznych, to żeby nie zagłębiać się ciągle w kodzie funkcja w funkcji, to pomyśl własnie o tych promise'ach z jQuery. To nie jest banalna koncepcja, ale bardzo pomaga jak się ją zrozumie.
3) Generalnie... to co chcesz zrobić można w JS-ie zrobić bardzo ładnie, albo tragicznie :D JS niestety ma to do siebie, że nie zmusza do pisania choćby "sensownie". Jako że sam język mocno odbiega od większości innych, to trzeba się sporo dowiedzieć, bo go nie kaleczyć.
-
Wojciech Mazurek:
zawsze zwraca pusta wartosc ?
Myślę, że żadna z metod nie działa tak jak myślisz :) Generalnie, nie obsługuje się asynchronicznych callbacków, ani tak jak próbowałeś, ani w sposób proponowany przez Andrzeja.
Zacznijmy od tego - jeśli nie czytałeś mojego artykułu o zasięgu i closure w JS, to przeczytaj :P Ten albo inny, jeśli mój jest za słaby :P. Wtedy będziesz wiedział, że kiedy definiujesz funkcję, która jest callbackiem dla "$.get" wewnątrz funkcji "Zapytaj", to ten callback zapamiętuje miejsce swojej definicji. Co rozumiemy przez "zapamiętuje"? Ma dostęp PRZEZ REFERENCJĘ do wszystkich zmiennych, które były dostępne w funkcji "Zapytaj". To jest właśnie closure (domknięcie - czyli "domykanie zasięgu"). To samo zresztą tyczy się funkcji "Zapytaj" - ona też zapamiętuje swój scope, którym w pierwszym przypadku jest m.in. zmienna "s".
Czyli w przypadku:
1) Zapytaj domyka "s". Callback domyka to co jest w Zapytaj, czyli też "s".
2) Zapytaj nic nie domyka, callback domyka "sx".
Idźmy dalej. Teraz równie ważna sprawa - $.get jest asynchroniczną metodą. Oznacza to, że po jego wykonaniu od raz wykonywany jest następujący kod. W tym wypadku zwracany jest "sx/s". Czyli Twoja funkcja Zapytaj zwraca pusty string.
Następnie, po chwili, pobierane są dane z serwera, wywoływany jest callback i on ustawia zmienną "sx/s". I teraz zależnie od przypadku:
1) jako że zmienna "s" była zadeklarowana w scopie najwyżej, to jest ona dostępna TERAZ w każdym innym miejscu tego scope'a. Dlatego jeśli w tym samym scopie masz zadeklarowaną np. metodę obsluzDane(), to ta metoda, jeśli wykonamy ją PO wykonaniu callbacka będzie miała dostęp do danych z serwera.
2) jako że zmienna "sx" zadeklarowana została wewnątrz scope'a funkcji Zapytaj, to tylko funkcje zadeklarowane wewnątrz tej funkcji mają do niej dostep. Czyli nasza obsluzDane() nie będzie widzieć tej zmiennej.
Jakie są sposoby z radzeniem sobie z asynchronicznymi wywołaniami?
1) w callbacku dla $.get() wykonuj funkcję obsługującą dane, której przekażesz te dane jako argument - sposób najbanalniejszy
2) jak w przypadku 1. - deklarujesz zmienną w takim scopie, by funkcje obsługujące te dane widziały tę zmienną i wykonujesz W CALLBACKU funkcję obsługującą dane (tym razem już bez argumentów
3) wykorzystujesz tzw. promise'y, dostępne w jQuery - http://api.jquery.com/deferred.promise/ i http://api.jquery.com/category/deferred-object/ pamiętając że $.get zwraca promise'a.
I kolejny raz autopromocja :P. Prowadziłem ostatnio szkolenie i później jeszcze prezentację na tematy związane z asynchronicznością w JS. Tu są slajdy - http://code42.pl/2011/10/09/moje-prezentacje-z-devmeet...
BTW. ZAWSZE używamy "var". Nie korzystaj nigdy z globalnych zmiennych w innym celu niż do definicji głównego API Twojej aplikacji (najlepiej jednego obiektu, typu window.app).Piotr Koszuliński edytował(a) ten post dnia 04.11.11 o godzinie 17:25
-
Wojciech Mazurek:
img.onload = function() { $("#grafika13").attr('src', img.src); }
BTW. nie wiem czy to przeoczenie, czy specjalnie, ale w tej linii też dobrze byłoby postawić średnik. Bo jeśli przypadkiem zacząłbyś następną linię od nawiasu "(", to byś sobie wywołał tę funkcję od razu :) To tzw. ASI - automatic semicolon insertion, które w tym wypadku by akurat tego średnika nie postawiło i potraktowało to jako wywołanie. Zasady ASI są co prawda dość proste (choć widziałem takie przypadki, że naprawdę można się zdziwić) i dlatego niektórzy namawiają aby w ogóle nie stawiać średników... poza średnikami na _początku_ linii zaczynających się od "(" bądź "[". Masakra :P Dlatego wolę stawiać zawsze, ale na końcu.
-
Hej. JS ma zasięg funkcyjny i do tego zasięg statyczny (leksykalny). To drugie to tzw. closure - jedna z najpotężniejszych rzeczy w JS. Warto o nim wiedzieć, ale to trochę za dużo by się rozpisywać na ten temat tutaj :).
Napisałem ostatnio dwa artykuły na ten temat:
Co lepiej wiedzieć o JavaScriptcie cz.1. - typy zasięgu i domknięcia
Co lepiej wiedzieć o JavaScriptcie cz.2. - hoisting, deklaracje funkcji i wyrażenia funkcyjne
W szczególności pierwszy powinien Cię w tym wypadku zainteresować.Piotr Koszuliński edytował(a) ten post dnia 03.11.11 o godzinie 22:10
-
Jeśli Github ma API do edycji pliku z zewnątrz, to byłoby świetne. Bądź - do czego API ma na pewno - możesz wykorzystać Node'a do łączenia się po prostu z repozytorium gita, pobierać przez Node'a listę plików, dany plik, wysyłać do przeglądarki, wysyłać z przeglądarki do Node'a i z node'a do githuba gitem. Pomysł bomba.
O ile oczywiście znajdziesz jakiś DZIAŁAJĄCY moduł do obsługi gita z poziomu Node'a. Ewentualnie... mógłbyś z Node'a gadać wprost do shella - może być nawet prostsze. Dla ułatwienia mógłbyś sobie z wyprzedzeniem wygenerować klucze (nie wymagające hasła) i śmigałoby świetnie.Piotr Koszuliński edytował(a) ten post dnia 03.11.11 o godzinie 20:27
- 1
- 2
- 3
- Następna »
