Мне не нужно загружать файлы с классами, все файлы уже подключены в нужных местах. Мне нужно создать новый класс внутри неймспейса, но сделать так, чтобы он принадлежал глобальному неймспейсу.
Добавил через before белую полосу у контейнера с top:0, bottom: calc(100% - $padding), z-index: 1. Т.е. на высоту отступа внутри контейнера. Всё получилось! Большое спасибо за наводку!
Александр, тогда контейнер схлопнется в ноль по высоте. Задавать явно высоту контейнеру нельзя (в вашем примере 100px) - высота контейнера должна зависеть от высоты содержимого.
Александр, да, идея не плохая, но в таком случае before перекрывает контент таба, нужно точно также, только чтобы в табы можно было добавлять контент и он отображался))
Никита Егоров, нет, во-первых ненужный border в 1px серого цвета, во-вторых тень на лепестке не корректно падает (не сочетается с тенью у контента), в третьих есть эффект, который я описываю и показал на скриншоте в соседнем комментарии (под лепестком справа от белого оверлея - не белый цвет (часть боковой тени) )
Конечно же нет, обратите внимание во-первых тени разные у лепестка и контента (по краю тень идёт не ровно), во-вторых из-за того, что нижний блок с белым цветом под лепестком шириной равен лепестку - он обрезает тень и это очень заметно, если вы сделаете именно большую тень (читайте внимательно вопрос, какая должна быть тень). Если бы всё было так очевидно - вопрос не был бы задан.
Картинка не задаётся фоном, она задаётся в теге IMG. Если height=autо, то это ситуация с ratio=original. Одно и то же изображение должно иметь возможность отображаться с различным ratio в не зависимости от его оригинальных размеров.
Дмитрий Полянский, насколько я знаю, null-это когда берут тему/плагин и делают байпас лицензии. Вредоносный код может скорее быть, если вы что-то премиум (это может быть оригинал, не нулл) скачали нахаляву и ожидаете, что там не будет вредоносного кода.
Проблема скорее в настройках сервера (NGINX) и в ресурсах.
На картинке у вас с фасадом - фасад обращается к классам субсистемы, а я говорю, что мне нужно из класса сабсистемы обращаться к ДРУГОМУ классу через главный класс.
Например, есть классы Application, Framework, Framework_Feature1, Framework_Feature2.
Application - класс приложения, управляет жизненным циклом Framework.
Если мне нужно из Application обратиться к методу foo() класса Framework_Feture1, то я "пробрасываю" этот метод в класс Framework и обращаюсь как Framework->foo(); В данном случае класс Framework является фасадом по отношению к Application.
Мне было нужно совершенно другое. Мне нужно из класса Framework_Feature1 обратиться к методу класса Framework_Feature2 (например boo()). Если я обращусь как Framework_Feature2->boo(), то класс Framework_Feature1 будет зависеть от класса Framework_Feature2. (И таких зависимостей будет куча среди всех подклассов фреймворка). Поэтому, я создаю в классе Framework экземпляры классов Framework_Feature1 и Framework_Feature2 и уже внутри класса Framework_Feature1 обращаюсь к методу boo() не как Framework_Feature2->boo(), а как Framework->feature2->boo(). Фреймворк по отношению к классам Framework_Feature1 и Framework_Feature2 - не фасад (!), эти классы "знают" про устройство фреймворка, а фреймворк знает про эти классы. Это посредник (медиатор).
Я просил КОНКРЕТНЫЙ пример реализации, а не кучу ссылок на стандарты, в которых Я НЕ НАШЁЛ примера реализации, который я описал выше!
Кирилл Несмеянов, фасад - это когда снаружи кто-то обращается к методу фреймворка (не зная ничего о его внутреннем устройстве). В данном случае это не фасад. Классы, которые обращаются к главному классу - это тоже часть фреймворка и они "знают" о свойствах фреймворка в которых нужно вызывать методы. Это называется медиатор (посредник). Получается, что главный класс одновременно является фасадом (для того, чтобы предоставлять API для использования фреймворка) и медиатором (для того, чтобы подружить все классы друг с другом без тесной связи - методы фреймворка всегда можно переписать).
По вашей ссылке вообще никаких примеров нет, три строчки элементарного кода, который вообще никак с архитектурой не связан. Второй уже ответ от вас бесполезный. Ещё раз повторюсь - вопрос был именно в реализации. То что вы пишите что реализаций может 100500 - это бред. В данном конкретном случае правильная реализация только одна и я её описал.
Александр, before для градиентной обводки, after для заливки фона. Градиенты не поддерживают транзиент в CSS, поэтому чтобы сделать появление фона (например, при ховере) плавным, нужно управлять opacity. - Это первая причина. Вторая причина - уровни переопределения кнопки, чтобы можно было выбрать подходящий дизайн.
Андрей, у меня есть книги автора и я всё это читал, проблема в реализации. Как это должно работать я понимаю, я не понимаю как это реализовать конкретно на PHP.
Головной класс должен быть одновременно и фасадом и медиатором (посредником).
