Ну основные, на мой взгляд, паттерны в случае с php - абстрактный класс, синглтон, мультитон, интерфейс, наследование-инкапсуляция-полиморфизм, active record, MVC (и все вытекающие), трейты с недавних пор. То, что вспомнилось. А так все сильно зависит от компании и конкретного собеседующего. Может так получится, что настолько классный и обаятельный парень, что ты придешь и всех покоришь, и тебя ничего этого спрашивать не будут. Да и мне кажется, что для собеседования рассказать о своем опыте в первую очередь.
Юрий Пузыня: Там нет такого понятия в принципе. Говоря слово "класс" про js человек либо снисходит до менее просвещенных людей, чтобы им объяснить что-то через понятия, о которых они знают (провести аналогии), либо сам не понимает js.
Все - объекты, в частности и функции, и функции-конструкторы (как бы "классы"). И это ломает мозг людям, которые сначала познали классический подход к ООП. Поэтому и нужно отказаться от слова "класс", иначе не будет понимания.
Quber: Можно весь блок обернуть в label, а в него уже пихнуть инпут и подпись в спане. В итоге вся эта хренотень будет кликабельной. Собсвтенно, сам этот лейбл и его содержимое вполне можно сделать как на картинке и не будет семантически лишней разметки.
Алексей: не знаю, на мой взгляд достаточно взглянуть на архитектуру опенкарта, чтобы понять, что это несерьезный инструмент. Не подумайте, что я фанат битрикса, я вполне адекватно его воспринимаю, но для интернет-магазинов на мой взгляд одним из самых оптимальных решений является именно он. Насчет глючности - не знаю, не видел. Может быть потому, что я никогда не использую компоненты, идущие в коробке, но с API за все время я столкнулся по сути только с 2-мя проблемами (но зато какими...): работа с файлами, прикрепленными к элементам инфоблока и в какой-то функции (точно уже не вспомню) мистический глюк, который проявлялся, когда в нее передаешь литерал массива (до сих пор не понимаю, в чем была проблема).
Sergeniy: Не менять, а 1 раз написать и использовать где угодно. Так, чтобы все работало (это возможно, да). А стили, к сожалению, придется менять под каждый проект и для плагина, и для своего решения. И я не говорю, что готовые модули использовать нельзя. Можно. Но тебе нужно потратить время на то, чтобы плагин подключить и разобраться в нем. Столько же или меньше времени лично у меня уходит на велосипед. Поэтому я выбираю велосипед.
Sergeniy:
Не придется кодить. Кодить != потратить больше времени. Настраивать плагин и его стили, кстати, тоже так или иначе в коде придется.
Esc. Еще немного кода 1 раз, использование его же в дальнейшем. В итоге время скорее всего сэкономишь.
Вперед-назад. Аналогично.
Адаптивность. Не самая сложная задача, согласись :) Тут даже без media queries легко обойтись - делаешь overflow: auto + max-width и дело в шляпе.
Все браузеры. При использовании jQuery проблем с браузером не будет, а используют его чуть менее, чем все. Стили тоже не вызывают проблем для IE >= 9 (а на 8 лично я уже начал забивать).
Страдания. Не знаю, я не страдал.
Sergeniy: Так, и насколько меньше времени у тебя займет использование стороннего плагина в случае с индивидуальным дизайном сайта? Я не говорю про админки, прототипы и т.п., где, понятное дело, просто берешь какой-нибудь бутстрап и не заморачиваешься, а именно про случай с индивидуальным дизайном.
То есть это что-то достаточно сложное. Это дела не меняет, любая универсальная CMS с этим справится. Тут вопрос больше не в инструменте, а в том, с чем имел дело программист(ы), который займется разработкой. Лично я бы такое на битриксе делать не стал, выбрал бы или drupal, или ruby on rails вообще.
Ну все равно же на каждом проекте индивидуальный дизайн, что не дает возможности все настраивать за 5 минут в любом случае. Поддержка IE без анимации вполне возможна, тут все зависит от css для модального окна. С анимацией для IE - да, придется заменять ее на вызовы jQuery.animate. Для вылета и изгибания (и еще много для чего) вполне хватит средств css. С помощью 2-х свойств, transform и opacity, можно просто чудеса творить, хватило бы фантазии. Да и фантазии в принципе у многих до нас уже хватило, в гугле примеров огромное количество можно найти. Единственное, чего тут можно добавить - подгрузку с ajax, но это еще 2 строчки добавить в js и все.
Ой, ошибся, я ошибся. Вот так надо:
...
LEFT JOIN (
SELECT MIN(id) as id, inner.pluginid as pluginid
FROM jml_jquery_images inner
GROUP BY inner.pluginid
) ji_first_ids ON jp.pluginid = ji_first_ids.pluginid
...
Не совсем понял, что значит "group будет занят"? На самом деле я невнимательно прочитал твой вопрос, поэтому поправка небольшая: если тебе нужно выбрать именно первую картинку, то без подзапроса не обойтись.
SELECT jp.*, ji.image as first_image
FROM jpl_jquery_plugins jp
LEFT JOIN (
SELECT MIN(id) as id FROM jml_jquery_images WHERE pluginid = jp.id GROUP BY pluginid
) ji_first_ids
LEFT JOIN jml_jquery_images ji ON ji_first_ids.id = ji.id
ну и так далее. Я, правда, не могу проверить, но это должно сработать
Left join соединяет строки из двух таблиц. Как ты себе представляешь соединение таблиц при отношении один-ко-многим, чтобы при этом получалось по одной строке из исходной таблицы? Left join работает не так, как ты думаешь. Он дублирует записи из исходной таблицы по количеству записей из присоединенной. Я поэтому и говорю, что в твоем случае нужен GROUP BY, иначе будут дубли, и это нормальное поведение базы. Если тебе не нужны сами картинки, а только их наличие, то можешь вместо конкатенации написать COUNT(ji.id) as count, например, и потом проверять на count > 0.
Angular way - это ничего не делать в коде для того, чтобы анимация работала. В том и суть, что единственным куском кода, который включает анимации на сайте является angular.module('myApp', [..., 'ngAnimate', ...]). Ну, не считая css, разумеется. Ты четко разделяешь логику и внешний вид данных (хотя для ангуляра это немного размыто, потому что много логики в представлениях, но это не касается стилей).
Да и создание элементов через $compile - это далеко не angular way, нужно всю разметку выносить в шаблоны или хотя бы в строку template, если там ее почти нет.
С svg точно не знаю, но он же все равно остается подмножеством xml, доступным в дереве документа, то есть все директивы и стили можно применять к элементам svg так же, как и к обычным html элементам, а значит поведение будет ровно таким же. Но это я предполагаю, сам непосредственно с этим дела не имел. Ну и такое справедливо только для inline svg, по-другому включить svg в dom вряд ли получится, а, следовательно, не получится и взаимодействовать с ним.
А, извиняюсь, не обратил внимание на динамическое создание элемента. В таком случае лучше его создавать, а в scope директивы загнать булевую переменную типа show и сделать шаблон для твоего попапа с ng-show="show". Ну и дальше все, что я писал выше.
