Модуляризация веб-приложений

Question

Мне было интересно, как крупные компании, как правило, модульные компоненты на своей странице. Фейсбук хороший пример:

Есть команда, работающая над поиском, которая имеет свой собственный CSS, Javascript, HTML, и т.д ..

Там команда работает над новостями канал, который имеет свой собственный CSS, JavaScript, HTML и т.д ...

... И этот список можно продолжить

Они не могут все знать, что каждый называет своими тегами div и что-то в этом роде, так что делает контроллер (?), Чтобы подключить все эти компоненты на последней странице ??

Примечание. Это относится не только к Facebook - любая компания, в которой отдельные группы работают над отдельными компонентами, имеет некоторую логику, которая помогает им.

РЕДАКТИРОВАТЬ: Спасибо всем за ответы, к сожалению, я до сих пор не нашел то, что я ищу - когда вы проверяете исходный код (предоставлен его минимизированный), у div есть UID, я думаю что есть процесс компиляции, который проходит через все компоненты и делает их уникальными, переименовывая div и правила css ... какие-нибудь идеи?

РЕДАКТИРОВАТЬ 2: Спасибо всем за то, что поделились своими мыслями - щедрость получила самый высокий голос. Вопрос был разработан, чтобы быть неопределенным - я думаю, что это привело к действительно интересной дискуссии. По мере улучшения процесса сборки я буду делиться своими мыслями и опытом.

Спасибо всем! Мэтт Мюллер

Answer 1

Веб-разработка определенно приносит некоторые организационные проблемы. HTML / CSS не совсем идеальная среда для разделения работы. Очень важно определить определенные правила и строго следовать им.

Моя личная тактика, к которой я пришел, - добавлять имена в общих источниках (например, CSS или компоненты разметки) к какому-либо суффиксу модуля. Если вы будете придерживаться стратегии, она приведет к унификации имен по всему миру.

Например:

вместо

div.question_title
div.question_body

вы можете использовать

div.so_question_title
div.so_question_body

div.su_question_title
div.su_question_body

Также согласитесь с командами в отношении некоторых общих данных, таких как цвета цветовой схемы. Определите их где-нибудь на глобальном уровне и используйте их повсюду.

Другая проблема возникает, когда команды работают над разными частями одной и той же страницы. Здесь, если вы разрабатываете компонент страницы, вы можете обнаружить, что однажды что-то сломалось, потому что парни, работающие над самой страницей, что-то изменили, и изменения распространялись по иерархии элементов.

Например, если вы определяете стиль CSS таким образом:

div.main_news *
{
    /* ... */
}

это будет напрашиваться на неприятности. Я предлагаю вам, как правило, определять стили CSS с минимально возможной областью 1021 *, достаточной для работы некоторой техники.

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

div.news_container
{
    /* Reset styles */
}

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

ОБНОВЛЕНИЕ: относительно div с UID. Если вы имеете в виду Facebook, я не уверен, на какие UID вы ссылаетесь. Только скрытые входы имеют в качестве значений длинные загадочные идентификаторы (главная страница, не вошли в систему), но это, вероятно, результат того, что инфраструктура по какой-то причине автоматически генерирует эти значения. Однажды я написал некоторый код (для ASP.NET MVC) для помощников Html, чтобы генерировать уникальные идентификаторы для всего приложения (я хотел связать флажки с метками по идентификаторам полностью автоматически и прозрачно для меня). Другой случай может состоять в том, что основанная на событиях инфраструктура (например, ASP.NET WebForms) имеет уникальные идентификаторы, сгенерированные на стороне сервера, в качестве требования для поддержки ее работы. Каждый элемент управления должен иметь некоторый уникальный идентификатор, чтобы на стороне сервера можно было узнать, какой элемент вызвал событие на странице. Также некоторые редакторы WYSIWYG добавляли автоматические идентификаторы к элементам при их перетаскивании в форму.

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

Answer 2

Проблемы с конфликтами пространства имен можно избежать, используя соглашение об именах. Дополнительное чтение:

• Практика CSS: псевдо-пространства имен в сложных проектах
• Поддержка пространств имен CSS - функциональные и проектные спецификации

Вкратце: это зависит от того, как построена ваша система, но при условии, что все состоит из модулей, затем назовите ваши идентификаторы CSS (или идентификаторы JS и т. Д.) Следующим образом: SiteName-ModuleName-Function .

Если вы хотите использовать язык вашего приложения (например, PHP) для взаимодействия с кодом CSS / JS, тогда можно использовать «произвольное» наименование, назначив каждому модулю его динамически генерируемый числовой идентификатор и прикрепив этот идентификатор. идентификатору клиентского языкового объекта. Например:

# PHP script
class module_articles {
    public function __construct() {
        $this->GUI = new view;
    }
    public function display_articles() {
        // The CSS file is rendered first by the PHP engine and
        // the identifiers name is constructed with the $this->GUI->id property.
        $this->GUI->load_css('path/to/file.css');
    }
}

class view {
    private static $instance_number = 0;
    public $id;

    public function __construct() {
        $this->id = ++ self :: $instance_number;
    }
    public function load_css($path) {
        // $id can also be the CSS file path (slashes replaced with underscore)
        // or the module name itself (e.g. module_articles)
        $id = $this->id;
        include $path;
    }
}

В конце концов, CSS-файл должен выглядеть примерно так:

/* CSS of module_articles */

<?php echo $id ?>author_name { /*...*/ }
<?php echo $id ?>article_date { /*...*/ }

Примечание. Файл должен быть включен через ключевое слово PHP include ! Используйте Выходной буфер , чтобы вывести его позже.

Answer 3

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

Не пытайтесь решить проблему на «уровне стандартов» или на уровне «как» ... решить ее на человеческом уровне, на уровне управления.

Мы используем несколько методов для поддержания согласованности на уровне управления:

• Поддержите инструменты для разработчика, чтобы сообщить остальным. Это включает вики, внутренние дискуссионные форумы и т. Д.
• Иметь достаточно среднего звена. Никто не может знать обо всем, но для человека имеет смысл знать обо всем, что находится на его уровне. Таким образом, группа управления пользователями может синхронизироваться с группой безопасности, а группа безопасности может синхронизироваться с группой управления контентом. Миссия этого среднего звена состоит в том, чтобы знать достаточно обо всем, не нужно знать каждую деталь, просто достаточно, чтобы передать знания там, где они должны быть.
• Добавляйте уровни по своему усмотрению, но на каждом уровне должен быть один человек, ищущий, все делают более или менее одинаковые вещи. Он будет отвечать за сигнализацию, если две группы делают вещи совершенно по-разному.
• Поддерживать хороший информационный поток. Наличие стандартов очень важно, но позволить людям на самом деле ЗНАТЬ, что они выходят, еще лучше, и гарантировать, что они их используют, с помощью пересмотра кода и еженедельных собраний, если вы хотите продолжать делать все правильно.

Я знаю, что многие люди не любят "менеджмент". Они думают, что это дополнительный слой, который ничего не делает. Ну, это не правда. Менеджмент помогает решать проблемы именно так. Помогите общаться большими командами и иметь общее представление о том, что происходит ... Есть много "техник", чтобы определить стандарт того, как делать вещи ... все эти техники терпят неудачу, когда нет человека быть уверенным, что люди следуют, знают и следуют этим стандартам.

Answer 4

Некоторые приложения используют сервер портала, который используется в качестве прокси. Он расположен перед всеми этими веб-серверами / серверами приложений. Сервер портала получает данные / каналы HTML этих серверов, а затем добавляет к тегам префикс / суффикс, делающий их уникальными.

Если вы правы, есть компонент, который обрабатывает такие вещи.

Answer 5

Если вы действительно хотите знать, просто откройте firebug и зайдите на сайт Facebook.

30 секунд спустя вы обнаружите, что они редко применяют css к элементам через идентификаторы; и вместо этого используйте много обозначений класса точек.

Как только вы пойдете по этому пути, разделение групп разработчиков на функциональность станет намного проще. У вас может быть одна основная группа, которая отвечает за основную «оболочку» с помощью идентификаторов. Всех остальных вы заставляете использовать точечные классы.

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

Answer 6

Я работал с несколькими одностраничными веб-приложениями, из моего опыта

ваши команды различий должны сесть один раз, чтобы настроить простое соглашение CSS

например

мод-search.css

.mod-search .title { }
.mod-search .text { }

мод-news.css

.mod-news .title { }
.mod-news .text { }

в производственном процессе используйте ваш любимый интерфейс и объединяйте все ресурсы в один

также делает то же самое с js, на самом деле js проще для менеджера, чем css

убедитесь, что каждый модуль обернут в свое собственное закрытие

Я использую YUI в качестве примера

мод-search.js

(function(){
   var node = Y.Node.create('<div/>').addClass('mod-search'); 
   // hook your event to this module node only
   node.delegate('click', handleSearch, 'button.search');
}());

mod-news.js

(function(){
   var node = Y.Node.create('<div/>').addClass('mod-news'); 
   // hook your event to this module node only
   node.delegate('click', handleViewNews, 'a.view-news'); 
}());

all-in-one.js.php

//
// php set content type text/javascript
//
YUI().use('node', 'event', function(Y){
   // php include mod-new.js
   // php include mod-search.js
}); 

HTML

<html>
    <head>
        <link href='all-in-one.css.php' rel='stylesheet' />
    </head>
    <body>
        <script src='all-in-one.js.php' ></script>
    </body>
</html>

Answer 7

Можно многое сказать о таких фреймворках CSS, как CSScaffold Шона Инмана . Он позволяет вам подразделять таблицы стилей, определять константы, легко обрабатывать локальные контексты и т. Д. Это не решает вашу проблему, но может оказать большую помощь.

Со стороны Javascript можно работать с локальным контекстом, хотя я редко сталкиваюсь с проблемами.

Именование элементов HTML определенно сложно, но HTML 5 должен помочь (требуется меньшее количество идентификаторов и классов), и прекомпиляция, как вы упоминаете, может быть другим вариантом.

Answer 8

Это не то, что должно происходить на лету, оно запекается в структуре компании. Невозможно рассказать, как это делает Facebook или любой другой конкретный сайт / компания, но это может быть так же просто, как ведение единой таблицы базы данных. Как:

project_namespace

• ID
• имена
• каталог

Итак, у вас есть основное приложение (1, 'core', '/ htdocs / core'). Вероятно, за это отвечает премьер-министр или старший, и некоторые обезьяны создают и поддерживают его - дополнительную таблицу базы данных, если HR еще не управляет этим отношением, но это не имеет значения. Каждое пространство имен будет требовать общей структуры: ./css для файлов CSS, ./templates для шаблонов HTML, ./js, ./images и т. Д. Опять же, для этого может быть таблица БД, но она не имеет отношения к этому примеру. Добавьте любое количество других команд - search (2, 'search', '/ htdocs / search'), учетные записи (3, 'users', '/ htdocs / users'), ребята из веб-служб (4, 'services', '/ htdocs / services /') и так далее. Каждое значение уникально, и я просто придумываю это, поэтому, пожалуйста, не обращайте внимания на отсутствие деталей.

Теперь у вас есть процесс сборки - сценарий или серия сценариев, которые извлекают все из системы контроля версий, запускают минификаторы CSS и JS и, как правило, собирают все разрозненные части в веб-сайт. Он загружает пространства имен из таблицы db и добавляет их (или только уникальные идентификаторы) к каждому соответствующему правилу CSS, идентификатору элемента HTML, классу Javascript или к чему угодно. «Базовое» пространство имен, вероятно, будет иметь некоторые специальные правила, позволяющие другим пространствам имен вызывать его, что-то вроде мета-API (опять же, не так актуально для примера, но реалистично).

По крайней мере, в этом суть, но это не обязательно связано с тем, что я только что упомянул. Для некоторых команд это может быть просто напоминанием по электронной почте: «FTP ваши изменения здесь, но, черт побери, лучше не перезаписывать мои материалы», а для других это связующее правило с тремя кольцами, реализованное с помощью жесткой сборочной линии, подключенное к любому числу средства отслеживания ошибок и инструменты просмотра кода, автоматов, выполняющих модульные тесты и обрабатывающих make-файлы, проверяющих права доступа и так далее и так далее. Я предполагаю, что Facebook больше склоняется к последнему.

Короче говоря: информационная организация и процесс сборки для его обслуживания.

Так что да, каждый может (и должен) знать, что другие называют своими тегами div и функциями JS и всем остальным важным, благодаря этому зловещему объекту, похожему на MCP, поддерживающему правила и раздающему имена. С правильным процессом и инструментами вы никогда не будете не знать.

Answer 9

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

Желательно, чтобы у вас была одна команда для написания / разработки пользовательского интерфейса для всех компонентов, а затем разбить остальные слои по мере необходимости.

Answer 10

Моя компания занимается бизнес-веб-приложениями.

В большинстве случаев мы используем SOA Architectre с интерфейсом ADF или PHP, поэтому не имеет значения, как называются вещи, потому что большая часть HTML-кода визуализируется из компонентов (это уменьшает свободу, которую вы имеете в свободном HTML, но делает это быстрее развиваться).

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

Большим преимуществом является то, что вы можете повторно использовать некоторые веб-сервисы в разных приложениях, не обращаясь к первоначальному разработчику.