Намерих си аз едно занимание -> трябва да добавя на едно от устройствата ми WEB страници.

Процесора е RX62N. Пробвах няколко примера - работят но не мога все още да схвана как от веб страницата се връща информацията наобратно.
Тоест имаш поле въвеждаш нещо си(текст, числа и т.н.) натискаш бутон за да се пратят и...
Има ли накъкъв стандартен начин за това?

Най-стандартния начин е в html страницата да имаш форма (form), в нея може да имаш разни елементи и субмит бутон. Като се субмитне сървърът получава get/post заявка с content type - application/x-www-form-urlencoded или нещо от сорта. В бодито са ти стойностите (име на поле = стойност)...

Тишо, това горе с DHTML-а хич не го чети. Само ще те обърка. Поне преди около година мен ме обърка. Ако тръгнеш да се ровиш във всичките високопарни термини и "технологии" на тая велика измишльотина, наречена WEB, и купищата недомислени неща, но за сметка на това писани на който както му скимне, ще ти бръмчи главата поне месец. Всичкото племе, занимаващо се с творенето на тия "технологии" има нужда от един хубав кютек.

Приеми че основно се ползват 2 вида заявки (GET, POST), и толкоз. Или казано простичко - броузера пита, сървъра отговаря с някакво съдържание, с което пък броузера и твоя код, вървящ върху него, може да прави най-различни неща. И си пробвай страницата на всичките по-разпространени броузери, както и на различни степени на увеличение. С IE от 7 надолу хич не се занимавай, ако искаш нещо шаренко, и т.н.

Накратко - супер готин замисъл, и тотално осрано изпълнение, в резултат на което, ако гледаш всеки пиксел, какъвто навик имам аз, се бориш като прасе с тикви, докато го накараш да излиза нормално (забележи не еднакво, а нормално, да изглежда еднакво е невъзможно) на всички броузери, на които искаш да се ползва.

Напълно съм съгласен в всички квалификации и оценки на sparkybg , особено за кютека.

Все пак ще допълня обзора: освен Get и Post е добре всеки, който прави ембендет веб програмиране да си хареса една от AJAX техниките - има ги много, вкл. и постички на по няколко реда. Дори и да не му вика DHTML, е много полезно сайтът, свързан с ембендет техниката да се обновява понякога. При това - без да се презарежда целия. Това "AJAX" е техника, с която се правят заявки към сървъра без да е нужна намеса на потребителя (сайтът, визуализиран на браузъра решава кога да изпрати заявка и какво да прави с отговора).

Не е сложно - малко JS, малко четене хелпове на DOM, въпроси по форуми и свестен дебъгер (Firebug е ОК) - това е от към браузъра.
От към сървъра - каквото ти душа иска: Отговорът на сървъра може да е всичко: от едно число, до сложна структура (естествено, сериализирана, примерно в HTML, JSON, XML или каквото ти харесва, но да е текст, щото минава през HTTP ).
На времето за трансфер на данни ми хареса JSON (щото лесно се трансформираше в обект за JS, ама напоследък XML май е по-популярно, поддържано и четливо).

JSON се поддържа от абсолютно всичко, що поддръжа и JavaScript. То си е де-факто текстово описание на JavaScript обект. То и името му (Java Script Object Notation) означава точно това.

...и може да се спори кое е по-четливо. За мен XML-а е в пъти по-гламав от JSON, а и по-дълъг за един и същ обем информация в него.

За debug - лично за мен вградения в Chrome дебъгер е по-добър. В IE 9+ вече също има вършещ работа такъв. Общо взето като го докараш да върви под Chrome, IE8+, FF и Opera, може да си умерено спокоен (никога напълно ) че ще върви в повечето знайни и незнайни броузъри. Ако искаш да върви читаво и на телефони, таблети и т.н. е отделна тема.

...но всичкото това важи ако ще пишеш скриптове в клиентската част (вървящи върху клиентската машина, в броузера). За съвсем прости страници може и съвсем прост класически HTML. Ако пък скриптове, нещо от сорта на JQuery е според мен абсолютно задължително, в противен случай рискуваш да се бориш като прасе с тикви с всичките простотии на всеки отделен броузер. И за да не се объркаш що е то JQuery, това е просто библиотека, или по-скоро нещо като фреймуорк, с определен набор от функции, които с малко по-голяма сигурност вървят на максимален брой броузери еднакво, или възможно най-еднакво. Хубавото е че се хостват на много места, и няма нужда твоя точно сървър да ги предоставя, стига компютъра, през който цъкаш в страницата на устройството, да има и интернет достъп. Но и да се наложи да ги предоставя сървъра, в компресиран вид са 80к, което не е чак невъзможно дори за Embedded сървър. В краен случай можеш да ги запишеш във външен сериен флаш, щото понеже се и кешират върху клиентската машина, заявките за тях няма да са твърде чести.

...за съжаление модерна хубава страница без JavaScript практически е невъзможно да направиш, което значи че и без JQuery (или нещо от сорта) трудно може да се мине.

Бе, накратко казано, ако няма сериозно да ровиш в тая посока, рови само толкова, колкото да си свършиш работа. Щото останалото е бездна и докато схванеш голямата картинка, главата ще ти пуши здраво. Впрочем, самия JavaScript е на пръв поглед тотално нелогична и отвратителна работа за нормален програмист, пишещ на нормални езици. Ама като му хванеш цаката виждаш че има ужасно хитри нещица вътре.

Толкова многословен съм, защото преди точно година ми се наложи да знам и това, а до тогава WEB не бях пипвал под никаква форма, та още ми е прясно. Толкова безпомощен пред компютъра не се бях чувствал никога. Сега пък се хващам че на всичкото отгоре ме и кефи. А и се оказва че и в това нещата са точно като във всичкото останало програмиране - една малка част от всички правят истинските неща, а останалите просто папагалстват и се правят на велики с високопарни термини, технологии и прочие полюции.

Мисля въпроса за важен и затова ще пиша пак, за да поясня за челивостта: като текст, ако са добре форматирани, вероятно наистина е спорно кое е по-четливо. Но като средства за разработа (среди за създаване/редактиране): редактори за XML има безброй (повечето куци, но са безброй ), а за JSON средствата за подръжка са доста по-малко. Свестни няма или поне аз не знам.
Ползвам тоя (онлайн).
Но е доста трудно да се намери грешка в голяма йерархия.
Повтарям - повечето ми структури са JSON, мога да сложа тук примерче (от простичките):) (пардон - трябваше да го направя като "code", ето):


АМА ЩЕ АТАЧНА и едно истинско (малко му смених нещо, за да е конфиденциално )

А, за редактиране в редактор съм абсолютно съгласен. Но ако ще гледаш текстовия файл в обикновен текстов редактор, всичко си зависи от тоя, дето е писал текстовия файл. JSON-а може да бъде кристално четлив, както и тотално нечетлив, както и всичко друго, касаещо JavaScript въобще. Особено пък за човек, дето никога не е писал на JavaScript, или поне на език, приличащ като синтаксис на него.

Към това, което Sparki написа, мога да добавя -
- всички използвани CSS-и да ги компресираш (търси CSS компресор), така че да се получи един единствен файл.
- всички използвани javascript-отве - също като CSS-a - да станат на един единствен .js файл.
- Изображенията използвани за самия дизайн и иконки - в един файл (после се ползват отделните спрайтчета и се отместват с CSS).
- Добавяй хедър информация, указваща браузъра да кешира всички използвани ресурси (js, img, css).
И на последно място, но не по важност - ресурсите можеш да държиш в компресиран вид (zlib) и така да ги пращаш към браузъра.
Относно xml vs json - json естествено . Нативен за JavaScript-а и с по малък овърхед.
jQuery ми се вижда пресилено за ембедед проект, а и да не забравяме неговата големина.

33k компресирано. А и горе споменах че не е нужно да го предоставя ембеддед сървъра. Може само да се сложи линк към някъде, където е хостнато, например google. Но дори и да го предоставя ембедед сървъра, 33к не е чак непосилно, още повече като се има в предвид колко писане спестява.

Но за прости странички наистина далеч не е задължително.

Tisho предполагам пита за RX. Има RX-ове с 2MB флаш. 33-те килобайта на практика са без значение, ако се сметне че е нужно. А и при положение че се кешира върху клиентската машина, дори и във външен сериен флаш да го сложи, някакво бавене ще има само при първо влизане.

Бе кви скриптове кви щуротии го пращате, той пита просто как работи http като протокол,
не какво тече по него. Едва ли ще тръгне да прави шарении и скриптове, обикновен html
стига за почти всякакви разумни цели и без друго.

Тишо, прочети rfc1945 (http 1.0) - най-старата публична версия и съответно най-бързо
се разбира като за начало поне по мой спомен.
После има http 1.1 подобрения , rfc2068-> rfc2616 -> rfc2817,
но 1.0 е най-добро за първоначално разбиране (то е и съвсем елементарно но е казано с доста
приказки). Подобренията си идват на мястото лесно после.

Ще ти трябва навярно да разбереш и MIME, rfc1521 ми беше на мене първото, коя от
следващите версии съм чел и коя не не знам вече, много са. Но то е над http-то.

Че за прости статични страници не трябва нищо повече от обикновен HTML съм съгласен. От там нагоре обаче и най-елементарното променяне на съдържание на поле на екрана няма как да се случи без скрипт освен да презаредиш цялата страница.

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

Какъв е проблема с презареждането? Предполагам става дума за уеб сървър за някакво настройване на параметри. Ако презареждането е общо 2-3К не е фатално "претоварване" нито за mcu нито за кой да е браузър.

Е то не е обемът а това, че някой трябва да натисне копчето на браузера - а със скрипт
може да си обновява параметрите на живо някак. Не бих тръгнал в тая посока докато мога
другояче де, то и това ако го направя така браузърът би получавал всеки път един
image/gif да опреснява и линк карта по него (та да му намалеят шансовете за творчество)
ама VNC е къде по-свястно както го имам та няма да е скоро.