nepster-web

Алексей Николаев Очень умиляют ответы использовать таблицы с не табличными тегами. Это как гвозди черенком от молотка забивать. Для чего все эти телодвижения ?
У нас есть 2 блока, один на всю ширину, другой который прилипает к какому-то краю. Первая мысль верная, использовать таблицы. Есть свои минусы, ну и новое поколение "крутых" верстальщиков считает это не Тру :) Такие все в гуглах работают обычно, таблицы - старье же!

Второе решение уже требует каких то минимальных знаний в верстке, а это понимание контекстов наложения и поведение потока. Но и тут все не очень сложно, мы знаем что свойство overflow создает новый поток, если оно его конечно не отменяет. А это значит что мы никогда не переместимся под элемент у которого стоит обтекание. Задав это свойство левому столбцу получается то что и планировал ТС. Но тут есть минус, это нарушение семантичного порядка. Блок с обтеканием должен идти первым, что бы его обтекали последующие элементы. Так же вижу проблему с нарушением потока в правом блоке, он получается оторван от контекста.
jsfiddle.net/7dkhyLkv/3

Если бы я решал такую задачу, то скорее всего нивелировал бы минусы табличного подхода (адаптивность) и применил его. Все же для меня очень важен поток документа.

Хотел бы обратиться к новому поколению верстальщиков
Я понимаю что сейчас у вас халява, нет того порога входа в эту отрасль, который был при Maxton, IE6 и первых версиях Netscape. Давайте будем стремиться к стандартам, которые старое поколение так долго создавало для вас(Те кто верстал под эти браузеры меня поймут). Я не утверждаю что этого категорически делать нельзя, хотя в своей практике я не встречал ни одной задачи где это было бы единственным решением. Но ведь это так просто...
Давайте не будем блочным элементам давать табличное поведение, а span'ам блочное. Они не для этого создавались. Ведь это так просто не вкладывать в инлайн элементы блоки, а идти от большего к меньшему. От вас не убудет, а вот вашему, более аккуратному товарищу по верстке будет приятно читать ваш код.

nginx на localhost слушает нужный порт ?
nmap localhost
Сервер ngnix вообще есть в процессах ?
ps aux | grep nginx

git tags

DI именно в вашем случае не при чём. Это способ реализации, а не сама идея. Идея состоит в том, что вам нужно реализовать принцип инверсии зависимостей. То есть начать работать с интерфейсами, а не с конкретными реализациями.

Чтобы быть универсальным и переносимым, модуль не должен знать о моделях извне себя. Вместо этого он должен выражать свои требования в виде интерфейса, а внешние модели этот интерфейс должны реализовывать.

Для вашего примера делаем в модуле Article делаем интерфейсы:

interface ArticleInterface
{
    public function getTitle();
    public function getAuthor();
}

interface ArticleAuthorInterface
{
    public function getName();
    public function getID();
}

Далее в пределах модуля используем только интерфейсы, а не сами модели:

public function renderArticle(ArticleInterface $article)
{
    return $this->renderPartial('_article', [
         'author' => $article->getAuthor(), 
         'title' => $article->getTitle()
    ]);
}

Вне модуля нам придётся реализовать интерфейсы в моделях:

class Article extends ActiveRecord implements ArticleInterface
{
   // ...
}

Скорее всего парсеру просто не нравится содержание файла, а именно в строку затесался недозволенный (скрытый) символ.

initialMinimumValue = Math.round( (startTime[0] * 60) + (startTime[0] * 24 / 60) );
  initialMaximumValue = Math.round( (endTime[0] * 60) + (endTime[0] * 24 / 60) );

может быть, таки:

initialMinimumValue = Math.round( (startTime[0] * 60) + (startTime[1] * 24 / 60) );
  initialMaximumValue = Math.round( (endTime[0] * 60) + (endTime[1] * 24 / 60) );

В файле /etc/php5/fpm/pool.d/www.conf проставьте необходимые права:
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

Потом перезагрузите fpm

sudo service php5-fpm restart

Можно вынести элемент из потока абсолютным позиционированием jsfiddle.net/q72bs1tp/1

Т.е. если внутри элемента с overflow:hidden находится абсолютно позиционированный дочерний элемент, а родитель имеет static позиционирование, то дочерний элемент будет спозиционирован относительно ближайшего в иерархии элемента со свойством position отличным от static и не будет обрезан родителем с overflow:hidden. Тут есть ряд нюансов, но пример кроссбраузерный.

зы: как-то так можно оставить и позиционирование и overflow jsfiddle.net/q72bs1tp/2

Позволить показывать элемент за пределами предка с overflow:hidden невозможно.
А раз селекторы не работают вверх по дереву (пока), то только показывать/скрывать элемент за пределами такого предка. Управляется, конечно, скриптом.

Symfony это конструктор, который поставляется в собранном виде. Но ничто не мешает вам его разобрать и собрать по-своему. Многие критикуют фреймворк за это качество: нет ощущения целостности как у Yii или Laravel. Похожее говорили в свое время про Zend1: монстр, куча несвязанных компонент, лучше я буду кодить в своем уютном CodeIgniter-e.

Symfony Framework - это (грубо) HttpKernel + DependencyInjection Container (DIC) + EventDispatcher.

Главное задачей HttpKernel является конвертирование Request в Response. Для этого он загружает и инициализируется бандлы, создает контейнер (DIC), пытается по Request определить контроллер, выполнить его и убедиться, что результат выполенения контроллера является объектом Response, если нет, то пытается преобразовать результат в Response.

DIC занимается созданием и хранением сервисов, если совсем грубо, то это такой навороченный Registry.

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

Бандлы лучше всего сравнить с плагинами. Есть ядро, которое было описано выше, а бандлы это плагины для него, добавляющие некий функционал (FrameworkBundle, TwigBundle, MonologBundle). FrameworkBundle это основной плагин, который добавляет основной функционал: формы, валидация, сессии, translations. При желании его тоже можно заменить как и любой другой. Другой задачей бандлов является интеграция различных библиотек в ваш проект: twig, monolog, swiftmailer (поставляются с симфони), sphinx, elastic и т.д. Ну и логика приложения так же может быть размещена в бандлах.

Чтобы Symfony узнал про ваш бандл, его необходимо зарегистрировать в AppKernel.

У каждого бандла есть своя конфигурация, с помощью которой он может интегрироваться в Symfony:
1. Регистрация своих сервисов в DIC. Далее вы можете использовать их, например, в контроллере: $container->get('sphinx.search')->query(...)
2. Бандл может повесить свои сервисы на какие-то события. Например, на событие KernelEvents::CONTROLLER, тогда ваш бандл получит управление при подборе контроллера и вы сможете обойти штатный механизм подбора и вернуть свой, который и будет выполнен.
3. Использование тегов. Например, вы создали класс HelloWorldViewHelper и хотите его подключить в Templating. В конфигурации указываете для него тег "templating.helper" и он будет подхвачен Symfony и встроен в шаблонизатор.

Бандлы - самодостаточные модули инкапсулирующие какие-то сервисы и прочую штуку. По сути это расширения для DependencyInjection, если очень грубо.

Модели - это те самые Entity грубо-говоря. Вообще есть такое понятие как Доменная-модель. Это просто структура данных, сущности которыми оперирует бизнес логика. Последняя должна быть инкапсулирована в сервисы (всякие UserManager, PostManager и т.д.). В Yii модели смешаны с сервисным слоем и по этому у вас получается путаница.

Что до кода... есть распространенный подход иметь свой AppBundle и фигачить все в нем. Есть так же рекомендуемый подход - не использовать бандлы вообще. То есть.... бандлы должны быть самодостаточны и их основное предназначение - реюз логики между проектами. Бизнес-логику приложения реюзать у вас не выйдет, поэтому рекомендуется просто писать код и регистрировать его в app/Resources/config/services.yml или что-то в этом духе, как именно решать вам. Профит в том что вы на замарачиваетесь всей этой фигней с бандлами и у вас возникает меньше вопросов по структуре. А если же вы захотели что-то вынести в бандл - например сервисы для авторизации которые реально можно реюзать, то вам никто не помешает это сделать. В итоге у вас будет структура проекта приблизительно такая:

| - app
| - var
| - src
  | - Controller
  | - Entity
  | - Bundle/
    | - MyAuthBundle/
| - web

ну как-то так. Как не странно такой подход не сильно распространен в Symfony-сообществе хотя его рекомендуют в недавно вышедшем бест практис буке и в принципе эта струтктура более чем логична.

Что до виджетов, в Symfony2 есть HMVC. То есть вы можете сделать эдакие под-запросы на другие контроллеры внутри вьюшек. Можно скажем все "виджеты" инкапсулировать как отдельный контроллер с методами и дергать их из вьюшек.

<div id="sidebar">
    {{ render(controller('AcmeArticleBundle:Article:recentArticles', {
        'max': 3
    })) }}
</div>

Это дает больше гибкости, внутри каждого контроллера можно дергать другие контроллеры. Можно прикрутить кеширование на уровне обработки запросов (кешировать скажем все подзапросы по каким-то критериям) и т.д.

Не уверен, хорошо ли это, ну вот такое решение: jsfiddle.net/5varj2Ly - см. в консоль.

В основе идея из stackoverflow.com/questions/7273668/split-a-long-a...

решение на css с медиа запросами
ссылка на пример внизу

html:

<div class="box">
  <div class="block block_1">block # 1</div>
  <div class="block block_2">block # 2</div>
  <div class="block block_3">block # 3</div>
</div>

css:

.box{
  width: 400px;
  margin: 50px auto;
}

.box:before {
  background-color: rgb(100, 250, 100);
  display: block;
  content: "full";
}

.block {
  width: 33.3333%;
  height: 100px;
  border: 1px dotted black;
  box-sizing: border-box;
  display: inline-block;
}

.block_1 {
  float: none;
}

.block_2 {
  float: left;
}

.block_3{
  float: right;
}

@media (max-width: 600px) {
  .box:before {
    background-color: rgb(150, 150, 250);
    content: "mobile";
  }

  .block_1 {
    width: 100%;
  }

  .block_2 {
    width: 50%;
  }

  .block_3{
    width: 50%;
    float: left;
  }
}

codepen.io/iusfof/pen/Lmiep?editors=110 код в действии

Обычно, разбивают классификацию на подгруппы:
- По типу интерпретации\комиляции языка
- По платформе использования
- По виду хранения записей в базе данных
- По среднему урвоню зарплат
- По среднестатическому-годовому размеру команд на энтерпрайзах

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

Хотя вообще, полезность идеи сомнительна, имхо

Да, просто поменяйте их местами.
img:hover + .hover-info { display: block;}

transform:rotate
ну и соответствующие фильтры для ie
habrahabr.ru/post/107183

Вы не правильно пользуйтесь instanceof , он проверят объект, а вы ему имя класса подсовываете.

is_subclass_of , может проверять по имени классу, по этому он success.

Из выше сказанного, остальные fail т.к:
1. неправильное использование оператора instanceof;
2. для проверки реализации нужного интерфейса, нужно указывать полное имя класса (интерфейса), т.е включая его namespace;