[AlexandrY 2]

Скажем есть embedded WEB сервер умеющий читать и отдавать HTML  и другие файлы со своей файловой системы.
Сервер умеет парсить и выделять компоненты запросов GET и POST и генерить по ним и отдавать динамически сформированные JSON файлы с данными.
Имеет базовую аутентификацию.  
Никакие PHP, JS, Python и т.д. скрипты на своей стороне сервер выполнять не умеет и не хочет (мало динамической памяти) .
Какую технологию можно порекомендовать для разработки WEB интерфейса к такому серверу? 
Какие фреймворки , какие IDE?  jQuery, React, AngularJS, AppML, Bootstrap,  ... ? 
 

[Stepanov 8]

Делал лет пять назад пару таких устройств, с RNDIS (рекомендую, удобная технология, не тяжелая, надёжная). HTML страницы старался минимизировать, писал вручную, просто на HTML, GET разбирал ручками в коде программы. Это довольно неудобно, но ничего что былобы специально заточено под встроенные приложения не нашел, в частности чтобы оно куски кода на Си генерило. Относительно недавно появился в частности "Mongoose", я его сам не ковырял, сказать не могу, но наверное это удобнее чем в рукопашную.

https://habr.com/ru/post/321430/

[Eddy_Em 1]

Я бы порекомендовал использовать то же самое, что и на ПК: написать на С или С++ простой сокет-сервер, который будет играть роль и веб-сервера, отдающего при обращении на порт 80 странички, и fastCGI-сервера, обслуживающего POST/GET-запросы на определенный порт. Вот с аутентификацией будет плохо, потому что лично я не представляю себе, как портировать ssl на STM32. Или, может быть, есть уже какие-то простенькие порты?  Тогда можно работать по https и использовать простейшую базовую аутентификацию. Ну или пароль/логин передавать POST-запросом из формы авторизации.

P.S. На гитхабе полным-полно tinyCGI библиотек для обслуживания запросов и работы с "печеньками". Но это и так достаточно просто, лучше самому за два-три вечера написать.

Изменено 9 апреля, 2021 пользователем Eddy_Em

[AlexandrY 2]

12 minutes ago, Stepanov said:

Делал лет пять назад пару таких устройств, с RNDIS (рекомендую, удобная технология, не тяжелая, надёжная).

У меня есть и RNDIS и WiFi одновременно. 
Но WEB сервер менять не хотелось бы. 
Речь скорее о том как сделать responsive WEB средствами клиентской стороны. 
Т.е. о технологии создания страниц с использованием JavaScript которые бы подстраивались под любые экраны смартфонов и компьютеров и выглядели бы везде одинаково.
А то вот взял тут jquery.mobile,  а с ним чекбоксы в разных броузерах имеют разный вид. 
    

[Ozone 2]

Так bootstrap хороший широкораспространенный фрейморк - это типа к верстке относится.

Касательно самого веб приложения на стороне клиента, то Vue JS  или React.  Vue JS проще.  Но смотря что там вообще нужно на странице, возможно Vue / React и не нужны вовсе.

[x893 35]

Да любой фреймворк можно использовать, если памяти хватает под статические файлы (с gzip или deflate сжатием). Динамические - на С или С++ руками и головой.

 

Заказываете любому веб дизайнеру, смотрите в разных системах, платите денеьги и получаете счастье за три копейки.

Или долго и нресчастливо тыкаете мышью/кнопками в любой IDE (100500 вариантов).

 

[jcxz 184]

2 минуты назад, x893 сказал:

Да любой фреймворк можно использовать, если памяти хватает под статические файлы (с gzip или deflate сжатием). Динамические - на С или С++ руками и головой.

Как думаете: Можно ли рассчитывать, что и ныне и присно и сейчас и в будущем любой браузер (под какой ОС на каком девайсе бы он не жил), обязательно поддерживает и будет поддерживать оба этих алгоритма (и сообщает о них в заголовках HTTP)? Что в какой-то не очень прекрасный момент "Accept-Encoding: gzip, deflate" внезапно не канет в лету?

[x893 35]

 

2 minutes ago, jcxz said:

Как думаете: Можно ли рассчитывать, что и ныне и присно и сейчас и в будущем любой браузер (под какой ОС на каком девайсе бы он не жил), обязательно поддерживает и будет поддерживать оба этих алгоритма (и сообщает о них в заголовках HTTP)? Что в какой-то не очень прекрасный момент "Accept-Encoding: gzip, deflate" внезапно не канет в лету?

Но что-то другое будет. Сделаете другую прошивку и закачаете её.

И опять будет счастье.

Есть место - храните без сжатия.

Какие проблемы ?

[AlexandrY 2]

1 hour ago, Ozone said:

Так bootstrap хороший широкораспространенный фрейморк - это типа к верстке относится.

Касательно самого веб приложения на стороне клиента, то Vue JS  или React.  Vue JS проще.  Но смотря что там вообще нужно на странице, возможно Vue / React и не нужны вовсе.

А сравнивали bootstrap и jQuery Mobile ?
Они вроде как под одно и то же заточены.  

Но у jQuery Mobile есть такая фишка как https://jquerymobile.com/download-builder/  которая минимизирует загружаемые скрипты.
Ведь в микродивайсах есть такая проблема как отсутствие SD карты, т.е. все сопутствующие скрипты и css файлы надо помещать во Flash.
Причем сослаться на внешний CDN (content delivery network ) не могу, дело происходит в изолированной локальной сети.
Или в вашем случае это все не имело значения? 

38 minutes ago, x893 said:

Заказываете любому веб дизайнеру, смотрите в разных системах, платите денеьги и получаете счастье за три копейки.

Тут дел на пару дней. Какой дизайнер. 
Перехожу просто с технологии SSI (server side includes) на динамические страницы.
SSI работало просто и надежно, не требовало никаких скриптов. Спец утилита генерила все нужные страницы автоматом.  
А теперь в связи с тем что скрипты везде включены по умолчанию, не модно делать статику. 
И пробую сэкономить на парсере. Вместо парсинга SSI применить парсер JSON, который и так применяется в MQTT.
Т.е. в WEB-е применить те же информационные юниты что и при общении с MQTT брокером. 
Простая утилитарная задача, но достаточно комплексная. 

[Ozone 2]

12 минут назад, AlexandrY сказал:

А сравнивали bootstrap и jQuery Mobile ?

К сожалению нет 

[AlexandrY 2]

Just now, Ozone said:

К сожалению нет 

Сейчас попробовал их смешать на одной странице. 
Полный облом. Вместе не работают. Компоненты bootstrap просто не отображаются.

[mantech 33]

20 минут назад, AlexandrY сказал:

Вместо парсинга SSI применить парсер JSON, который и так применяется в MQTT.

Можете вменяемо объяснить, зачем? Под вменяемостью я подразумеваю "данная технология вскоре перестанет работать", все остальное "модно-молодежно"- фтопку, имхо...

Изменено 9 апреля, 2021 пользователем mantech

[x893 35]

2 minutes ago, mantech said:

Можете вменяемо объяснить, зачем? 

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

[mantech 33]

28 минут назад, AlexandrY сказал:

И пробую сэкономить на парсере.

У вас же по 300КБ выделяется только ОЗУ на сетевой стек, к чему копеечная экономия??

5 минут назад, x893 сказал:

Ну нравится человеку json.

Ну пусть тогда и php туда засунет, чего ж процу простаивать-то Как-то баловался, засовывал простенький Си-подобный интерпретатор, даже работало)))

Изменено 9 апреля, 2021 пользователем mantech

[AlexandrY 2]

1 minute ago, mantech said:

Можете вменяемо объяснить, зачем? 

JSON де-факто стандарт хранения данных в embedded. А SSI требует побайтно прошерстить каждый html файл с подстановкой перед отправкой.
Причем подстановка идет HTML тэгов.
Эт вызывает необходимость при программировании на С думать о дизайне на HTML, что приводит к потере производительности.