Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
Есть небольшая задача. Предположим, что есть PIM приложение (прям как в учебниках по шаблонам проектирования :-) ). В списке дел могут создаваться различные события - к примеру одно имеет конкретную дату проведения, а второе должно срабатывать только через n дней после проведения первого. Помимо этого мы должны дать пользователю возможность запрограммировать поведение при непроведении события, к примеру должны создаваться два других события, но ужде другого типа(скажем отчетное собрание по причинам непроведения мероприятия). При том что даты, количество людей(состав), события при проведении или непроведении определяет сам пользователь. Есть шаблон проектирования Strategy(Policy), несколько удовлетворяющий данным требованиям. Сталкивался кто-нибуль с подобной задачей ? У кого какие соображения ? Или какие здесь могут быть "грабли" ? Может есть еще какие шаблоны которые бы помогли правильно конфигурировать, задавать поведение системы в runtime ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2005, 10:45 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
BegginerProЕсть небольшая задача. Предположим, что есть PIM приложение (прям как в учебниках по шаблонам проектирования :-) ). В списке дел могут создаваться различные события - к примеру одно имеет конкретную дату проведения, а второе должно срабатывать только через n дней после проведения первого. Помимо этого мы должны дать пользователю возможность запрограммировать поведение при непроведении события, к примеру должны создаваться два других события, но ужде другого типа(скажем отчетное собрание по причинам непроведения мероприятия). При том что даты, количество людей(состав), события при проведении или непроведении определяет сам пользователь. Есть шаблон проектирования Strategy(Policy), несколько удовлетворяющий данным требованиям. Сталкивался кто-нибуль с подобной задачей ? У кого какие соображения ? Или какие здесь могут быть "грабли" ? Может есть еще какие шаблоны которые бы помогли правильно конфигурировать, задавать поведение системы в runtime ? Грабли начнутся при редактировании и удалении. Придется заранее думать что делать с порожденными по некоему алгоритму записями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2005, 10:50 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
> Сталкивался кто-нибуль с подобной задачей? Нет. > У кого какие соображения? Или какие здесь могут быть "грабли"? Специфичных - imho никаких. Если события строго типизированы и поведение системы для каждого типа детерминировано, то вообще никаких. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2005, 13:32 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
Поведение для каждого события неизвестно заранее, единственный вариант ограничить все события одним интерфейсом, чтобы хоть как-то унифицировать. Но в любом случае, к примеру, при отмене собрания, один пользователь захочет отменить все последующие собрания,или создать другое событие(совещение по поводу непроведения первого), другой перенесет событие на месяц, а третий на конкретную дату... Суть в том, что пользователь должен лишь запрограмировать, а создание новых события из расчета результатов предыдущих система должна делать сама. Тема все еще открыта. Как можно решить данную (чем проще тем лучше) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 11:35 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
BegginerProПоведение для каждого события неизвестно заранее, единственный вариант ограничить все события одним интерфейсом, чтобы хоть как-то унифицировать. Но в любом случае, к примеру, при отмене собрания, один пользователь захочет отменить все последующие собрания,или создать другое событие(совещение по поводу непроведения первого), другой перенесет событие на месяц, а третий на конкретную дату... Суть в том, что пользователь должен лишь запрограмировать, а создание новых события из расчета результатов предыдущих система должна делать сама. Тема все еще открыта. Как можно решить данную (чем проще тем лучше) ? А оно надо? Вы пытаетесь предусмотреть все возможные варианты действий пользователей, или у Вас есть подробное ТЗ? Не лучше ли дать пользователям понятный, дубовый, надежный функционал и пусть они применяются к нему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 11:43 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
ТЗ предусматривает именно такой вариант работы. То есть пользователь сам определяет реакцию системы на определенной событие(или определенного множества событий с кончным множеством параметров). Ему необходимо не просто сообщение о завершении работы какого то события(удачно-неудачно), а втоматическая реакция системы на результат. Предполагается создать некоторое множество готовых событий (к примеру проведение собрания, отправка уведомлений и т.д.) которые пользователь будет выбирать и конфигурировать в зависимости от результатов работы другого события. Все это получается несколько сложно. Поэтому я и поднял такой вопрос, в надежде что, кто-то из гуру подскажет возможные варианты более простого решения задачи, н ов рамках той поставновки что я описывал в предудыщих постах. :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 14:55 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
Мне кажется, что, раз модель свою ты проработал, и у тебя имеется инструмент реализации, то решение твоей проблемы в грамотном интерфейсе пользователя. Используй, к примеру, диаграммы Ганта. Вот тут можно посмотреть примеры для разных платформ: http://plexityhide.com/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 15:10 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
Поведение системы или шаблоны прТЗ предусматривает именно такой вариант работы. То есть пользователь сам определяет реакцию системы на определенной событие(или определенного множества событий с кончным множеством параметров). Ему необходимо не просто сообщение о завершении работы какого то события(удачно-неудачно), а втоматическая реакция системы на результат. Предполагается создать некоторое множество готовых событий (к примеру проведение собрания, отправка уведомлений и т.д.) которые пользователь будет выбирать и конфигурировать в зависимости от результатов работы другого события. Все это получается несколько сложно. Поэтому я и поднял такой вопрос, в надежде что, кто-то из гуру подскажет возможные варианты более простого решения задачи, н ов рамках той поставновки что я описывал в предудыщих постах. :-( Для сложной постановки простое решение получить может и не получиться :) А практика показывает, что пользователь ни фига конфигурировать не захочет (или у Вас уникальные пользователи). Все же хотелось бы понять получше, откуда ноги растут у такой постановки. На самом деле вполне логично пытаться понять оправданность постановки - никто не хочет решать надуманные задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 15:17 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
> Поведение для каждого события неизвестно заранее, Т. е. пользователь может создавать любые события, связанные с любыми событиями любыми отношениями? > единственный вариант ограничить все события одним интерфейсом, Это понятно. > Cуть в том, что пользователь должен лишь запрограмировать, а создание новых > события из расчета результатов предыдущих система должна делать сама. Для каждого пользователя (группы или роли) заводим конфиг (пара основных таблиц + вспомогательные), где отражаем модель поведения системы при наступлении события определенного типа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 15:28 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
Усугубим: заводим дефолтный конфиг для системы; для пользователей (групп или ролей) регистрируем только отличия поведения системы от поведения по умолчанию. Компактно + возможность легко дописывать/изменять модель поведения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 16:12 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
2 Dogen "Для сложной постановки простое решение получить может и не получиться :)" Я имел в виду "разумно" простое. То есть без лишнего усложнения. 2 guest_20040621" "Т. е. пользователь может создавать любые события, связанные с любыми событиями любыми отношениями? " Нет не настолько сложно - предполагаю создание всего двух трех статичных событий, возвращающих опред. статус - 1)к примеру событие активировано, 2)выполнено(удачо, нет, возможно введение большего количества статусов) и т.д. При выполнении определенного события создается сценарий для создания другого обьекта (множества обьектов, но их "жесткого" спискатиповобьектов), с запрограммированными пользователем параметрами. Или для определнных события можеть не быть сценариев. После этого родительский обьект должен или станавливаться в неактивное состояние, либо через определенный промежуток времени снова активироваться. :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 16:19 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
> Нет не настолько сложно - предполагаю создание всего двух трех статичных > событий, Это я и хотел выяснить: произвольные события или все-таки типизированные. С произвольными чуть сложнее, но в принципе imho было бы достаточным ограничить функциональность системы регистрацией результатов события, статуса события и уведомлений участников (владельцев и пр.). Т. е., разница между наличием произвольных событий и их отсутствием будет выражаться в более детальном описании параметров событий. > При выполнении определенного события создается сценарий для создания > другого обьекта (множества обьектов, но их "жесткого" спискатиповобьектов), Понятно. Думаю, с конфигами все должно получиться. > После этого родительский обьект должен или станавливаться в неактивное > состояние, либо через определенный промежуток времени снова активироваться. Это тоже должно быть в конфиге. Imho плохо то, что программный код придется привязывать к содержимому таблиц. Кстати спросить (всегда интересовало, но никогда руки не доходили): не думали на предмет реализации разных календарей (актуально для распределенных систем)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2005, 16:55 |
|
||
|
Поведение системы или шаблоны проектирования...
|
|||
|---|---|---|---|
|
#18+
2 guest_20040621 "Кстати спросить (всегда интересовало, но никогда руки не доходили): не думали на предмет реализации разных календарей (актуально для распределенных систем)?" Разных календарей ? То есть учитывать часовые пояса ? Нет не возникало. Хотя с календарями есть еще один момент. События зависимы от дат. Но в разных ситуациях зависимость может быть различной: 1) абсолютная - то есть на некоторое число... 2) относительная - то есть происходящее через несколько дней после контрольной даты, к примеру удачного выполнения предыдещего события. В свою очередь, относительная зависимость может "активироваться" - через несколько календарных дней, рабочих дней (или к примеру опер. дня банка, в случае привязки системы к банковским продуктам, но это уже отдельный разговор), или несколько часов. По всей видимости придется реализовать и широкоиспользуемые "форматы дат" событий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2005, 07:10 |
|
||
|
|

start [/forum/topic.php?fid=32&tid=1546069]: |
0ms |
get settings: |
7ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
75ms |
get topic data: |
12ms |
get forum data: |
4ms |
get page messages: |
58ms |
get tp. blocked users: |
2ms |
| others: | 267ms |
| total: | 448ms |

| 0 / 0 |
