[Слесарь 9]

Не вижу смысла вникать в JavaScript когда все можно реализовать в HTML. Исключение, МК под управлением Linux или Windows, там вопрос метода не принципиален, так как OS по любому грузит.

[theBMV 0]

Некропост, но всё же.

Итак, добился своего. Может кому пригодится:

модифицируем httpd.c в handle_input(struct httpd_state *s) сразу после получения имени запрашиваемой страницы

char *ptr_params;
  
  // get params string from GET line for further parse
  ptr_params = strchr(s->inputbuf, ISO_question);
  if(ptr_params)
    strcpy(s->params, ptr_params+1);

предварительно добавив поле char params[50] в структуру httpd_state

И в handle_output(struct httpd_state *s) в ветке else (то есть параметры принимаются, если запрашиваемая страница существует в ФС) вызываем парсер

//got file, accept parameters
    if(strlen(s->params))
      parse_params(s->params);

Далее сам простенький парсер. Тип принимаемых значений - int (большего мне не требовалось)

typedef struct s_params_table {
  char name[5];
  int *val;
} t_param_table;

#define MAX_PARAM 2
// переменные, используемые нами
int led1 = 0;
int led2 = 0;

const t_param_table par[MAX_PARAM] = {
  {"LED1", &led1},
  {"LED2", &led2}
};

void parse_params(char *params)
{
  char *name;
  char *val;
  
  name = strtok(params, "=");
  val = strtok(NULL, "&;");
  accept_param(name, val);
  do
  {
    name = strtok(NULL, "=");
    val = strtok(NULL, "&;");
    accept_param(name, val);
  }
  while(name && val);
}

void accept_param(char *name, char *val)
{
  if(!name || !val)
    return;
  
  for(int i = 0; i < MAX_PARAM; ++i)
    if(!strcmp(par[i].name, name))
      *par[i].val = atoi(val);
}

Всем спасибо, кто помог или принял участие.

[Quasar 20]

Наполнение надо хранить либо в памяти как статику, либо динамически генерировать.

У меня был так же и упрощенный вариант динамического контента который очень хорошо подходит для МК. В памяти хранятся статические HTML страницы. При запросе той или иной страницы по HTTP, содержимое пропускается через HTML парсер, если в статическом содержимом парсером обнаруживается специальная метка с идентификатором, согласно идентификатора вместо метки подставляется динамический код (например текст с динамической информацией) и далее по HTTP отправляется по назначению. Для экономии ресурсов процессора, чтоб не парсить все запрашиваемые HTML, именовал странички по разному, там где 100% статическое содержимое, давал расширение файла .htm, там где встречаются метки для парсинга, давал расширение .html .

 

 

Это когда браузер гарантированно поддерживает JavaScript. Мне довелось начинать осваивать клиент-серверные технологии на примерах WAP приложений. Это такой формат для браузеров сотовых телефонов начала века, где JavaScript не прижилось.

 

Не хочу обидеть, но это очень дурацкий метод, он не позволяет статический контент сжимать, и что вы будете делать, если например данные необходимо раз в секунду обновлять?

 

Все нормальные, современные браузеры поддерживают JavaScript (и пожалуйста, не путайте JavaScript с Java, это совершенно разные языки, не относящиеся друг к другу ну ни как), в том числе и мобильные. Хотя бы тот минимум, который необходим для работы AJAX. Правильнее делать как написал zöner.

 

проще хранить HTML как статику, а параметры настройки отдавать в JSON (такой вариант и проще отладить на ПК).

 

Данные не обязательно JSON, можно xml или вообще свой формат. То есть, статические данные html лежат в МК и просто выплевываются по запросу, в этих статических данных JavaScript, который после загрузки страницы запускается и грузит уже чисто динамические данные, затем подставляет их в нужные места html страницы с помощью getelementbyid.

 

Плюсы такого метода:

- всю статику можно сжать, а это иногда двукратная экономия;

- данные можно динамически обновлять, перезагружая их AJAX'ом и подставляя в нужные места;

- легко отлаживать;

- не тратиться время МК на парсинг большого количества статики в поиска меток.

 

Данные надо передавать общепринято POST запросом, например на странице два окна ввода и кнопка

 

Код

<form action="demo_form.asp">

First name: <input type="text" name="fname"><br>

Last name: <input type="text" name="lname"><br>

<input type="submit" value="Submit">

</form>

 

Тег <input> поддерживается всеми браузерами и передает данные POST запросом.

 

Тег input ни чего ни куда не передает, это поле ввода с типом type. Что-то куда-то передает тег form и конкретно в вашем примере он передает данные методом GET http://www.w3.org/TR/html401/interact/forms.html#h-17.3

[Слесарь 9]

Не хочу обидеть, но это очень дурацкий метод, он не позволяет статический контент сжимать

А что, в моем методе есть какие-то проблемы со сжатием? Сжимай хоть до, да хоть и после обработчика.

 

Тег input ни чего ни куда не передает, это поле ввода с типом type. Что-то куда-то передает тег form и конкретно в вашем примере он передает данные методом GET http://www.w3.org/TR/html401/interact/forms.html#h-17.3

Поздравляю! Вы классный знаток WEB.

[Quasar 20]

А что, в моем методе есть какие-то проблемы со сжатием? Сжимай хоть до, да хоть и после обработчика.

 

 

Поздравляю! Вы классный знаток WEB.

 

То есть вы собираетесь сжимать в реалтайме микроконтроллером? ;) Статика уже лежит сжатая во флешь контроллера, и она просто отдается web сервером со строкой в http заголовке:

 

Content-Encoding: gzip

 

Поздравляю! Вы классный знаток WEB.

Классные знатоки WEB занимаются WEB разработками, а это всего лишь минимум.

[Слесарь 9]

То есть вы собираетесь сжимать в реалтайме микроконтроллером?

Слушайте, с моим методом можно сжимать хоть процессором/контроллером, хоть держать сжатым в памяти.

В разработанной мной системе в 2005 году, 95% и более контента генерировалось динамически по этому сжимать процессором было вполне нормально. Статически хранилась только главная страница сайта.

 

вы собираетесь сжимать в реалтайме микроконтроллером?

А что, с этим какие-то проблемы и сложности?

Естественно сейчас речь идет о WEB интерфейсе с одним или двумя клиентами. Больше клиентов думаю не требуется для устройств под управлением МК.

 

И еще, поясните, зачем вообще сжимать если это интерфейс к МК ?

Насколько понимаю здесь речь идет о маленькой страничке с десятком динамических текстовых данных, паре кнопок и нескольких полях ввода?

[Quasar 20]

Слушайте, с моим методом можно сжимать хоть процессором/контроллером, хоть держать сжатым в памяти.

В разработанной мной системе в 2005 году, 95% и более контента генерировалось динамически по этому сжимать процессором было вполне нормально. Статически хранилась только главная страница сайта.

 

Сжимать статический контент необходимо для экономии флеш, а не для галочки. Нафига во флеш хранить несжатый контент, а потом тратить еще время на его сжатие? Экономия канала смешная. Да еще и на лету сжимать, портируя для этого например на 8 битный камень gzip, это надо очень себя не любить.

 

А по поводу 95% динамического контента, ну только если у вас очень простое изделие и совсем элементарный внешний вид представления данных. А если полноценная веб страница, с проверкой на клиентской части введенных данных и т. п., с частым фоновым обновлением данных, то тут статический контент будет как раз 95%.

 

Да и вообще, жесткое разграничение динамических и статических данных есть best practice. Так как в этом случае, можно менять внешний вид (статическую часть) совершенно не трогая динамическую (в том числе и С код, который его генерит), проверять верность генерации динамических данных, и правильность построения статической страницы, забирать только динамические данные с железки веб-сервисами или сторонними приложениями для дальнейшей работы с ними, если железка работает в сложной системе. Сейчас, все чаще используют для этого вместо SNMP - HTTP, так как он более наглядный. Ну ладно, вам я так понимаю это совсем не интересно, вы все еще в 2005 году...

 

И еще, поясните, зачем вообще сжимать если это интерфейс к МК ?

Насколько понимаю здесь речь идет о маленькой страничке с десятком динамических текстовых данных, паре кнопок и нескольких полях ввода?

 

Речь идет о разных страничках, и о простых, и о сложных. Подход должен быть один. Сейчас надо две кнопки, а завтра двадцать две. В некоторых моих проектах, в результате развития, страницы с 20 кбайт начали весить по 300-400 без сжатия. Например, из-за того, что появилась поддержка других языков, появился новый функционал.

Изменено 9 июля, 2013 пользователем Quasar

[Слесарь 9]

Речь идет о разных страничках, и о простых, и о сложных. Подход должен быть один.

Каждому свое...

Я лишь занимался перекладыванием философии программирования оконных приложений в область WEB. Если в видовс содержимое выводится во Фрейм, то у меня выводилось в браузер.

И кстати оставаться мысленно в 2005 году не обязательно совсем плохо.

 

Кста, я еще в 2010 заинтересовался WEB интерфейсами к устройства на базе МК, но чтот так и не нашел практического применение. Сделал не менее 5 устройств где есть подключение Ethernet и поддержка HTTP, но возможность управлять устройствами из браузера по интернет или по локалке так и не оказалось еще востребованным. Ну не интересно это. Правильней делать специальное клиентское приложение для PC или клиентский терминал под управлением того же МК без всякого HTMLя.

[Quasar 20]

Кста, я еще в 2010 заинтересовался WEB интерфейсами к устройства на базе МК, но чтот так и не нашел практического применение. Сделал не менее 5 устройств где есть подключение Ethernet и поддержка HTTP, но возможность управлять устройствами из браузера по интернет или по локалке так и не оказалось еще востребованным. Ну не интересно это. Правильней делать специальное клиентское приложение для PC или клиентский терминал под управлением того же МК без всякого HTMLя.

 

Ну тут смотря какая аудитория. Те, кто используют и сами настраивают всякие Wi-Fi роутеры хотят видеть веб-интерфейс. Всякие суровые сис. админы любят telnet консоль или ssh. Приложение - ставить надо, плюс не надо забывать про поддержку ОС. У меня дома windows машин нет, либо Mac, либо Linux. В некоторых организациях используют только Linux. Писать приложение для всех платформ не очень.

[Слесарь 9]

Устройства на базе МК зависимые от ПК, тож как то не очень... Устройства на базе МК разработанные непосредственно для ПК не в счет, там понятное дело ПК есть по определению.

Интересно рассмотреть сферы применения WEB интерфейсов в отрыве от систем ПК, например бытовая техника/автоматика, автомобили, охрана, сигнализация, энергетика, тепло-вода-снабжение.

[Quasar 20]

Интересно рассмотреть сферы применения WEB интерфейсов в отрыве от систем ПК, например бытовая техника/автоматика, автомобили, охрана, сигнализация, энергетика, тепло-вода-снабжение.

 

Например.

Есть устройство на МК, которое меряет температуру (или чего-нибудь еще) и выводит свои показания на Web страницу. Данное устройство может использоваться вместе с ПК, человек удаленно заходит на веб-страницу и смотрит на показания температуры (или чего-нибудь еще). А теперь, задача, оснастить такими девайсами 100 помещений. Человеку через ПК заходить уже не с руки на 100 девайсов. Все данные надо сливать в какой-то единый центр и анализировать. Пишется софт, который являясь http клиентом собирает данные, так же заходя на все железки по Web интерфейсу. Если есть возможность забрать данные в xml или JSON виде, то их парсинг проще пареной репы, если же данные уже вшиты в веб-страницу (озвученным вами выше методом) и отдельно не забираются, то надо писать сложный парсер страницы. Любые изменения на странице, могут привести к изменениям в парсере, а это уже не best practice.

Изменено 9 июля, 2013 пользователем Quasar

[Слесарь 9]

Я вспомнил, тут недавно поставили на предприятии автомат который длиной более десятка метров и содержит не менее 50 управляемых МК исполнительных механизмов и датчиков. Так вот, наверное не плохо было бы выводить настройки и данные датчиков этого аппарата на ПК в браузер, очень высокая степень совместимости с разными ПК получилась бы, но нет же, эти разработчики аппарата замастрячили специализированный терминал с сенсорным дисплеем связанный с мультиконтроллером аппарата по специальному промышленному интерфейсу. Спрашивается, почему делается именно так? Не проще ли поставить обычный ПК, развивать WEB и в этой сфере?

 

А теперь, задача, оснастить такими девайсами 100 помещений. Человеку через ПК заходить уже не с руки на 100 девайсов.

Для 100 помещений не помешает поставить какой-нить сервак опрашивающий сотню датчиков. И именно сервак будет генерировать WEB контент обычными средствами для множества пользователей.

 

Недавно был у знакомых, у них районное охранное предприятие, с сотни сигналок и тревожных кнопок собирает данные ретрансляционный блок с подключением к ПК по COM порту. На ПК работает специализированное приложение собирающее данные от сигналок и выводящее данные оператору на монитор. И это правильно!

А вот по WEВ они наверное намучились бы копаться в списках сообщений охранной системы и в настройках. хорошо что это обычное оконное приложение.

[Quasar 20]

Для 100 помещений не помешает поставить какой-нить сервак опрашивающий сотню датчиков. И именно сервак будет генерировать WEB контент обычными средствами для множества пользователей.

 

Так вот после того, как сервер соберет все данные с датчиков, как-то их обработает, он выведет данные опять в виде веб-морды (уже своей), например собрав все показания в таблицу, построив график изменения и так далее.

 

 

Если делать датчик с веб-интерфейсом, то его можно использовать и как standalone решение, так и как решение в составе системы. Для решений в составе системы конечно часто используют SNMP протокол, и есть готовые решения серверов опрашивающих датчики, но для работы с SNMP нужен доп. софт на ПК и адрес SNMP ресурса 1.2.3.2322.12345.542352 человеком совсем не воспринимается, в отличии от http://192.168.1.1/temperature.xml

[Слесарь 9]

Так вот после того, как сервер соберет все данные с датчиков, как-то их обработает, он выведет данные опять в виде веб-морды (уже своей), например собрав все показания в таблицу, построив график изменения и так далее.

Все известные мне реальные системы используют специализированные приложения для сбора и удобоподобного отображения собранных данных. WEB в основном нужен когда множество клиентов, а у реальных систем сбора данных и управления обычно один оператор на которого возлагается ответственность с записью в журнал, WEB просто не нужен.

 

Лично я делал систему со множеством клиентов для школ города, это был удаленно доступный по WEB, ПК и мобильники, для родителей и учеников, классный журнал. В каждой школе оператор вводящий данные с журнала по WEB, и родители смотрящие классный журнал по WEB или WAP на мобильниках. Систему обслуживает один сервак с Виновс VC++ приложением + MSSQL.

[Quasar 20]

Все известные мне реальные системы используют специализированные приложения для сбора и удобоподобного отображения собранных данных. WEB в основном нужен когда множество клиентов, а у реальных систем сбора данных и управления обычно один оператор на которого возлагается ответственность с записью в журнал, WEB просто не нужен.

 

Необязательно для этого. В автономных системах, где оператор не сидит постоянно за компом, сам комп убран от шаловливых ручек, и работает в режим 24/7/365, и возможно даже под охраной ;-). Зачем сидеть человеку и наблюдать за температурой? Случился сбой, пришла СМС, mail, другой вид оповещения ответственному лицу, он начал принимать меры.