Форум PHP

Спасибо, камрад.

Вы хотите чтобы я это кино смотрел? У меня на данный момент времени нет времени на сериалы, да и вообще, уж если вникать в это, то по печатному оттиску.

Не пытайтесь создать что-то из кусков, не получится. Если вы хотите освоить готовые инструменты, то используйте их, если хотите написать что-то свое, то сначала ответьте на вопрос себе, что вам надо - универсальный инструмент на все случаи жизни или вы хотите сделать легко изменяемый легкий инструмент, который позволяет решать конкретные задачи подобной текущей - сделать из монстра легко управляемую структуру.

Принял, спасибо. Пока буду переваривать, возник вопрос.

>>Давать полям формы имена соответствующие именам таблицы базы, это плохо, при ошибках, которые
>>не дай бог вы вываливаете на сервере, эти имена будут щедрым подарком для тех, кто анализирует ваши
>>ошибки не ради благих намерений.

Согласен.
А как быть, если разного рода связки вроде backbone и lavarel, которые возвращают данные из БД в чистом виде (видео)? Подобные связки используют же десятки тысяч людей, если не больше.

С одной стороны, выходит, безопасность, а с другой удобство и скорость разработки? (это я присматриваюсь к инструментарию, что бы в будущем динозавра своего переписать).

{.. template:"person.tpl"...} - а зачем клиенту ненужные данные? Если указывать клиенту куда это помещается, то получается, что инициатором диалога выступает сервер. Запрашивает клиент сервер, а не наоборот, а это означает, что клиент указывает серверу с каким шаблоном на текущий момент времени будет работа, и знает для какого шаблона данные ответа предназначены. Это если говорить о шаблонах на клиенте.

Не о шаблоне, сперва просто готовый html на основе таблиц базы.

Да, таблиц может быть много, иметь поля они могут какие угодно, вот только типов данных которые могут хранить эти поля гораздо меньше, чем фантазии по именованию, да и типы постоянны.

Поля таблиц кроме данных могут иметь комментарии, а это значит, что указать заголовки таблицы которая выводит эти данные можно на основе этих комментариев. Число колонок таблицы определяется только числом полей которые необходимо просмотреть/обновить.

Поля которые обновляются имеют соответствующие поля формы, тип которых может быть основан на типах данных таблицы базы.

Давать полям формы имена соответствующие именам таблицы базы, это плохо, при ошибках, которые не дай бог вы вываливаете на сервере, эти имена будут щедрым подарком для тех, кто анализирует ваши ошибки не ради благих намерений. Имена полей формы могут быть вообще абстрактными, для каждой сессии и даже каждой формы новые. Для идентификации данных достаточно индекса, ибо поля формы, это массив, который не обязательно должен быть ассоциативным, имея для каждого поля индивидуальный ключ.

Индексный набор данных формы легко связать с реальными именами таблицы на сервере, достаточно описать эти имена по указателю - таблице с которой в данном случае работает форма. При этом, если клиент возвращает не все индексы прописанные в форме (тот же checkbox), то поле ему соответствующее не будет участвовать в обновлении данных.

Типов данных не так и много, а поэтому описать операции проверки данных не сложно. Но полной универсальности в том смысле "что само догадается что сделать" вы не напишите, поэтому описывать некие индивидуальные или дополнительные правила тех или иных полей какого либо источника все равно придется.

Все это вместе может работать как автомат, при этом не обязательно такое можно решить только в ООП. Если данные имеют простейшие индексы, то это уже позволяет ссылаться по ним как адресам в матрице, которая описывает имена, правила и прочее. То есть, в качестве такой матрицы может выступать обычный массив, а ячейка массива совсем не обязана содержать только число/строку, это могут быть и функции.

Я уже здесь писал о подобном с примерами, повторяться не хочется, а то что сделать можно, это бесспорно. Только для этого нужно отталкиваться не от {id:"1",..., pesonAge:"10"}, а от первичного - от данных, их организации, а что и как передавать клиенту, это уже потом.

>Если часть управления асинхронная и сессия "приказала долго жить", а пользователь повторяет в это время асинхронный запрос, и получается казус (насколько я могу судить о вашей проблеме), то надо выдать команду клиенту на перегрузку страницы (был запрос асинхронный, снова вход), иначе просто перенаправление на вход.

В моём положении, когда проверка на авторизацию происходит только при загрузке страницы целиком, получается, что:
а) скрипт отрабатывающий аякс, должен сообщить, что сессия крякнула;
б) на клиенте это надо поймать и тупо перезагрузить страницу, типа window.location.href=window.location.href;

Но у тут мой неуклюжий динозавр гадит, в том смысле, что надо эту проверку вставлять везде, где есть аяксы. Сделать то можно, но динозавр обретёт ещё один костыль, а в следующий раз не хватит терпения и его придётся пристрелить.))

Какие вижу варианты? Можно создать (как — пока не знаю) некую обёртку, которая позволит выполнять аякс строго в одном месте, но отрабатывать успешное завершение, ошибки по разному, исходя из переданных в обёртку параметров. Это нормальное решение?

Да. Всё ясно.
Тогда, если не возражаете, можно я вас ещё немного вопросами помучаю?

В качестве пролога — я раньше на всяких асмах-си-паскалях писал, жизнь заставила писать и под веб. Когда начинал делать сайт, толком ничего не умел, по ходу получения знаний занимался модернизацией. Потому мой проект сейчас как динозавр с куче костылей.

Один из вопросов, который меня мучает, это как можно упростить задачу администрирования уже накопившейся кучи таблиц, ведь все они с разными полями, поля все имеют разные имена, каждое поле может быть числом, строкой, там, или текстом, и т.д.

До недавнего времени (до начала использования аякса) я под каждую таблицу делал отдельный класс, который отвечает за работу с данными из этой таблицы. Ну, то есть, тупо выводил html по старинке. Потом, со временем, стал использовать автоматическую подгрузку данных в комбобоксы из других таблиц аяксом, и тут во мне закралось подозрение, что всю эту неуклюжую конструкцию (движок) можно как то упростить.

Вот вы тут написали очень правильные вещи, например, перевести админскую часть целиком на аякс, по нему же получая только голые данные и уже на клиенте их распихивать по формам-местам. Всё ясно, кроме одного — что же делать с этой кучей таблиц? Писать опять под каждую свой javascript код, или же есть методология, позволяющая шагнуть на встречу светлому будущему?

Ну, в качестве идеи вижу, например, такой вариант. Скажем, нужно отредактить описание объекта, тогда по запросу получаем, например, такой ответ:

{id:"1",
error : "0",
template:"person.tpl",
data: {
personID:"10",
personName:"Vasya",
personAge:"10",
}
}

где personID, personName, personAge — имена полей в БД, и они же ID полей, куда надо примостить данные. А примостить их надо в person.tpl, который, по логике, надо получить либо заранее, либо дополнительно запросить. Второй вариант, конечно, никудышный. В первом можно заранее вывести эту форму, но как быть, если, скажем меняется контекст, и нужно отредактировать другую таблицу? Придётся запросить таки новый шаблон, а потом в него данные, так что ли?

Что скажете, мастер?

так и я о чем. только этот <div>{var}</div> лучше не в переменной держать, а откуда-то брать, чтобы не мешать.. хотя ладно, мне уже надоела эта дискуссия.

Нет, только уроки бальных танцев )

Если часть управления асинхронная и сессия "приказала долго жить", а пользователь повторяет в это время асинхронный запрос, и получается казус (насколько я могу судить о вашей проблеме), то надо выдать команду клиенту на перегрузку страницы (был запрос асинхронный, снова вход), иначе просто перенаправление на вход.

А вы случаем курсы для желающих не проводите?

Спасибо. Да, выходит, у меня косяк вылез. Вернее как вылез. До того, как не было аяксов, и страница грузилась полностью, авторизация проверялась при каждой загрузке. А при аяксе на скрипты — не проверялось. Блин, и проект — динозавр, переделывать придётся много.