Куски html/css/шаблоны я храню в SO10 текстах — так проще потом править.
Ваш набор css/html можно было просто загнать в текст и заменой placeholder'ов подставить нужные значения.
Смесь переводимых текстов (параметры отчета) и непероводимых (th) в одном значении — это фу.
Объявление переменных в теле кода, а не в начале — фу (тут так принято). Тогда уж лучше использовать inline объявление, если версия позволяет.
раздутыйкакиндюкабапер mode off*
Не оценивайте мое брюзжание как критику. Дерзайте. Учитесь. Делитесь опытом.
Я не эксперт в Физике, Химии и Биологии, но на ум приходят следующие мысли.
1. Установка большого количества солнечных батарей закроет от солнца приличный кусок поверхности земли. Соответственно растения, а потом и козявки переползут на солнечное место, подальше от батарей. Поэтому, слова
Миссис Манн рассказала, что лично видела, как деревья и трава вокруг солнечных панелей становятся коричневыми и умирают, потому что не получают достаточного количества солнечного света.
на мой взгляд не такие уж и глупые. Подойдите к любому забору и посмотрите с северной стороны много ли там чего растет?
2. Мне достоверно не известно влияние электро-магнитного поля на человека, да и ученые точно этого не знают. В доме много техники — этого не боюсь. Однако я, как и многие другие, совершенно не стремлюсь жить рядом с высоковольтными линиями или подстанциями.
Кидайте в меня тапками, но, по-моему, учительница не так уж и глупа.
Лучше вообще не оборачивать, по крайней мере руками. Почитайте про data binding. По сути все тот же «всемогущий javascript», но сильно упрощает и ускоряет разработку.
ИМХО, то, что ваш сервер в одном ответе возвращает разнородные данные (подписчики и новости) уже неправильно.
Да и пункты у вас по сути не отличаются. Ответ с сервера и обработка Javascript.
Разница только в том, кто оборачивает ответ в HTML, сервер или клиент — вставляет в любом случае JS.
Для вас поясню. В связке Apache+PHP — Apache выполняет роль Web сервера, а код, написанный на PHP роль сервера приложений (бизнес логики). На PHP можно написать скрипты, которые будут работать и без Apache.
Я привет пример с XAMPP, так как это наиболее простой и доступный пример для построения клиент-серверной архитектуры (free или low cost). Я много лет работаю с приложениями от SAP и встречал более сложные схемы.
web client -> load balancer -> n x web server -> load balancer -> n x app server -> DB cluster
Поэтому достаточно четко понимаю разницу между web server и app server — физически это могут быть не только разные приложения, но и разные машины.
Либо у вас не очень много опыта в проектировании и разработке корпоративных web приложений.
В корпоративных приложениях. Web-сервер отвечает за предоставление данных пользователю в конечном виде. Сервер приложения отвечает за бизнес-логику. Строго говоря сервер приложения может работать и без WEB сервера, планируя задания и отвечая за интеграцию со сторонними системами.
Даже на примере XAMPP должно быть очевидно, какую роль выполняет Apache, а какую PHP.
По поводу своих контролов очень просто.
Приложение на английском языке должно запускаться у клиентов по всему миру.
Отгадайте на каком языке покажут контролы браузеры в разных странах.
Отгадайте, какие региональные настройки будут в стандартных контролах.
Кстати, у dojo тоже куча своих контролов. Нафига?
Ну а по поводу
dojo на порядок круче, богаче, модульнее, продуманнее. документация и примеры в сравнение не идут.
Как же можно сравнивать 2 фреймворка, если один из них вы точно не знаете?
Зря вы так… Посмотрите сколько к вам вопросов в комментариях. В данном посте вам не очень удалось описать методологию.
Прочитал описание вот тут: accountology.ucoz.ru/faq/1-1#1, как по мне — так это больше философские размышления о видении правильного учета, описанные художественным языком. Никакого формализма, никаких правил, приемов и способов… Методологии, практической методологии, как таковой, так и не смог увидеть/понять. Хотя, причина этого может быть в математическом складе ума и попытках структурировать и систематизировать знания.
К примеру, ожидается, что через месяц вещь будет выкинута на свалку.
Так это совершенно не контрпример к моим примерам. В MRP есть понятие списания — поставка, или грамотнее — движение материала, (например, при истечении срока годности). Причем это не перевод наличия в ноль, а даже в минус, вследствие затрат на утилизацию… И выбытие, списание, делается все тем же видом движения материала (действием по вашей терминологии).
Я бы не хотел сравнивать. Сравнил не просто термины, а термины, применимые в конкретном программном обеспечении, которое реализует вами описанный функционал (причем годов эдак с 70-x). Вы почти в каждом комментарии пишете об особом методе. В чем же заключается ваш метод (достаточно ссылки на публикацию, я сам постараюсь разобраться), и что в нем особого (нового)?
Обязательство у вас понятие абстрактное — неживое. Как только вы его пытаетесь применить в программе, оно оказывается еще как формализуемым: либо поставка, либо выполнение работ, либо финансовое (что в принципе можно свести к поставке). Обещание жениться к методологии движения материала не применимо :)
По поводу (У меня программа для учета, а не для бизнес-аналитики) вы сами себя загоняете в угол. Любая программа учета — это аналитика. Они собственно для аналитики и создаются. Посмотреть наличие товара на складе на дату, посмотреть движение материалов за интервал времени, посмотреть объемы поставок по контрагентам — все это аналитика. Без этого функционала — ваша программа не будет отличаться от ведения приход/расход кладовщиком в тетрадке, соответственно будет не нужна.
Про генерацию отчетов неправильно изъяснился. Имел ввиду, что все эти отчеты в методологии MRP давно известны (см. предыдущий абзац).
А я вот наоборот. Много общего увидел.
Вы просто отошли от бухгалтерии в сторону логистики (изобрели свои термины и правила).
Делаем следующие замены:
Вещь -> Материал
Действие -> Движение материала
Обязательство -> Планирование поставок (и платежей в MRP II)
Вероятности -> Оценка рисков (только не пальцем в небо, а с помощью методик)
Генерация отчетов — тут даже переименовывать ничего не надо, оно и так все есть
И получается, что ЭкаунтоЛогика -> Учет и планирование в логистике.
Куски html/css/шаблоны я храню в SO10 текстах — так проще потом править.
Ваш набор css/html можно было просто загнать в текст и заменой placeholder'ов подставить нужные значения.
Смесь переводимых текстов (параметры отчета) и непероводимых (th) в одном значении — это фу.
Объявление переменных в теле кода, а не в начале — фу (тут так принято). Тогда уж лучше использовать inline объявление, если версия позволяет.
раздутыйкакиндюкабапер mode off*
Не оценивайте мое брюзжание как критику. Дерзайте. Учитесь. Делитесь опытом.
ABAP — язык бизнес-логики, для красивостей лучше смотреть в сторону bsp, webdynpro или sapui5.
Хотя, что это я? Сам на прошлой неделе верстал html-письма на нем-родимом :)
а в коде
1. Установка большого количества солнечных батарей закроет от солнца приличный кусок поверхности земли. Соответственно растения, а потом и козявки переползут на солнечное место, подальше от батарей. Поэтому, слова
на мой взгляд не такие уж и глупые. Подойдите к любому забору и посмотрите с северной стороны много ли там чего растет?
2. Мне достоверно не известно влияние электро-магнитного поля на человека, да и ученые точно этого не знают. В доме много техники — этого не боюсь. Однако я, как и многие другие, совершенно не стремлюсь жить рядом с высоковольтными линиями или подстанциями.
Кидайте в меня тапками, но, по-моему, учительница не так уж и глупа.
Да и пункты у вас по сути не отличаются. Ответ с сервера и обработка Javascript.
Разница только в том, кто оборачивает ответ в HTML, сервер или клиент — вставляет в любом случае JS.
Я привет пример с XAMPP, так как это наиболее простой и доступный пример для построения клиент-серверной архитектуры (free или low cost). Я много лет работаю с приложениями от SAP и встречал более сложные схемы.
web client -> load balancer -> n x web server -> load balancer -> n x app server -> DB cluster
Поэтому достаточно четко понимаю разницу между web server и app server — физически это могут быть не только разные приложения, но и разные машины.
В корпоративных приложениях. Web-сервер отвечает за предоставление данных пользователю в конечном виде. Сервер приложения отвечает за бизнес-логику. Строго говоря сервер приложения может работать и без WEB сервера, планируя задания и отвечая за интеграцию со сторонними системами.
Даже на примере XAMPP должно быть очевидно, какую роль выполняет Apache, а какую PHP.
Браузер -> Web сервер -> Сервер приложения -> База данных
Может вы просто не нашли демки…
https://openui5.hana.ondemand.com/explored.html
Или просто не знаете про Fiori…
Catalog of SAP Fiori Apps
И много чего еще…
По поводу своих контролов очень просто.
Приложение на английском языке должно запускаться у клиентов по всему миру.
Отгадайте на каком языке покажут контролы браузеры в разных странах.
Отгадайте, какие региональные настройки будут в стандартных контролах.
Кстати, у dojo тоже куча своих контролов. Нафига?
Ну а по поводу
Как же можно сравнивать 2 фреймворка, если один из них вы точно не знаете?
Это отличие от бухгалтерии или от MRP? Я же писал в самом начале
в том, что касается методологии, а не философском видении.
С удовольствием, но не нашел. Киньте, пожалуйста, ссылку на практическую методологию.
Зря вы так… Посмотрите сколько к вам вопросов в комментариях. В данном посте вам не очень удалось описать методологию.
Прочитал описание вот тут: accountology.ucoz.ru/faq/1-1#1, как по мне — так это больше философские размышления о видении правильного учета, описанные художественным языком. Никакого формализма, никаких правил, приемов и способов… Методологии, практической методологии, как таковой, так и не смог увидеть/понять. Хотя, причина этого может быть в математическом складе ума и попытках структурировать и систематизировать знания.
Так это совершенно не контрпример к моим примерам. В MRP есть понятие списания — поставка, или грамотнее — движение материала, (например, при истечении срока годности). Причем это не перевод наличия в ноль, а даже в минус, вследствие затрат на утилизацию… И выбытие, списание, делается все тем же видом движения материала (действием по вашей терминологии).
Обязательство у вас понятие абстрактное — неживое. Как только вы его пытаетесь применить в программе, оно оказывается еще как формализуемым: либо поставка, либо выполнение работ, либо финансовое (что в принципе можно свести к поставке). Обещание жениться к методологии движения материала не применимо :)
По поводу (У меня программа для учета, а не для бизнес-аналитики) вы сами себя загоняете в угол. Любая программа учета — это аналитика. Они собственно для аналитики и создаются. Посмотреть наличие товара на складе на дату, посмотреть движение материалов за интервал времени, посмотреть объемы поставок по контрагентам — все это аналитика. Без этого функционала — ваша программа не будет отличаться от ведения приход/расход кладовщиком в тетрадке, соответственно будет не нужна.
Про генерацию отчетов неправильно изъяснился. Имел ввиду, что все эти отчеты в методологии MRP давно известны (см. предыдущий абзац).
Вы просто отошли от бухгалтерии в сторону логистики (изобрели свои термины и правила).
Делаем следующие замены:
Вещь -> Материал
Действие -> Движение материала
Обязательство -> Планирование поставок (и платежей в MRP II)
Вероятности -> Оценка рисков (только не пальцем в небо, а с помощью методик)
Генерация отчетов — тут даже переименовывать ничего не надо, оно и так все есть
И получается, что ЭкаунтоЛогика -> Учет и планирование в логистике.
ru.wikipedia.org/wiki/MRP_II