Универсальный декларативный построитель выражений в PHP
7 ответов
Небольшое предупреждение. Эти типы универсальных построителей выражений обычно считаются отличным решением множества пользовательских проблем. Мышление имеет тенденцию развиваться в следующих направлениях:
- Пользователь хочет получить все эти разные отчеты
- Мы не можем предоставить им доступ к SQL (даже если бы они могли его понять)
- У нас нет времени на напишите все эти пользовательские отчеты
- Поэтому я сделаю для них простой способ писать запросы без необходимости знать конкретный синтаксис, таблицы и поля.
Это не обязательно плохая идея, но то, что мы обнаружили на Моя компания состоит в том, что пользователи, не являющиеся техническими специалистами, испытывают удивительные трудности с пониманием и построением выражений, более сложных, чем группа ANDS или группа ORS. Нам, программистам, это трудно понять, поскольку у большинства из нас, вероятно, было интуитивное понимание логической логики еще до того, как мы научились программировать.
Я бы рекомендовал вам не пытаться предоставить им полную гибкость для создания любого выражения, которое они хотят, а вместо этого вы создаете пользовательский интерфейс, который позволяет вы, программист, определяете что-то более сложное на внутреннем интерфейсе, но предоставляете пользователю простой выбор на интерфейсе. Очевидно, это легче сказать, чем сделать.
Помните - иногда проблема для конечных пользователей заключается не в том, что они не знают правильного синтаксиса для выражения своей идеи. Чаще всего это потому, что они даже не знают как сформулировать свои мысли однозначно, даже если им был предоставлен простой способ сделать это.
ПРИМЕЧАНИЕ: я не говорю, что конечные пользователи всегда идиоты - просто их умы могут работать не так, как мы, сумасшедшие разработчики .
Я думаю, что это больше связано с пользовательским интерфейсом, чем с PHP в целом. Вам лучше поменять теги на свой вопрос. Возможно, вы просто хотите проанализировать эти определения в PHP, в этом случае я бы предложил использовать preg_replace_callback.
Недавно я сам реализовал такую функциональность, и, IMHO, проще написать собственную реализацию.
почему бы не попробовать использовать smarty , который является механизмом шаблонов. вам просто нужно получить и проанализировать ввод пользователя.
Теперь, когда я подумал, для этого нужно будет проверять ввод пользователя, чтобы избежать инъекций.
Это не совсем компонент, но вы можете взглянуть на вкладку «Условия» в построителе правил корзины покупок в Magento , чтобы найти надежную реализацию PHP этого типа. функциональности. Он адаптирован для электронной коммерции, поэтому не является универсальным оверлеем базы данных, но имеет отличный интерфейс для построения условий.
Я бы начал с создания объектно-ориентированной модели запросов. Например. Критерии-объекты . Следующим шагом будет написание пользовательского интерфейса, который позволит манипулировать этой структурой модели.
Думаю, это очень интересная идея. Планируете ли вы работать над этим проектом для личного использования или в рамках работы?
Если вы планируете работать над этим проектом лично, возможно, вам стоит написать его самостоятельно и превратить в проект с открытым исходным кодом. Похоже, что уже есть некоторый интерес к этой области, и это было бы хорошим опытом обучения.
В противном случае я могу понять, как компания может найти ценность в чем-то подобном. Это дало бы программистам еще одну утилиту, которая могла бы помочь им делать свою работу немного проще и приносить дивиденды в долгосрочной перспективе.
В любом случае, этот проект выигрышный. Вы многому научитесь и создадите то, что другие люди сочтут полезным.