если их там 500+будет парсинг займет много времениЕстественно, по уму надо таскать только свежие/обновленные, иначе точно наступит жпа. А со свежими естественно выборка уже будет совсем небольшой.
превратить их в объекты javascript и соответственно работать с ними как с объектами js вставляя и перемещая их на странице... Понятно, что я могу вставить их в тег scriptОчевидно, что все что вы хотите получать как объект жс, должно быть жс. По этому - да, это будет сформированный в шаблоне кусок скрипта, с соответствующим json представлением объектов. Есть куча методов этого не делать, например парсить сформированные хтмл данные, или еще как-либо извращаться, но если вам нужны именно объекты без заморочек - только через скрипт (собсно аяксом они и попадают внутрь скрипта, в контекст вызывающего объекта).
сомневаюсь, что на вакансию джуна будет человек, знающий jquery,ajax запросы, да еще и связав их между собой и php.Не сомневайтесь, там делов на 5 минут посмотреть как это делается и понять как работает, дальше все обычно просто. А используется все это практически в каждом проекте. Короче жс худо-бедно но надо знать.
что-то с ними делать по таймеру.
Да и хочется возникновения события вовремя, а не когда там сработает очередной поиск по cron.Так по таймеру, или по експирации? Если у вас речь идет о каком-то событии типа "просрочено" или "напомнить", делайте просто выборку с учетом условия при запросе данных.
сообщение - это три значения: id, from_id (отправитель), to_id (получатель), msg (сообщение).Точно три??? А то я плохо считаю на пальцах... А еще неплохо было бы дату сообщения как то хранить, и собсно по ней сортировать...
Мы получим дупликаты. Как поступить?Дубликаты чего?
Как поступить?Зависит от того что вам нужно, в приведенных запросах вы получаете всю выборку, так как лимит на количество записей у вас не обозначен. Последний запрос с ограничением в одну запись я думаю подойдет, но я бы все же рекомендовал добавить дату (чисто по логике- хотелось бы знать кто и что когда кому отправлял) и уже по дате делал ордер.
Параметр который я хочу передавать это ключ, который у каждого пользователя свой.Если у каждого пользователя он свой, то зачем вам его куда-то писать на фронте? Проверяйте это на сервере.
Я бы хотела передавать этот ключ когда пользователь заполняет форму авторизации, что бы прописать, что если логин: Петя, то передаем ключ 123, если логин Вася передают ключ 443.Очень интересно как вы будете знать что это Петя, если пользователь еще не авторизирован?
конечно ключ буду передавать через скрытое поле.Даа, это конечно же самый безопасный метод передачи ключей, прям по заветам Сноудена...
Файл RouteController.php обрабатывает URLуже плохо, контроллер не должен знать что-то про урл и прочие переменные извне. Для этого есть роутер и реквест.
и делает вывод о типе контроллера (гость, авторизованный пользователь или администратор).Как тип контроллера соотносится с ролью пользователя?
Создаёт объект этого контроллера и отправляет в него аргументами (str)имя контроллера и (str) полученный URL.У вас же уже вызван контроллер, RouteController.php, либо он не контроллер, либо зачем тогда снова контроллер создавать? И зачем ему урл?
Эти аргументы попадают в родительский контроллер файла Controller.php и оттуда далее используются в условном ветвлении и передаются в соответствующие функции, где дальше из этих функций опять передаются в нужные функции.Сложнааа, слоожжнаа (с) Карина. Очень запутанно и очень странно работает ваша творческая мысль.
Чисто ради эксперимента решил вынести поле car_color_id в отдельную таблицу,А надо делать это во первых на постоянной основе, а во вторых и для других справочных полей сделать то же самое.
Запрос выглядит так : ... бред поскипан...Запрос должен быть с джоином, со связью через первичный ключ таблицы car_colors_info и соответственно car_color_id.
т.е. соотвественно есть айди цвета, ну и из основной таблицы мы можем по этому айди найти нужный нам цветНа деле же вы почему то ищете по имени цвета - айди цвета, и по нему уже синие машины...
