- Еще для кучи. Когда взаимодейтствие идет по схеме "заказчик->исполнитель", то это одно. А когда программу переписывает программист, находящийся в штате этой же компании, то это другое. Программы могут жить годами, а то и десятилетиями.
Ну тут много спорных нюансов:
- 1C наверняка нехило так берет за каждую лицензию за раб место
- Для многих заказчиков зачастую важно иметь возможность зайти в систему хоть с ноутбука в кафе, хоть с телефона, хоть с пылесоса, поэтому именно веб бывает предпочтительнее (а возможно еще и какое-нибудь Android/IPhone приложение под эту дудку можно впарить).
- Многое зависит от продаванских навыков и от платежеспособности заказчика. Я знаю одного ушлого товарища, который годами впаривал системы учета, написанные на VBA+Access. Когда это стало совсем неприличным - он нанял программистов, которые переписали все это хозяйство на ASP.NET.
Я тоже долго дивился, почему заказчики не переходят на 1С.
Наверняка, конечно, есть и под веб готовые системы, но опять же, любая система избыточна, а заказчиков вводит в ступор любой доп функционал, который к их задаче не относится. Т е система должна хорошо и гибко настраиваться.
Но, в целом, я с вами согласен, перед тем, как начинать что-то делать, стоит проанализировать имеющиеся варианты.
А если даже на чистой системе все повторится, то грешить можно разве что на провайдера, что он какую-то дрянь к заголовкам фала дописывает, говорить тогда с ним, но, честно говоря, никогда таких чудес не встречал.
Значит вирус или какое-то сомнительное ПО, попробуйте поднять виртуалку или поставить вторую систему - наверняка на них все будет норм. Следовательно, анализируйте, что установлено. Отключите все подозрительные плагины к бразуерам, откатите систему на тот момент, когда все работало норм, прогоните еще раз нормальным антивирем.
Генерация файла - дело ненадежное, права могут слететь, его может занять другой процесс, что-то глюканет и он сгенерится только до середины, да мало ли что. Когда он генерится на основе данных из базы - в аварийном случае можно просто нажать кнопку еще раз. Если же делать это минуя базу, то труды менеджера в случае чего пойдут насмарку и ему придется все конструировать заново.
Алексей Свечкарь:
>>>Представьте, каким будет SQL запрос для формирования json
Сложно возразить: джоинов и подзапросов будет порядком, придется колдовать с индексами, вьюхами, времянками и т д.
Можно немного облегчить: не генерить json на лету при работе посетителя с формой, а в админке сделать кнопку "Обновить файлы json" и нажимать ее после изменения полей из справочников.
Алексей Свечкарь: Это понятно, что тренинг нужен всегда. Но, одно дело, учить менеджера ставить галочки и нажимать кнопочки, совсем другое - нагружать его техническими деталями, заставлять разбираться его в непонятных текстовых форматах. В одной конторе, где я работал, девушку, далекую от IT, напрягли править какие-то xml, получалось у нее через раз, все равно xml часто был невалидным и приходилось активно ей помогать.
>>>json описание хранится в поле модели "Услуга" в базе данных. И меняется как текст через админку.
Получается, что новое свойство может добавить только программист, вряд ли обычный контент менеджер знает, что такое json и с чем его едят
Алексей Свечкарь: Хранение json в поле БД нарушает ее целостность, хотя, не спорю, многие так делают, а в нек БД даже спец тип поля есть. Лично я бы делал наоборот, хранил данные в БД, а если на клиенте нужен JSON, то сделал бы типа веб-сервиса, который на основе переданных параметров генерил JSON из базы.
Сергей: Так уже написали ниже, что если вывести фокус за пределы сайта, то нажатие тех или иных клавиш (того же PrintScreen) будет уже не отловить через js. Если фотка слеплена из двух, то это тоже не вариант, так как принт скринт возвращает конечный результат, отображаемый на экране, а из чего он получился - юристов вряд ли будет интересовать.