Андрей, Далеко ходить не надо, вы можете на Тостере добавлять, редактировать, удалять и просматривать свои записи. Правда тут нет API, но можно обойтись и без API
Думаю как раз обновление винды и повлияло. У меня после последнего обновления винды OpenServer вообще начал работу, как-будто только установился (первый запуск). Попробуйте переустановить OpenServer (заодно можно свежую версию скачать).
Вы дайте свой вариант решения, если он не будет работать, то на Тостере смогут подсказать. А так создавать за вас полностью готовое решение никто не будет. В лучшем случае могут дать ссылку, но их может дать и сам гугл.
Если база данных SQL, то $obj это не массив объектов таблицы this_table, а массив строк таблицы. В любом случае надо как-то указать, что строки выборки должны определяться как объекты. Не думаю, что это возможно без определения класса.
Но вопрос интересный, подписываюсь.
Валерий, и выглядит сформированный запрос ? в кавычках `user`?
Есть подозрение что вы где-то дважды где-то обрамляете в двойные скобки. Я такое видел, когда формировался запрос в виде {`user`}, но это было по причине того, что в одной из модели стояли тройные скобки. В вашем случае почему-то получаются аж 4 скобки, потому это преобразуется в результате
{{mydb.`user`}}
Одним словом ошибка не методе tableName(), а тем где формируется уже сам запрос.
raulvodov,
Могу добавить ещё кое-что. Я вообще ни разу ни верстальщик, и тем более не дизайнер. Моя работа обычно начинается с того момента, когда мне дают сверстанный шаблон и я начинаю создавать сайт.
И могу сказать, что в процессе создания сайта возникают куча недоработок, которые не были заложены на этапе проектирования, и как следствие этого не были созданы ни макеты, ни шаблон. К примеру, сверстали красивую форму для обратной связи. А как будут выглядеть ошибки если пользователь ввел неправильные данные? Этого ни дизайнер, ни верстальщик не сделали. И приходится это делать программисту.
И если там стоит бутстрап, то я выведу обычный alert class="danger", и у меня на это уйдет 15 секунд. А если там собственная верстка, то мне придется самому и дизайнить и верстать отображение сообщений об ошибке, и на это у меня уйдет намного больше времени, особенно с учетом, что это не мой профессиональный профиль.
Кода люди работают в команде, лучше стремиться использовать фремворки. Но иногда есть требования заказчика - это превыше всего. Если он скажет никаких фреймворков, и только нативный код, то будем писать именно так. :)
raulvodov, лучше использовать известную сетку, ведь вашу работу через год-два могут начать дорабатывать. И если там будет известная сетка, то будет намного проще продолжить/исправить. А если там будет собственная, то другим придется разбираться.
Но если делаете сайт для себя, то вообще без разницы, так как только вы с ним и будете возиться. Написать собственную сетку в этом случае будет интересней самому, для получения опыта.
Вообще есть негласное правило. Если проект делается для кого-то, то лучше использовать фреймворки, так как потом им будет легче поддерживать. Если для себя, то можно экспериментировать с чем угодно - это только ваше и останется тоже только вашим. И это касается не только верстки, но и любого кодинга вообще.
Вы попробуйте без SQL обычным логическим языком описать подобную выборку.
Я, например, вижу, что те пользователи, что попадают под категорию "более 3 дней", будут автоматически попадать и в две другие категории.
Как вы собираетесь их вообще разделять на группы? Какие бы условия вы им поставили?
Более того, я плохо пока представляю как должен выглядеть вывод этих данных? Можно пример как бы вы хотели его получить. Потом можно подумать и о запросе.
Ankhena, Верно, но дизайнер делает то, что есть в ТЗ. А в ТЗ такие мелочи не описываются, да это просто не возможно сделать, чтобы прописать каждую деталь. Например, сайт определяет город. И в шапке в макете в качестве образца написано "Москва", а если по факту геобаза выдает "Балашиха, Московская область", то такая надпись просто не влезает по задумке дизайнера, и верстальщик не заложил, что город может иметь такое длинное название и в результате всё начинает разъезжаться.
Ankhena, Поверьте, если вас будут просить аккуратно что-то доделать, то вы с утра до вечера будете доделывать такие вещи. Программисту проще самому доделать, чем дать вам, и ждать пока вы доделаете, а потом продолжить дальше свою работу. Допиливать приходится достаточно часто. Я привел только один пример, но могу привести десятки примеров только с одного проекта. При верстке всевозможные варианты сразу не создать. И чаще всего это то, что текст в верстке и текст у живого сайта сильно отличается и тут начинаются проблемы, то слово слишком длинное, то оно слишком короткое. То попап не оформлен, то модальное окно не создано при верстке. А сообщения об ошибках и успехе отправки форм вообще обычно не создаются верстальщиками.
Алибек Кулсеитов,
вот вы собираетесь передавать это на бекенд, а там жалуются, что нет бутстрапа. Я сам тоже бы жаловался. Вы же когда верстаете то не создаете все возможные варианты. Например, как будет выглядеть ошибка если пользователь ввел не тот логин и пароль? И программисту зная бутстрап будет очень просто добавить див с alert danger. А если бутстрапа не будет, то ему придется самому создавать какие-то классы, или прямо в теги добавлять style. И потратит он на это время куда больше времени.
Вы не представляете сколько программисту приходится допиливать после верстальщика. И с будстрапом это сделать намного проще чем без него.
Дмитрий Лахно, cURL - это программа, которая позволяет создавать запросы к удаленному серверу и получать от него ответы без использования браузера. Во многих языках программирования есть надстройки для этой программы, чтобы не вводить консольные команды вручную.
Например, для php
Lander, Как раз таки внимательно прочел. Вы указали одну крайность, когда нет смысла использовать ООП для примитивных вещей, а дополнил ваш ответ тем, что иногда ООП просто не может справится с поставленной задачей, потому используют другую парадигму.