Александра: студию советовать не буду. Выбирайте сами по своему ценнику.
Компания может подсунуть кого угодно, вот только все равно ЕЙ поддерживать проект в дальнейшем (если вы правильно составите договор).
PS
С компании можно стрясти деньги через суд. С фрилансера-одиночки вы в лучшем случае пару рублей на завтра стрясете.
Александра: это все громкие и красивые слова, но реальность куда прозаичнее...
>В идеале хочется найти разработчика, для которого это станет не просто средством зарабатывания, а своим делом!
До тех пор, пока ему не нужно будет думать о будущем и как прокормить семью. Тут вам подойдет молодой и амбициозный разработчик, но скорее всего с небольшим опытом, что в конечном итоге скажется на качестве проекта.
>Последующее развитие не менее интересное
Это очень утомительное и нудное занятие, которое при неправильной архитектуре превращается в кошмар.
>Человек, любящий находить решение непростым задачам не сбежит!
Где вы все находите подобные лозунги? Вы прочитали учебник "Как мотивировать рабов"?
Что вообще такое "находить решение непростым задачам"?
Что по вашему "непростые задачи"?
Вы не понимаете одного, что все ваши розовые пони будут убиты в один миг, когда разработчик решит уйти. А поддержка чужого кода обойдется вам куда дороже, чем если бы вы изначально работали со студией.
Александра:
>Не вижу причины разработчику пропадать
Всякое может быть. Фрилансеры-одиночки имеют свойство пропадать в самый неподходящий момент.
Тем более если проект долгосрочный, то риск увеличивается.
Так же вы забываете про поддержку проекта. Фрилансер-одиночка может закончить и сдать проект, но вот с поддержкой могут возникнуть проблемы, и вам придется искать нового исполнителя, которому придется разбираться в куче кода написанного другим разработчиком.
С фирмой в этом плане проще.
Станислав Почепко: можно сделать немного проще:
- переопределить метод newQuery у Model
- использовать механизм scope. Посмотрите как это сделано для SoftDeletes трейта.
Станислав Почепко: если использовать как трейт, то там ничего и не нужно. Просто пилим все необходимые функции, а затем выносим этот функционал в отдельный composer пакет.
Станислав Почепко: зачем пакет? Просто наследуем Eloquent, и переопределяем нужные нам методы. Делаем модель EloquentMutliLanguage и все остальные модели которые должны быть многоязычными наследуем от нее.
Какие именно переводы нужно хранить в БД?
Я для переводов обычно использую стандартные lang файлы, а к БД храню только пути (например: 'settings.general.shutdown') и во view вывожу просто через trans($model->name).
Если не нужен поиск по переводам, то вполне сойдет.
Станислав Почепко: я не думаю что тут можно сделать что-то совсем универсальное и гибкое. Требования всегда разные.
В итоге все равно придется форкать пакет и перепиливать под себя, так как иначе никакой гибкости не будет, слишком много возможных вариантов применения.
Александр Ковальчук: нужно логи смотреть. Возможно хеш неправильно генерится.
Нужно добавить логирование после каждого действия, и смотреть по логам где затык.
kornilov-s: у вас ошибка в тексте. Вы неправильно составляете буквы в слова. Буквы должны быть составлены так:
"Подключил данный плагин. Захожу на страницу комментариев, оставляю комментарий, но не срабатывает. Я делаю так {описание}. Ожидаю получить {описание}, но получаю {описание}."
Кирилл Несмеянов:
>А рефакторинг зачастую скучное и унылое дело, как следствие смысла смотреть его не особо много.
Как раз таки рефакторинг был бы полезен новичкам, так как это одна из сложнейших тем для освоения.
Andrzej Wielski: именно поэтому стоит отказаться от готовых панелей. Они максимум подходят для простенького блога, или homepage. Что-то сложнее обычных CRUD - и вы почувствуете острую боль чуть-ниже спины.
Виктор: никак.
>Например, у модели 10-15 связей belongsToMany и нужно их сохранять вместе с моделью.
belongsToMany - нельзя сохранять вместе с моделью. Вы это делаете отдельно, для каждой конкретной связи, через $model->{связь}()->create/update/sync/attach().
У Eloquent нету возможности узнать прописанные связи, пока вы их явно не вызовите.
