"CSS и javaScript в отделни файлове извън HTML, което не е ОК"

Много добре знаем, че от гледна точка на "добрите практики" не е ок, но за целите на едното елементарно домашно е хипер удобно всичко да ти е в един файл, без да се ровиш излишно из файлчета ;)

Не съм на това мнение. Според мен добрите практики трябва са се спазват винаги. 

Примера, който ще дам може би не е най-удачния, но престави си едно издателство, което издава голяма книга и малка книга.  Това значили, че качеството на малката книга трябва да е по-лошо?

Аз пък съм на мнение, че в случая с едното домашно, в което има някоко реда HTML, три реда CSS и 20-тина реда JS, ако човек тръгне да спазва дословно "добрите практики" се получава така, че все едно е тръгнал да "гърми комара с оръдие" (Конфуций)...

"Според мен добрите практики трябва са се спазват винаги."

Така е! Затова и се наричат "добри практики". Но пък според мен, човек не трябва винаги да върши нещо, просто защото така повелява канона или така трябва (един вид на сляпо), а да вниква във всяка една ситуация, да се нагажда според случая и да преценява, кое е най-оптималното и подходящо. А именно, в случая не става дума за обемен проект, в който разделянето на кода спрямо "добрите практики" би било ключово и много важно в много, много аспекти, а говорим за задачки от по няколко реда... То само времето, човек да обособи всичко в отделни фалове и да прескача между тях ще му отнеме излишно време, какво остава, ако иска да го шерне или после пък като трябва да се проверява, вместо човек да хвърви един поглед и сичко да му стане ясно веднага, ще трябва да отваря един път css файл, втори път js файл и тн и тн...

Нито кодът е обемен, че да се изгуби човек защото не са спазени "добрите практики", нито тапърва трябва да се упражняваме в тях или да убеждаваме в тяхната полезност, Ниво 2 сме все пак...Аз поне лично не бих си позволил да намаля оценката на някое домашно, защото нещата са в един файл...Да, бих го посочил в коментара си, за всеки случай, но ми е пределно ясно, че всеки един колега от Ниво 2 е наясно с "добрите практики" и ползата от тяхното спазване при работа... В случая с тези домашни, от тях просто няма реална полза, защото кодът е от по няколко реда.

"Примера, който ще дам може би не е най-удачния, но престави си едно издателство, което издава голяма книга и малка книга.  Това значили, че качеството на малката книга трябва да е по-лошо?"

Ами зависи за какво "качество" говориш...Ако говориш за качеството на печата, качество на хартията, гланца на корицата, мастилата...? Или за "качеството" на оформлението на книгата - примерно по-малката книга да е оформена по-лошо, да кажем корицата й е сложена някъде в средата, или главите в нея да са разбъркани и да започва самата книга от 3та глава? Ако това имаш в предвид, тук не става дума кодът от домашното, който да е събран накуп в един HTML да бъде с кофти качество, или пък някой като отваря style таг в него да буха java script кода си и да прави мазаляк навсякъде....!!!

Принципно за печатниците няма значение книгата "голяма" или "малка" е, а е важно количеството на тиража. "Малката" книга може да се изпечата в тираж 50 000, а "голямата" - в 50. Понеже даваш примера точно с издателство, което печата книги. Като човек, който е работил дълги години в печатни медии, ще ти кажа, че ако имаш една "голяма" книга и една "малка" книга, ако "малката" книга е в малък тираж, печатницата дори няма да пусне да загрява "голямата" машина, на която се печатат "големите" книги и поръчки, тъй като това за тях е като да "гърмиш комара с оръдие" и не им е изгодно нито като време, нито като консумативи за машината... Просто ще пуснат "малката" книга на "по-малката" машина, за да си спестят време и ресурси, без това да отнеме от качеството й.

Зачистването се получава, защото <button> има type = submit по подразбиране и при натискане автоматично ти събмитва данните от формуляра към посоченото в action = "...". Ако много държиш да ползваш <button> трябва да му смениш типа: <button type = 'button' >.... или да ползваш <input type = 'button'

На втора задача не разбрах какво имаш предвид "да зареди JSONа локално". JSON -ът е форматиран правилно, само че трябва да се изтрият външният комплект кавички от док-файла. При мен вмъкването на този JSON, без редакции, в инпут текстово поле се разчита без проблем.

Аха схванах идеята за бутона. Наистина като  направи събмит е логично да ми презареди страницата и да зачисти промените. За втора задача локално имам в предвит да си сложа JSON-а в е идин файл data.json и ot там да си го пaрсна с jQuery. Chrome реве, че това е секюрити проблем(да достъпвам данни отдалечено, щото горкия от къде да знае че съм си на мойта машина) и ми иска authentication какъвто аз няма как да направя. За firefox достъпа до файла не е секюрити проблем и го позволява, но не харесва формата. Пробвах какво ли не, то какво има и да се пробва де. Формата за json си е един и е елементарен. махам външните кавички и... същата история. Ще споделиш ли решение как си го преборил :)

Ето го решението ми: нищо особено. Вмъквам зачистения от външните кавички JSON в едно инпут текст поле, с присвоено действие при излизане от полето. след това обхождам с два вложени each().

Грешката ви е на 17 ред, не подавате променливата cls, a стринга 'cls'. По този начин се опитвате да селектирате 'cls', който не съществува в DOM дървото.

Първо пробвах само с променливата cls, но не работи. Преработих го на стринг, за да указва, че се има предвид ".bird", т.е. класът "bird".

Така ли трябва да е:

        var cls = classInput.val();
        var color = colorInput.val();

         $('cls').css('background', color)

Защото така също не работи или пропускам още нещо?

cls = "." + cls;

$(cls).css('background', color), така работи. :)

$.getJSON е функция, която прави асинхронна заявка и тя не блокира изпълнението на моментния код. Функцията, която подаваш като втори параметър на getJSON, е callback, който ще се изпълни едва след приемането на отговор от сървъра. Това отнема време и е невъзможно да приключи преди интерпретатора да е стигнал до console.log(myItems)

В такива случаи ще искаш да работиш с myItems само в callback-a. Всеки код, който зависи от тази заявка, трябва да бъде извикан от/в този callback.

Асинхронният код не е толкова приятен като синхронния. Затуй jQuery са направили това чудо Deferred.

PS: Има начин да правиш синхронни заявки точно с такива цели, но е силно препоръчително да не го правиш, защото може да предизвика зацепване на сайта.

PS: Най-добре си добави break point при myItems = json и console.log(myItems), за да видиш за какво иде реч.

http://fixingthesejquery.com/#slide42

1-ва си мисля, че е точно това, което си мислиш. Поне аз така я направих. За 5-та си мисля, че трябва нещо от рода:

$.fn.grid = function () {

    var addRow = function addRow() {
        console.log('row added');
    };
    var addHeader = function addHeader() {
        console.log('header added');
    };

    return {
        addRow: addRow,
        addHeader: addHeader
    }
};

var table = $('#myGrid').grid();

table.addHeader();
table.addRow();

Разбира се функционалностите не трябва да са принтиране - това е само за демонстрация, че работи. Реално методите на обекта би трябвало да работят върху .this, което е нашата таблица.

Да, 5-та и аз така си я представях.

Обаче все още не ми е ясно на 1-ва като код какво се иска. Да си измислим някакви елементи и да ги сложим с двете функции ли? Защото условието е така написано, че излиза, че скрипта трябва да добавя тази фунцкионалност, а тя си я има наготово в библиотеката. Това ме обърква.

Възможно е, но понеже е с 10 думи написано едва ли е задача за терминатори и сигурно се иска най-простото. Хубаво ще е да да чуем и други мения. Аз не се бях замислял до сега, че може да се иска нещо друго.