Хотелось бы видеть в МЛО инверсию зависимости.
Если задача завершена - зависимая задача становится неактивна.
Это значительно упростило бы схемы где нужно использовать "выключатель".
У вас есть проблемы напоминаний в MLO-Android? Ответьте: Да/Нет.
Инверсия зависимости
-
- Команда бета тестеров
- Сообщения: 951
- Зарегистрирован: янв 2012
- Есть ответ: 32
- Откуда: Київ
- Благодарил (а): 29 раз
- Поблагодарили: 183 раза
- Контактная информация:
Инверсия зависимости
А если зависимость косвенная? Не всегда получается взаимозависимость.
Или если от задачи зависит несколько задач?
Идея интересная, но настолько редко применительная, что ее реализация только запутает пользователей.
Или если от задачи зависит несколько задач?
Идея интересная, но настолько редко применительная, что ее реализация только запутает пользователей.
Делайте! Внедряйте! И воздастся Вам по делам Вашим! (А не по Вашим мечтам, мыслям, планам, идеям или намерениям…)
-
Автор темы
- Команда бета тестеров
- Сообщения: 327
- Зарегистрирован: мар 2017
- Есть ответ: 15
- Благодарил (а): 76 раз
- Поблагодарили: 105 раз
Инверсия зависимости
Может функция редко применима, потому что её сложно реализовать? Сужу только по себе. Если она реально у других не востребована, я обойдусь костылями, но видеть хотелось бы.
Если же вопрос только в путанице - можно отработать именно путаницу. Не обязательно делать функию инверсия частью зависимости. Можно например сменить название(и само понятие) этой функции на что-то вроде "помехи", "препятствия", "блокировки", или например "замок"(и иконку открытого/закрытого замка, вместо иконки цепочки). Если помеха реализована, она препятствует дальнейшему выполнению заблокированной задачи/ветки.
Если же вопрос только в путанице - можно отработать именно путаницу. Не обязательно делать функию инверсия частью зависимости. Можно например сменить название(и само понятие) этой функции на что-то вроде "помехи", "препятствия", "блокировки", или например "замок"(и иконку открытого/закрытого замка, вместо иконки цепочки). Если помеха реализована, она препятствует дальнейшему выполнению заблокированной задачи/ветки.
Инверсия зависимости
Не очень понял целесообразность постановки задачи про инверсию зависимости.
Если зависимая задача станет неактивной после выполнения обеспечивающей задачи, то зачем зависимая вообще нужна? Так только невидимый мусор может накапливаться.
Другое дело, что можно предусмотреть особый вид зависимости, когда зависимая задача автоматически выполняется, при выполнении обеспечивающей. Это может пригодиться, когда задачи расположены в разных ветках дерева.
Если зависимая задача станет неактивной после выполнения обеспечивающей задачи, то зачем зависимая вообще нужна? Так только невидимый мусор может накапливаться.
Другое дело, что можно предусмотреть особый вид зависимости, когда зависимая задача автоматически выполняется, при выполнении обеспечивающей. Это может пригодиться, когда задачи расположены в разных ветках дерева.
-
Автор темы
- Команда бета тестеров
- Сообщения: 327
- Зарегистрирован: мар 2017
- Есть ответ: 15
- Благодарил (а): 76 раз
- Поблагодарили: 105 раз
Инверсия зависимости
Типовая схема звучит так: "когда я делаю А, то не могу Б." Применяю к нестандартным задачам, по большей части чтобы скрыть стандартные ситуации, когда контексты и фокус не справляются.
Пример "когда запланированная на дату..., то повторяющаяся..." Когда семейный праздник, то ряд вечерних дел и досуга не отображаются. Когда мы в пути, то почти вся рутина блокируются.
Пример "когда без даты..., то повторяющаяся..." Когда я занялся строительством пристройки или огородом, то дополнительные физические тренировки не нужны. Когда я приготовил тяжелую пищу, то физические и умственные вредны.
Пример "когда проект..., то другие проекты..." Когда получили хороший заказ, то перестаю дёргать мастера по второстепенным ролям. итд
На практике функция легко реализуется в момент прояснения задачи. Просто думаешь какие дела она заблокирует и добавляешь к этим делам в "блок". Сложность технически настроить.
Чтобы ветка не висела нужно подумать на сколько времени блокирующая задача выведет блокируемую из строя, или какое событие должно снять блок. Как вариант можно добавить опцию как в зависимости, "вернуть через...часов". Мне хватает повторов, или запуска архивации во время обзора.
Автозачёркивание даст немного другой эффект, если я правильно Вас понял.. Функция хоть и опасная, но тоже интересная. Реализую её с помощью локальной ссылки.
Пример "когда запланированная на дату..., то повторяющаяся..." Когда семейный праздник, то ряд вечерних дел и досуга не отображаются. Когда мы в пути, то почти вся рутина блокируются.
Пример "когда без даты..., то повторяющаяся..." Когда я занялся строительством пристройки или огородом, то дополнительные физические тренировки не нужны. Когда я приготовил тяжелую пищу, то физические и умственные вредны.
Пример "когда проект..., то другие проекты..." Когда получили хороший заказ, то перестаю дёргать мастера по второстепенным ролям. итд
На практике функция легко реализуется в момент прояснения задачи. Просто думаешь какие дела она заблокирует и добавляешь к этим делам в "блок". Сложность технически настроить.
Чтобы ветка не висела нужно подумать на сколько времени блокирующая задача выведет блокируемую из строя, или какое событие должно снять блок. Как вариант можно добавить опцию как в зависимости, "вернуть через...часов". Мне хватает повторов, или запуска архивации во время обзора.
Автозачёркивание даст немного другой эффект, если я правильно Вас понял.. Функция хоть и опасная, но тоже интересная. Реализую её с помощью локальной ссылки.
Инверсия зависимости
Не очень понятное у Вас разъяснение. На 100% я его так и не понял. Буду отвечать на то, что понял.
Стандартная зависимость: задача Б заблокирована до выполнения задачи А.
Вы предлагаете в начальном посте 13 фев 2018, 03:13 - задача Б становится неактивной, когда выполнена (уже выполнена) задача А.
Во-первых, смотрите мой предыдущий пост 20 фев 2018, 20:49. Во-вторых, не понятно как этот механизм поможет Вам реализовать механизмы, предлагаемые в посте 22 февр 2018, 08:59.
Стандартная реализованная зависимость имеет простейшее условие - выполнена-невыполнена задача А.
Вы предлагаете в посте 22 февр 2018, 08:59 ввести, как я понял, новый тип условий - блокировка, когда задача А выполняется. Это совсем не тоже самое, что в посте 13 фев 2018, 03:13. Чего вы на самом деле хотите?
Отступление. Задача имеет, как минимум, 2 параметра действия - активна-неактивна и (занимает ваше настоящее время)-(не занимает ваше настоящее время). [Простаивает-выполняется это другое - может быть другой исполнитель и ваше время свободно.]
Второй вид параметра в MLO дееспособным образом пока не реализован (старт-стоп), а активная задача, как впрочем и неактивная, могут как занимать ваше настоящее (сию минуту) время, так и не занимать.
Продолжение. Пока можно претендовать только на параметр активна-неактивна, а не параметр (занимает ваше настоящее время), то есть "выполняется" в Вашей терминологии. Но это не всегда оптимально, поскольку часто в активное время задачи закладывают резервное время, иногда значительное, например, когда задача выполняется по частям вперемежку с другими задачами, или, например, когда задача напоминает о себе заранее - с запасом времени. Активная задача - это актуальная задача, но не обязательно она занимает ваше время прямо сию минуту.
Стандартная зависимость: задача Б заблокирована до выполнения задачи А.
Вы предлагаете в начальном посте 13 фев 2018, 03:13 - задача Б становится неактивной, когда выполнена (уже выполнена) задача А.
Во-первых, смотрите мой предыдущий пост 20 фев 2018, 20:49. Во-вторых, не понятно как этот механизм поможет Вам реализовать механизмы, предлагаемые в посте 22 февр 2018, 08:59.
Стандартная реализованная зависимость имеет простейшее условие - выполнена-невыполнена задача А.
Вы предлагаете в посте 22 февр 2018, 08:59 ввести, как я понял, новый тип условий - блокировка, когда задача А выполняется. Это совсем не тоже самое, что в посте 13 фев 2018, 03:13. Чего вы на самом деле хотите?
Отступление. Задача имеет, как минимум, 2 параметра действия - активна-неактивна и (занимает ваше настоящее время)-(не занимает ваше настоящее время). [Простаивает-выполняется это другое - может быть другой исполнитель и ваше время свободно.]
Второй вид параметра в MLO дееспособным образом пока не реализован (старт-стоп), а активная задача, как впрочем и неактивная, могут как занимать ваше настоящее (сию минуту) время, так и не занимать.
Продолжение. Пока можно претендовать только на параметр активна-неактивна, а не параметр (занимает ваше настоящее время), то есть "выполняется" в Вашей терминологии. Но это не всегда оптимально, поскольку часто в активное время задачи закладывают резервное время, иногда значительное, например, когда задача выполняется по частям вперемежку с другими задачами, или, например, когда задача напоминает о себе заранее - с запасом времени. Активная задача - это актуальная задача, но не обязательно она занимает ваше время прямо сию минуту.
-
Автор темы
- Команда бета тестеров
- Сообщения: 327
- Зарегистрирован: мар 2017
- Есть ответ: 15
- Благодарил (а): 76 раз
- Поблагодарили: 105 раз
Инверсия зависимости
Не очень понятное у Вас разъяснение.
Это не мой конёк) Плохо определяю заранее что вызовет вопросы, а что запутает, у меня то в голове всё очевидно
Во-первых, смотрите мой предыдущий пост 20 фев 2018, 20:49
Не очень понял целесообразность постановки задачи про инверсию зависимости.
Цель: запланировать блокировку того(Б), чем я не буду заниматься по причине...(А).
Средства: ломать голову как это устроить, собирать из этого механизмы-шаблоны для разных условий, учиться быстро их встраивать в нужных условиях.
Так же средства: механизмы занимают место, иногда требуют дополнительных(формальных) задач, папок, подмеханизмов.
Сообразность цели средствам определяется для каждого случая индивидуально. Основной критерий: если шаблон при планировании добавляется в систему за несколько минут и гарантированно решает в будущем какой-то вопрос - ему быть.
Вы предлагаете в посте 22 февр 2018, 08:59 ввести, как я понял, новый тип условий - блокировка, когда задача А выполняется. Это совсем не тоже самое, что в посте 13 фев 2018, 03:13. Чего вы на самом деле хотите?
Не хватает именно этого:
задача Б становится неактивной, когда выполнена (уже выполнена) задача А
От разработчиков я прошу функцию в чистом виде...
Во-вторых, не понятно как этот механизм поможет Вам реализовать механизмы, предлагаемые в посте 22 февр 2018, 08:59.
...Чистая функция имеет преимущества над схемами её заменяющими. Что сэкономит затрачиваемые средства.
Предлагаемые механизмы можно уже сейчас настроить, успешно тестирую их для некоторой повторяющейся рутины, с помощью "километровых костылей".
Вот один из шаблонов, и реальный пример его тестирования(если выполнять проект с санками, то тренировки отпадут), воссоздал без дат, чтобы пример кликался.
Вместо "тренировок" можно поставить хоть всю сферу жизни РАБОТА и ДОМ или же отдельные их части, а вместо "горки" заблокировать задачей "посадка на рейс в отпуск", разблокировать задачей "посадка на рейс домой"(или просто отработав и заархивировав проект отпуск)
Если зависимая задача станет неактивной после выполнения обеспечивающей задачи, то зачем зависимая вообще нужна?
Нужность "блокируемой" задачи определена заранее, "блокировка" работает с уже нужными задачами, переключая только доступность.
Так только невидимый мусор может накапливаться.
Если "блокировка" прячет мусор навсегда - мусор удаляется при следующем обзоре активных проектов(если Вы такой глубокий обзор не проводите, можно подумать над другим решением)
Если "блокировка" временная или решаемая - мусор уже не мусор, а задача в ожидании.
Старт-стоп мне не очень нужен.
Еще пару скопившихся заметок по теме.
Как я представляю себе поведение функции?
Оформление
Долго писал сообщение... если что-то упустил или не понятно, отвечу наверное уже после отпуска.
Инверсия зависимости
Если ввести зависимость "Задача Б становится неактивной после выполнения задачи А", то после выполнения задачи А задача Б больше никогда не сможет быть активной и зависнет навсегда.
-
Автор темы
- Команда бета тестеров
- Сообщения: 327
- Зарегистрирован: мар 2017
- Есть ответ: 15
- Благодарил (а): 76 раз
- Поблагодарили: 105 раз
Инверсия зависимости
Ну да, поведение функции вполне естественно. Если в действительности задача "А" - безвозвратно блокирует "Б", то и в планировщике это должно повторяться. Это логично. "Б" зависнет без возможности завершиться. Всё что зависит от "Б" так же зависнет и это будет отражать реальный ход дел. "А" не решает проблему для "Б", а создаёт.
Если в действительности "А" - временная помеха, отображаем это в планировщике в свойствах "А".
Если в действительности "А" - решаемая помеха, отображаем это в планировщике в виде дополнительной задачи-решения.
Если в действительности "А" - временная помеха, отображаем это в планировщике в свойствах "А".
Если в действительности "А" - решаемая помеха, отображаем это в планировщике в виде дополнительной задачи-решения.
Вернуться в «Предложения по улучшению»
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 18 гостей