@SilenceOfWinter где вы это в условии увидели? Автор судя по всему модифицирует какой-то компонент для joomla, а там /administrator это директория, и с учетом index.php?com... находиться где-то в другом месте оно так же не может.
@CAMOKPYT с каких это пор в JS считается моветоном юзать фреймворки?
у меня позиция простая. Знать VanilaJS что бы писать с использованием любого фреймворка на JS просто нужно. Нужно понимать как оно там работает. Нужно понимать отличие "нормального ООП" от прототипного наследования что бы как раз не страдать фигней и не пытаться писать "классы" в JS. Нужно понимать тонкости работы с замыканиями, учиться искать утечки памяти в оных и т.д.
Я знаю людей которые не переносят фреймворков потому что все они имеют фатальный недостаток, они сложные, они "медленные". Помню на одном из собеседований чувак пытался меня убедить что "angular.js медленный и потому мы юзаем jquery+backbone". Я тихо улыбнулся и пошел дальше писать свой "медленный" код который по бенчмаркам обгоняет тот же backbone + jquery + underscore и при этом занимает раза в два меньше LoC.
Это проблема не технологии а людей. Всегда найдутся выскочки которые скажут "да говно этот твой фреймворк/библиотека, 100% медленно будет, давай лучше с нуля!". Без профилирования, просто предположения делают на основе которого потом фэйлится проект.
@vicodin если при использовании какого-либо решения производительность труда повышается при незначительном падении производительсноти то логично что это решение лучше. Производительность уже никого не заботит, только 0,01% проектов имеют под собой хоть какие-то основания париться. Это так, к слову.
@vohaha есть директивы для табов, можно попробовать адаптировать. Можно попробовать написать свои директивы для тех же целей.
Вообще как, такие вещи всегда жедательно выносить в директиву так как можно реюзать потом, но заранее все это делать имеет смысл только если вы не делаете рефакторинга уже написанного кода.
VanilaJS, Ванильный JS, старый добрый JS, без фреймворков библиотек и прочего. Это просто старый добрый классический JS. А сайт "фреймворка" это просто шутка такая.
@mind3 нет, я обычно делаю migration:diff который генерит вам миграцию на основе разницы текущего состояния базы данных и того что у вас в мэппинге описано (да, если вы сначала вносите в базу правки и потом пишете миграцию то работать это не будет). Затем я просто дописываю туда то, что нужно. Например перенос данных, их модификация или чего еще. Обычно я стараюсь не делать изменения в структуре такие, что требуется как-то что-то делать с данными в таблицах, но иногда приходится.
Ситуация с удаляет и создает индексы больше похоже на действие schema:update так как оно меняет названия индексов. В любом случае вам стоит разобрсять в том SQL который генерит вам doctrine.
И да, если вы не поняли что я написал или ваш процесс отличается, распишите, возможно вы что-то делаете по другому и из-за этого у вас проблемы.
@PiloTeZ если у вас там внезапно поменяется с MySQL/PostgreSQL на elastic search какой с фасеточным поиском, опять же поменяется только реализация репозитория.
@PiloTeZ нет конечно, по сути ваш вариант и нужно тогда реализовывать, просто передавать не массив а объект, и да, стоит разделить на отдельные методы этот самый find и делать все эти if на местах... или вообще придумать так что бы не делать if.
@PiloTeZ для того что бы контроллеры ничего не знали о структуре базы и ввели репозитории со своим интерфейсом.
Например в случае с блогом у вас будут методы у репозитория вида getPublishedPosts, getPostsByTag(Tag $tag), getPostsByAuthor(User $user).
Профит - контроллер или сервис использующий репозиторий не знает где хранится все это добро. Для них это выглядит так же, как если бы вы все в массивах хранили.
Причем хорошей идеей (но слегка оверхэд) было бы выделение всех этих методов в интерфейс и завязывать код на него. Что бы никакой сервис не хотел что бы ему заинджектили инстанс EntityRepository а он хотел бы PostRepositoryInterface получить.
Профит - если у нас разрастется приложение и вместо обращения в базу мы впихнет туда кеширование в памяти, логику инвалидации и т.д. то для клиетского кода ничего не поменяется. Вы сможете даже выкинуть доктрину и все будет работать.
