Не понял я, что куда там перемещается? Разметка страницы плывёт при вставке списка? Или что?
Если да, то ни php, ни ajax тут ни при чём, вы значит что-то затираете в объекте "podrazdels", влияющее на разметку.
Или, чтобы не указывать непосредственно в методах имена, можно дать им незначащие значения (например, false) и затем проверить, если передали отличный от дефолтного параметр, то его и использовать. Если нет - взять сохранённый в классе.
eai пишет:
Как это под рутовым, кто его пустил то туда
Это я просто даю пример в другую крайность - класс слишком абстрактен и даже непонятно, с чьими правами скрипт работает
В том-то и дело, что представляю, как оно всё выглядит в последние пару лет, а что там было когда-то в глубокой древности - отдельно гуглю.
eai пишет:
Вообще по уму нужно 2 конструктора, пустой и с параметрами, но к сожалению PHP это не поддерживает.
А значения по-умолчанию для чего ещё даны? Это-то как раз не сложно сделать.
eai пишет:
но нужно иметь "насильный" метод тоже
Это не спорю, нужно. Можно даже его же в деструкторе и вызывать. Это просто к тому, что пускай класс сам закрывает соединение, раз уж его можно этому научить
eai пишет:
Баа.таблица - плохой вариант, потому что не таблица а запрос!
Кроме того это нарушает принцип абстракции, запрос независит от БД
Да, это не самый верный вариант, но, в некоторых случаях единственный возможный. А в случае класса, реализующего соединение с БД, наоборот, указание БД по-умолчанию, такое же логичное действие, как и указание пользователя, хоста, пароля соединения. Или же, нелогичное, т.к. тогда не видно, куда коннектится и под чьим именем скрипт. Может он под рутовым пользователем сидит в базе?
eai пишет:
Кроме того это нарушает принцип абстракции, апрос независит от БД
А ведь всё равно надо будет шерстить скрипты при изменении имени БД, хоть для указания set_db($db);, хоть для запросов.
Либо, аналогично, тянуть переменную с именем вторичной БД и вставлять это имя в запросы через обычную конкатенацию.
Страуструп токачто поперхнулся . Идиологический спор. Для сторонников процедурного программирования все что я пишу полная ахинея, им я доказывать ничего ен собираюсь, они просто идут иным путем и все. Все что я написал только для тех кто любит ООП
Я ничего не имею против ООП, наоборот, считаю, что штука полезная, особенно в области разделения видимости и взаимодействия объектов (в том числе с единым интерфейсом и иерархическими описаниями наследований).
Например, относительно GD, ImageMagick весьма удобный класс. Хотя бы тем, что тип файла распознает самостоятельно
Но всё на ООП делать - не стоит. А то может echo надо в класс воткнуть и запретить вывод?
eai пишет:
Ну не тока виндовый, они делали сие для линукс, но ен пошо в массы, не нашо спроса к сожалению.
Ну потому и пишу "де-факто" ;) В далёком 2002 (когда выпустили под линуха делфю) году у меня не то, что линуха не стояло, вообще ПК не было
eai пишет:
А не проще ли просто возложить разницу трактовки запросов на обертку?
Не очень... Зачем писать кучу кода, который ещё и выполняться будет, отнимая ресурсы, для достаточно постоянной СУБД?
eai пишет:
if (!@$DB->query('INSERT INTO tbl(id, field) VALUES(1, ?)', $field)) {
Вот, примерно это и спрашивал. Если отдавать заботиться о экранировании и проверке данных на корректность единожды написанному методу, то это уже неплохой повод использовать такие классы. Правда, если они при этом не потребляют ресурсов в пару раз больше всего скрипта
А то по первому сообщению данной возможности не было видно.
И по самому классу:
Я так понимаю, что конструктор инициализирует соединение с БД по дефолтным значениям, определённым в классе?
А $db->set_params($dbhost, $dbname, $dbuser, $dbpasswd, "utf8"); - просто возможность сделать коннект к другой базе? А почему бы не передавать эти данные сразу конструктору, чтобы класс не создавал дважды соединение?
Почему бы закрытие соединения не вынести в метод __destruct? Тогда будет закрываться самостоятельно. (или я плохо понимаю, когда этот метод вызывается?)
Выбор БД я бы определил тоже по-умолчанию, т.к. в рамках 1 проекта БД меняется не слишком часто и в крайнем можно обратиться к ней по полному имени - т.е. база.таблица.имя_поля
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 11869
