так это же пакет пыховский.
Вы же симфони целое сюда прикрутили, а одного пакета не хотите.
Просто дергать файловую систему вместо того чтобы ждать нужного события как бы экстенсивно. Это все равно вместо того чтобы использовать select/poll на сокетах пытаться все время из них что-то прочитать.
Тулза для мониторинга должна потреблять минимум ресурсов. А у Вас файловую систему зря грузит.
Иначе оно будет падать при попытке вставить какое-то другое.
Вам все равно прийдется это отслеживать, потому что действие может передаваться параметром запроса в ряде приложений.
Стейтмашина просто сгенерирует в этом случае исключение, которое должно быть перехвачено выше по стеку и обработано.
А поскольку все равно будет такая обработка, то после этого использовать константы в коде или использовать фактически те же константы из БД значения особого имееть не будет.
Если в приложении не предусмотрена передача действия как параметра, тогда Вы вольны добавить константы. Этой возможности никто не отнимает. Если передается, то смысл исчезает.
ENUM вообще менять может быть довольно проблемно на больших таблицах.
согласен.
Сама таблица-словарь состояний в общем виде определяется двумя колонками: собственно идентификатор и какой-то алиас или тайтл. С приложения искать придется по этой второй колонке, и снова нет гарантии, что между приложением и БД не возникнет рассинхрон при очередном изменении кода или БД.
Идентификатор в статическом словаре делается строчным и смысл в алиасе тогда пропадает.
При динамическом словаре удобство хранения в БД по сравнению с файлом описал выше OnYourLips
С гарантиями в конфигурации или коде все проще: оно в приложении константно (для определенной версии) и гарантировано по определению.
Нельзя гарантировать, что упомянутое в конфигурации состояние будет в словаре состояний в БД. Для этого Вы и говорите об константах (если я Вас правильно понимаю), которые кто-то определил и сверил со словарем. Но зачем поддерживать 2 источника синхронными, если можно иметь один? Это же удобней.
VO. Он не соберется с кривого значения и вы получите ожидаемое исключение о кривой конфигурации
=====
Если Вы будете контролировать «кривые» значения при считывании конфигурации. БД уже это делает.
Не соглашусь на счет правильности хранения в конфигурации. Один из аргументов Вы сами высказали — возможность модификации через интерфейс.
И хранение в БД гарантирует использование того же словаря состояний в переходах, что и в ентити объекта с помощью внешних ключей. А как Вы обеспечите это, если конфигурация хранится в хмл/php/ini файле?
Мне пришлось работать с конечным автоматом с конфигурацией в хмл. Даже при небольшом количестве переходов листать длинный конфиг неудобно, там много лишнего на мой взгляд было описано.
Почему не рассматривал symfony/workflow — не знал о нем. Поинтересуюсь, спасибо. Со своей стороны могу сказать, что данный проект в той или иной модификации опробован на нескольких проектах под ЗФ2/3 и отлично себя зарекомендовал.
Вы же симфони целое сюда прикрутили, а одного пакета не хотите.
Просто дергать файловую систему вместо того чтобы ждать нужного события как бы экстенсивно. Это все равно вместо того чтобы использовать select/poll на сокетах пытаться все время из них что-то прочитать.
Тулза для мониторинга должна потреблять минимум ресурсов. А у Вас файловую систему зря грузит.
Вам все равно прийдется это отслеживать, потому что действие может передаваться параметром запроса в ряде приложений.
Стейтмашина просто сгенерирует в этом случае исключение, которое должно быть перехвачено выше по стеку и обработано.
А поскольку все равно будет такая обработка, то после этого использовать константы в коде или использовать фактически те же константы из БД значения особого имееть не будет.
Если в приложении не предусмотрена передача действия как параметра, тогда Вы вольны добавить константы. Этой возможности никто не отнимает. Если передается, то смысл исчезает.
согласен.
Идентификатор в статическом словаре делается строчным и смысл в алиасе тогда пропадает.
При динамическом словаре удобство хранения в БД по сравнению с файлом описал выше OnYourLips
Нет, в данном случае я просто подчеркнул, что это ПО тоже вполне хорошо себя зарекомендовало, не более того.
Против переиспользования компонентов в других фреймворках ничего не имею. Используем же мы доктрину например ;)
Нельзя гарантировать, что упомянутое в конфигурации состояние будет в словаре состояний в БД. Для этого Вы и говорите об константах (если я Вас правильно понимаю), которые кто-то определил и сверил со словарем. Но зачем поддерживать 2 источника синхронными, если можно иметь один? Это же удобней.
=====
Если Вы будете контролировать «кривые» значения при считывании конфигурации. БД уже это делает.
И хранение в БД гарантирует использование того же словаря состояний в переходах, что и в ентити объекта с помощью внешних ключей. А как Вы обеспечите это, если конфигурация хранится в хмл/php/ini файле?
Мне пришлось работать с конечным автоматом с конфигурацией в хмл. Даже при небольшом количестве переходов листать длинный конфиг неудобно, там много лишнего на мой взгляд было описано.
Почему не рассматривал symfony/workflow — не знал о нем. Поинтересуюсь, спасибо. Со своей стороны могу сказать, что данный проект в той или иной модификации опробован на нескольких проектах под ЗФ2/3 и отлично себя зарекомендовал.