История прихода к задаче с "точкнутыми" именами
serglif 28.09.2004 14:56
Исходная задача: для произвольной реляционной базы данных реализовать интерфейс ее заполнения путем ответа на ряд последовательных групп вопросов. Типа опросника короче, заполняющего поля базы. С кнопками "<Назад", "Далее>".
Придуманное решение: создается промежуточная структура данных, описывающая группы вопросов, и соответствия их таблицам и полям базы. По этой структуре генерится XML, который частями (в зависимости от текущего шага) отображается на странице в виде набора форм. Поля есть обычные и executable. Executable поля дают команду на создание дочернего или сестринского объекта (типа заполнили клиента, если стоит галка "Добавить контакное лицо" (executable поле), то создается дочерний объект относящийся к таблице контактов, который затем и заполняется). После сабмита формы и разбора ее полей, происходит изменение XML через DOM и выводятся поля следующего шага. Если шаг был последний то сохраняем текущий XML в базу и облегченно вздыхаем. Если нужно заполнять какие-то сестринские/дочерние объекты - сохраняем его в базу и создаем новый объект. Есть нюансы с идентификаторами объектов в случае создания родительско-дочерних связей, вроде придумал как можно использовать для этого ^uuid.
Прошу прошения за подробность изложения, но это больше для себя. Чтобы лучше осознать. Дамп оперативки из моей головы, так сказать! :) Есть еще куча мелких деталек, вьются в подкорке.
Откуда на арену выходит отряд "точкнутых": есть такой тип поля - select. С его заполннием поборолся так - храню в поле items (поле структуры по которой строится XML) строку вида:
база_данных#поле_1#поле_2#sql_запрос_наполняющий_поле_значениями
Разбираю эту строку и набираю пары значений [name,value] для select-a.
Но у этого поля есть дефолтно выбранное значение. Оно может выбираться по совпадению поля value с разнообразным данным. Это может быть заранее известное значение, может быть значение какой-то переменной, может быть значение атрибута одного из элементов этого же XML,
может быть значением хэша, результатом исполнения sql-зпроса. Поэтому я также храню строку вида
тип следующих данных#имя переменой или хэша или другая инфа для запросов в базу
В моем конкретном случае я сразу столкнулся с хэшем - дефолтное значение нужно выбирать в зависимости от user_id залогиненного юзера.
Про ваш совет с XPatch буду думать. Возможно пригодиться. То есть XPatch всяко пригодится в будущем, насколько пригодится для этой задачи, пока не могу осознать.
