Alex XYZ

Программирование вторично. Нужно тренировать своё видение решения. Решение - это полный набор технологий, которые обеспечивают желаемый сервис пользователю. И программирование только часть такого сервиса. Если какой-то "дядя", который продумывает архитектуру приложения ошибётся и перекинет проблему на программеров, то лично вы в проекте будете иметь много головной боли.
Поэтому не забывайте подтягивать админку, поучитесь настраивать сервера, контейнеры приложений и т.д. Иногда программирование начинается через день, неделю и более после тестирования архитектуры.

Php через Apache httpd работает. Не полный стек собираете. Для разработки локально вам вряд ли понадобиться nginx (Хотя все зависит от задачи).

Попробуйте так:
block1.onclick = this[ 'fun'+func ];
Согласен, что способ вызова странный, но иногда такое бывает нужно.

Если все пары ключ/значение раскиданы по строкам, то регулярными выражениями, между третьей и последней кавычкой заменить все кавычки на \" или ' (на ваш вкус)

Есть такой термин "карта кликов", "тепловая карта кликов": https://habrahabr.ru/company/altweb/blog/224847/

Если проект у вас вообще с одной формой, то не стоит заморачиваться со spring по двум причинам:
1. Изучение Spring у вас займёт времени больше, чем сам проект.
2. Spring автоматизирует действия, в которых вы ещё не очень разбираетесь. Это как изучать angular, не понимая JavaScript.
Лучше освоить логику работы сервлетов, на уровне обработчиков запросов, потому что все Java-фреймворки работают через них.
Tomcat нормально подойдёт.

Почему вы решили, что эти фреймворка пилят бизнес-логику? Бизнес-логика это движение только данных. Перечисленные вами фреймворки только связывают интерфейс с данными, предоставляемые бизнеслогикой. Грань между бизнес-логикой и интерфейсом - смена интерфейса. Если интерфейс можно поменять без изменений на стороне backend-а (например с HTML на WPF), то разделение выполнено правильно.

Посоветую всё-таки начать с декомпозиции задачи, т.к. сбор данных - одно, визуализация - другое. Не факт, что вам вообще сильно нужно программирование, т.к. если сможете загнать данные в какой-то формат (или БД) без программирования, то отобразить их сможете даже в Excel через источники внешних данных. Посоветую пока не углубляться в программирование, а постараться решить задачу малыми усилиями.
На странице https://www.siemens-pro.ru/components/s7-300.htm достаточно много информации. Меня немного повеселила такая инфа в одном из документов (видать очень давно разрабатывают эти контроллеры, что в общем-то характеризует их весьма положительно):


Ну а если без шуток, если у вас есть доступ к контроллерам siemens, то вроде как не проблема снимать с них показания и складывать их в БД MSSQL (может даже бесплатный MySQL). Главное получить данные с контроллеров. Эксперименты с отображением можно отложить на потом.

>> Я пишу десктопное Windows приложение и хочу прислать клиенту тестовую версию
Такие вопросы должны быть прописаны в договоре. Что предоставляется, на каких этапах. По идее акт приёма-передачи. У вас есть какие-то официальные договорённости или всё на честном слове?

В принципе понимание правильное. Почитайте ещё про многоуровневую модель OSI: https://ru.m.wikipedia.org/wiki/Сетевая_модель_OSI
Есть общий протокол работы с протоколами на низком уровне - ASN.1: https://ru.m.wikipedia.org/wiki/ASN.1
Для просмотра http-протокола используйте fiddler (www.telerik.com/fiddler) . Он показывает всю изнанку HTTP(S).
Ну а логику работы по протоколу каждый производитель обеспечивает сам. Протокол только описывает как должен производиться обмен, но как это реализовывать каждой стороне протокол не регламентирует. Поэтому реализация протокола остаётся на совести производителя ПО или оборудования.

>> Реляционная база подходит или стоит посмотреть в сторону NoSQL?
Хранить первичные данные в реляционной базе правильно, а изменения, которые делают сотрудники (версионность) записывать в отдельную JSON-сущность и складывать в отдельную таблицу. Дело в том, что бизнеслогика может требовать возможности работы с транзакциями, а в NoSQL они поддерживаются только на уровне документа (ElasticSearch, Mongo). Если во время работы вам потребуется откатить изменения в нескольких сущностях, то NoSQL вам этого не обеспечат.
Есть вариант скрестить NoSQL и реляционные базы - использовать JSON в MySQL. Но тут будет другая проблема - проверка схемы записываемых данных. Нетривиальная задача для MySQL. В общем, NoSQL на сегодняшний день ещё сыроват и для применения в проектах над ним надо попотеть. В Mongo схема вроде как есть, в ElasticSearch вообще жесткач по схеме (раз вы задаёте вопрос, то точно с ним не сталкивались и уверяю, что на изучение схемы в Elastic вы потратите время не меньше, чем на сам проект)

Вчера как раз отвечал на похожий вопрос с версионностью в MySQL: Как сделать версионность как на вики?

Что касается версионности, то тут есть ещё один момент - как защитить сущности от перезаписи другим пользователем? Основываясь исключительно на своём субъективном мнении я делаю инкрементируемое поле (скажем, version) для каждой сущности (группе значений, которых я принимаю за сущность), значение которого я отдаю при select-е из базы. При сохранении сущности клиент обязан предоставить этот индекс. Если индекс не менялся, то запись разрешена. Как только происходит запись сущности, то я инкрементирую это поле и если другой человек тоже попытается перезаписать данные со старым значением поля version, то программа ему не позволит это сделать (это очень примитивный способ блокировки, очень отдаленно напоминающий git. Там используются хеши, ну а я все упростил до безобразия) Проверка значения поля version делается в триггере, он же и отменяет процесс записи, если версии не совпадают (чего как раз нельзя сделать в чистой NoSQL). Можно было бы сделать как в 1С блокировку чтения, но для программ не уровня 1с имеем кучу геморроя при реализации.

Что касается Excel и Word, то читайте описание формата OOXML и смотрите библиотеки по работе с офисными форматами. Для Node не знаю, но для Java и C# есть очень мощные, если не хотите разбираться с OOXML.

Остальные сущности по бизнеслогике вы описали нормально. Лично я бы в постановке задал бы несколько вопросов непосредственным исполнителям этой бюрократической процедуры, а так вроде все норм.

Не работал с бухгалтерскими базами, но для своей базы MySQL хранение истории изменений использую JSON. Есть отдельная таблица history с полями - table_name, table_id и history (JSON) с данными типа массив [], в который добавляются записи формата JSON, за которыми производится наблюдение. На пользовательской таблице висят триггеры на добавление, изменение, удаление. Как только в пользовательской таблице производятся изменения, то триггеры записывают изменения в таблицу history. Это позволяет отслеживать всю историю работы с записью от момента создания, до удаления не вставляя код во всякие процедуры или бизнеслогику, а работая абстрактно только средствами базы.

Если у вас задача тестировать upload файлов через форму, то генерировать http-запросы выгрузки файлов можно не только через браузер. Выгрузка файлов - это стандартизованная процедура http протокола, а не просто фишка браузера. Называется multipart form data: https://ru.m.wikipedia.org/wiki/Multipart/form-data Сгенерировать такой запрос как через curl, fiddler, так и на разных языках, например c#: https://stackoverflow.com/questions/27425043/uploa... и это позволит вам выполнить даже нагрузочное тестирование выгрузки файлов на сервер.