Фреймворки

[Adelf]

@AllReady, timezone устанавливается один раз. В настройках. В случае laravel - config/app.php . Ну, если юзер не настраивает таймзоны под себя конечн...

 

[AllReady]

@AllReady, timezone устанавливается один раз. В настройках. В случае laravel - config/app.php . Ну, если юзер не настраивает таймзоны под себя конечн...

спасибо, не догадался сразу это сделать. Тут меня ругали за статические методы в модели, а какой смысл их делать "не статическими" ?
---
P.S. правильнее будет заменить получение данных с формы дописав use App\Http\Requests; и получать данные при помощи Request::input() ?

 

[Adelf]

P.S. правильнее будет заменить получение данных с формы дописав use App\Http\Requests; и получать данные при помощи Request::input() ?

Нет. Мне все больше нравится подход со специальными Request классами. Есть специальная папка для них - app/Http/Requests

<?php

namespace App\Http\Requests\Clients;

use App\Http\Requests\Request;

class ClientCreateRequest extends Request
{
    public function rules()
    {
        return [
            'name' => 'required',
            'ownersEmail' => 'required|email',
            'administrator_id' => 'required|integer',
        ];
    }

    /**
     * @return string
     */
    public function getName()
    {
        return $this->get('name');
    }

    /**
     * @return string
     */
    public function getOwnersEmail()
    {
        return $this->get('ownersEmail');
    }

    /**
     * @return int
     */
    public function getAdministratorId()
    {
        return $this->get('administrator_id');
    }
}

И дальше уже юзаем этот обьект вместо обычного Request:

public function store(ClientCreateRequest $request)
{
    ...
    $request->getOwnersEmail();
    ...
}

Ну со стороны кажется ненужным оверкодингом... но мне все больше и больше нравится. Почти нет магических строк в коде.

 

[AllReady]

Нет. Мне все больше нравится подход со специальными Request классами. Есть специальная папка для них - app/Http/Requests
Ну со стороны кажется ненужным оверкодингом... но мне все больше и больше нравится. Почти нет магических строк в коде.

Спасибо. Буду пробовать. А сколько вообще таких методов в ларавеле, чтобы передавать данные с форм ? И еще, я пользовался классом DB чтобы выполнить определенный запрос, а как обычный запрос с join'ом произвести в eloquent ? Примеры смотрел, у меня на выходе получается нереально большой массив (или объект, уже не помню)
---
UPD сделал вот таким вариантом. То есть в модели постов:

$posts = Post::join('users', 'posts.user_id', '=', 'users.id')
            ->select('users.name', 'posts.title', 'posts.subtitle', 'posts.user_id', 'posts.date_create', 'posts.url')
            ->getQuery()
            ->get();

но были варианты которые у меня не получались. Там создавались методы с названием таблицы с которой мы хотим связать и которые возвращали: $this->hasMany('App\Comment'), $this->belongsTo('App\Post') и т.д..
Мой вариант подойдет ? или все же попробовать с этими методами ?

 

[AmdY]

@AllReady вот на этом примере ты можешь сам понять правильность-неправильность применения ORM. Ибо твой запрос сводится к

$post = Post::firstOrFail($id);
$post->user->name; //  фреймворк сам подтянет по связи юзеров
foreach($post->comments as $comment) {
    echo $comment->title, // подтянули коммент
        ' ',
        $comment->user->name; // подтянули у коммента пользователя.
}

Здесь будут ленивые и неоптимальные запросы, в доке почитаешь как пользоваться with

 

[fixxxer]

@AllReady, ты неправильно понимаешь, что такое модель. Не ты один, это типичное заблуждение среди php разработчиков, я когда-то тоже неправильно понимал.

Модель это не то, что работает с базой Это вообще нерелевантно. Посмотри в словаре определение слова "модель". Вот и в программировании то же самое, модель - это некоторое идеализированное представление какой-то вещи в виде объекта на ООП-языке. Условно говоря - есть пользователь, у него есть имя и email, и он умеет менять свой емейл на другой. Соответственно, есть класс User, у которого есть свойства name, email, и метод changeEmail($newEmail). Пока про хранение в базе вообще не говорим, представим себе что пока базы нет и все хранится в оперативной памяти. Пока надо понимать, что ООП это работа не с неструктурированными массивами, а с классами и объектами, и на уровне моделей каждый класс - это программное представление какой-то сущности.

Соответственно, далее идет вопрос о том, как объекты сохранять в базу и наоборот доставать оттуда. В любом случае нам надо сопоставить свойства объектов с полями и таблицами в базе, а с этим знанием уже генерировать sql-запросы и разбирать результаты выборок, заполняя ими свойства объектов и наоборот. Есть два подхода - засунуть работу с базой и правила сопоставления внутрь модели (это называется Active Record), или сделать это отдельно (это называется Data Mapper). У AR есть масса недостатков, о которых можно поговорить как-нибудь в другой раз, но для простых контентных проектов, где мало бизнес-логики, вполне годится. В Laravel реализован Active Record, называется Eloquent.

Как в Laravel выглядит работа с AR, показал @AmdY в предыдущем комментарии. Почитай документацию, это важная вещь, надо это понять и освоить.

 

[Absinthe]

Ну, если юзер не настраивает таймзоны под себя конечн...

А зачем это настраивать и менять ее на бэкенде, если фронтенд уже обладает этими данными?
Не лучше ли на бэкенде работать с UTC, а на клиенте формировать правильные даты?

К тому же изменения часовых поясов или неправильный выбор пользователя не будут влиять.

 

[Adelf]

@Absinthe, мне нравится этот подход. Но на уровне топик стартера именно laravel является и фронтэндом и бэкэндом.

 

[флоппик]

А зачем это настраивать и менять ее на бэкенде, если фронтенд уже обладает этими данными?
К тому же изменения часовых поясов или неправильный выбор пользователя не будут влиять.

Это при условии, что ты от фронта получаешь таймзону пользователя при сохранении данных, иначе ты сохранишь не то время.

 

[Absinthe]

@Absinthe, мне нравится этот подход. Но на уровне топик стартера именно laravel является и фронтэндом и бэкэндом.

Вот на уровне вьюхи ларавела и надо просто добавить к span, содержащим дату, определенный класс.
А с остальным очередной jQuery плагин справится.

Это при условии, что ты от фронта получаешь таймзону пользователя при сохранении данных, иначе ты сохранишь не то время.

Бэкенду не нужно знать таймзону совсем.

 

[Вурдалак]

Бэкенду не нужно знать таймзону совсем.

It depends. Например, фича «не беспокоить ночью».

 

[Absinthe]

It depends. Например, фича «не беспокоить ночью».

В том числе и приложения вроде календарей ее должны знать.
Но таких единицы среди тех приложений, которые показывают время пользователю. И к ним нужен более серьезный подход.

 

[флоппик]

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

 

[AmdY]

А зачем это настраивать и менять ее на бэкенде, если фронтенд уже обладает этими данными?
Не лучше ли на бэкенде работать с UTC, а на клиенте формировать правильные даты?

К тому же изменения часовых поясов или неправильный выбор пользователя не будут влиять.

Ну так правильно, дефолтная зона для приложения должна быть UTC, а пользовательскую применяем только когда нужно. А ТС выставлял москальскую таймзону да ещё в каждом месте использования карбона.

 

[grigori]

дефолтная таймзона может быть любой, сейчас и базы и php отлично умеют пересчитывать, если не забыть о ней

 

[Redjik]

ой все
http://habrahabr.ru/company/mailru/blog/242645/

 

[AllReady]

в доке почитаешь как пользоваться with

Это же тоже относится к Eloquent ?

 

[AllReady]

@AllReady, ты неправильно понимаешь, что такое модель. Не ты один, это типичное заблуждение среди php разработчиков, я когда-то тоже неправильно понимал.

Модель это не то, что работает с базой Это вообще нерелевантно. Посмотри в словаре определение слова "модель". Вот и в программировании то же самое, модель - это некоторое идеализированное представление какой-то вещи в виде объекта на ООП-языке. Условно говоря - есть пользователь, у него есть имя и email, и он умеет менять свой емейл на другой. Соответственно, есть класс User, у которого есть свойства name, email, и метод changeEmail($newEmail). Пока про хранение в базе вообще не говорим, представим себе что пока базы нет и все хранится в оперативной памяти. Пока надо понимать, что ООП это работа не с неструктурированными массивами, а с классами и объектами, и на уровне моделей каждый класс - это программное представление какой-то сущности.

Соответственно, далее идет вопрос о том, как объекты сохранять в базу и наоборот доставать оттуда. В любом случае нам надо сопоставить свойства объектов с полями и таблицами в базе, а с этим знанием уже генерировать sql-запросы и разбирать результаты выборок, заполняя ими свойства объектов и наоборот. Есть два подхода - засунуть работу с базой и правила сопоставления внутрь модели (это называется Active Record), или сделать это отдельно (это называется Data Mapper). У AR есть масса недостатков, о которых можно поговорить как-нибудь в другой раз, но для простых контентных проектов, где мало бизнес-логики, вполне годится. В Laravel реализован Active Record, называется Eloquent.

Как в Laravel выглядит работа с AR, показал @AmdY в предыдущем комментарии. Почитай документацию, это важная вещь, надо это понять и освоить.

Вот из Ваших слов я понял следующее: у каждой таблицы с которой мы собираемся работать, есть своя модель ? Где как раз таки описываются свойства (из ларавела понял еще то, что данные которые пользователю не нужны ставят приватными) и методы, чтобы получить данные с этой таблицы, обновить, удалить и т.д. ?
Недавно мне коротко написали: Модели: Обращение к базе данных обмен данными с базой
У меня из головы никак не выходит следующее описание модели:
есть у нас модель например User которая работает с таблицей users. Она наследуется от общего класса Model где как раз таки идет соединение с БД в конструкторе. В самой же модели User в конструкторе пишется что-то вроде parent::__construct(); просто чтобы получить соединение с бд и дальше в методах модели просто используются методы с предка Model например на выборку и т.д..
---
Или например:
На примере чата, в models создаем файл chat.php, где создаем класс:

Class Chat extends Model {
// функции, получить все сообщения, по отдельности, удаление и т.д.. в общем то что нам нужно
  public function getAll() {
    return select('select * from chat');
  }
}

А в этом случае в Model обычные методы вроде public function select($query) {
return mysqli_query($this->link, $query);
}
---
что то я уже сам запутался. я просмотрел столько уроков, задавал на тостере, форумах столько вопросов

 

[AnrDaemon]

У таблиц нет моделей… Таблицы это вообще что-то из области хранения данных. Модель - это само приложение. Его логика.

 

[AllReady]

У таблиц нет моделей… Таблицы это вообще что-то из области хранения данных. Модель - это само приложение. Его логика.

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