• Можно ли получаемым путем ajax-запроса php-скриптом (который возвращает json) установить cookie?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Да. Запрос и ответ через AJAX ничем не отличается от обычного запроса страницы через адресную строку браузера.
    Ответ написан
    1 комментарий
  • Велосипед "ORM" для автоматизации. Следует ли продолжать и в каком направлении? Интересно ли?

    trevoga_su
    @trevoga_su
    1 - Полезно ли это будет хоть кому-то кроме меня?
    нет, но для тебя это может стать вполне приемлемым инструментом, если отточишь до блеска.

    2 - В каком направлении двигаться и в чем косяки такого способа работы с базой?
    твой косяк в том, что ты пишешь сам не понимая чего и называешь это все очень громкими именами, такими как ORM
    при этом ты все смешал в кучу и я не вижу тут никакой ORM
    я вижу попытку написать 1001 никому не нужный билдер запросов

    ORM должна работать на основе паттернов, таких как ActiveRecord или DataMapper, получать объекты моделей, а не просто stdClass и транслировать эти объекты обратно в базу:

    data-mapper.gif

    вот эти все дрочи
    Model::data(array("status"=>2))->where(array("id"=>2))->update();
    они никому не нужны. потому что реальные запросы гораздо более сложны, чем выборка по одному условию where. есть запросы, которые просто невозможно уложить в билдеры. ты же делаешь акцент на билдеры, а должен делать на ORM. Вот тебе пример data mapper класса. для его работоспособности используется простой билдер, но сложный sql пишется руками. и практически всегда возвращаются не просто объекты, а объекты моделей, ассоциируемые с этим data mapper. Обрати внимание, что почти в каждом методе вызываются
    return parent::result2objects(...);
    return parent::findModelListByParams($params);
    return parent::findModelByParams($params);


    т.е. ORM всегда отдает реальные доменные объекты, а не просто stdClass.
    Ответ написан
    Комментировать
  • Странное поведение кода return $status/true. В какую сторону копать?

    VladimirAndreev
    @VladimirAndreev
    php web dev
    а если на return false поменять - остается ошибка?
    Ответ написан
    Комментировать
  • Как правильно реализовать ООП класс базы данных с PDO?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Я уже отвечал как-то на подобный вопрос. И не один раз. И не два.
    Поскольку мозги всех пользователей пхп ходят по одним и тем же рельсам, не сворачивая. Впрочем, не всех. 85% всю жизнь продолжают писать mysl_query, которую выучили из видеоурока, и не видят в этом проблем. И только у самых талантливых 15-и процентов в какой-то момент возникает мысль ВСЁ АВТОМАТИЗИРОВАТЬ. Это, на самом деле, хороший знак. Такое желание как раз и отличает потенциального программиста от клепальщика гуано-кода.

    Но всё портит недостаток знаний в SQL. Искренне полагая SQL не более чем key-value хранилищем, они всерьез уверены в том, что функция select() с двумя аргументами - это все что им надо.

    Настоятельно рекомендую прочесть аргументацию по ссылке выше.

    После этого понять, что существует ТРИ класса классов для работы с БД:

    1. DB-хелпер. Класс, берущий на себя всю грязную работу по исполнению запросов. В случае с ПДО не сильно-то и нужен. Позволяет исполнять любые запросы. НИКАКИХ функций типа select(), ограничивающих функциональность, в нем быть не должно ни в коем случае.
    2. Query builder. Функция типа select() может быть только в квери билдере, который маскирует SQL в функции РНР. Заведомо ущербен по сравнению с первым, но зато позволяет использовать запросы более сложные, чем ORM.
    3. ORM. То, что начинающему пользователю на самом деле нужно, но он об этом просто не догадывается. Как раз та самая волшебная палочка, которая делает примитивное доставание данных из базы по первичному ключу столь маняще единообразным.

    Cамое главное, что надо понять:
    Все вышеперечисленное - это РАЗНЫЕ типы классов, не имеющие между собой ничего общего.
    И не пытаться под видом первого городить нежизнеспособное второе, имея в виду третье. Надо очень четко понимать, что сначала делаем первое, а потом, на его основе - либо второе, либо третье. Но не все вместе.

    А можно не пытаться изобретать велосипед, а использовать готовое. Например - популярный фреймворк. Тогда желаемая функция будет выглядеть вот так:

    public function viewUser($id)
    {
        return User::model()->findByPk($id);
    }

    Это в самом предпочтительном случае - при использовании ORM.
    На квери билдере это будет что-то вроде
    public function viewUser($id)
    {
        return DB::select('*')->from('users')->where("id", '=', $id);
    }


    При этом можно использовать и чистый SQL. Запрос прямо в классе юзера - это не так уж и страшно. Тем более, что есть такие запросы, которые по другому просто не выполнишь. Другое дело, что всю работу по исполнению запроса должен брать на себя хелпер. Пример можно посмотреть по ссылке выше - там хоть и SQL , но того ужаса, который здесь, нету:
    public function viewUser($id)
    {
        $sql = 'SELECT * FROM users WHERE id=?';
        return DB::prepare($sql)->execute([$id])->fetch();
    }
    Дальнейшую работы над классом можно производить только после того как ты определишься, какой именно класс ты хочешь написать.
    Ответ написан