Модульное исполнение веб-приложений
Я задавался вопросом, как крупные компании склонны строить компоненты из модулей на своей странице. Facebook является хорошим примером:
Существует работа в команде на Поиске, который имеет его собственный CSS, JavaScript, HTML, и т.д.
Существует работа в команде на ленте новостей, которая имеет ее собственный CSS, JavaScript, HTML, и т.д...
... И список продолжается
Они не могут все знать о том, что все называют их тегами Div и этажеркой, поэтому что контроллер (?) делает для сцепления всех этих компонентов в на заключительной странице??
Примечание: Это только относится к Facebook - любая компания, которая имеет отдельные команды, работающие над отдельными компонентами, имеет некоторую логику, которая выручает их.
Править: Спасибо все для ответов, к сожалению, я все еще действительно не нашел то, что я ищу - когда Вы проверяете исходный код (предоставил ее уменьшенный), у отделений есть UIDs, мое предположение - то, что существует процесс компиляции, который пробегает и делает каждый из компонентов уникальными, переименовывающими отделениями и правилами CSS.. какие-либо идеи?
РЕДАКТИРОВАНИЕ 2: Благодарен за то, что все вносят Ваши мысли - щедрость перешла к самому высокому ответу upvoted. Вопрос был разработан, чтобы быть неопределенным - я думаю, что он привел к действительно интересному обсуждению. Поскольку я улучшаю свой процесс сборки, я внесу свои собственные мысли и события.
Спасибо все! Matt Mueller
10 ответов
Веб-разработка определенно приносит некоторые организационные проблемы. 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 стили с минимально возможным диапазоном, которого достаточно для работы какой-либо техники.
Один из возможных обходных путей: каждый подмодуль сначала сбрасывает все стили для своего элемента верхнего уровня иерархии, например:
div.news_container
{
/* Reset styles */
}
так что теперь вы можете работать над модулем, будучи уверенным, что изменения в некоторых родительских элементах будут остановлены на вашем периметре.
UPDATE: Что касается div'ов с UID'ами. Если вы имеете в виду Facebook, то я не уверен, какие UID вы имеете в виду. Только скрытые входы имеют некоторые длинные загадочные идентификаторы в качестве своих значений (главная страница, не вошедший в систему), но это, скорее всего, результат того, что фреймворк автоматически генерирует эти значения по какой-то причине. Однажды я написал код (для ASP.NET MVC) для Html-помощников для генерации уникальных ID в масштабах всего приложения (я хотел привязать чекбоксы с метками по ID полностью автоматически и прозрачно для меня). Другим случаем может быть фреймворк, управляемый событиями (например, ASP.NET WebForms), генерирующий уникальные идентификаторы на стороне сервера в качестве требования для поддержки его работы. Каждый элемент управления должен иметь какой-то уникальный ID, чтобы на стороне сервера можно было узнать, какой элемент вызвал событие на странице. Также некоторые WYSIWYG-редакторы добавляют автоматические ID к элементам, когда вы перетаскиваете их на форму.
Не говоря уже об этом, можно, конечно, использовать какой-нибудь предварительно созданный скрипт, который будет просматривать код и вводить уникальные идентификаторы в разметку и части кода CSS. Но вам нужно точно знать, что и зачем вы делаете. Лично я считаю, что "уникализация" в целом может быть достигнута вручную путем внедрения некоторых простых правил в команде, в то время как некоторые работы, конечно, могут быть автоматизированы, как то, что я описал выше.
По моему опыту, как бы хорошо вы ни старались стандартизировать все, для больших команд полная слаженность, когда все делают одно и то же, практически невозможна.
Не пытайтесь решить проблему на уровне «стандартов» или «как сделать» ... решайте ее на уровне человека, на уровне руководства.
Мы используем несколько методов для поддержания согласованности на уровне управления:
- Поддерживаем инструменты, чтобы разработчик информировал остальных. Это включает в себя вики, внутренние дискуссионные форумы и так далее.
- Иметь достаточное количество менеджеров среднего звена. Ни одно тело не может осознавать все, но для человека имеет смысл осознавать все, что находится на его уровне.Таким образом, группа управления пользователями может синхронизироваться с группой безопасности, а группа безопасности может быть синхронизирована с группой управления контентом. Миссия этого среднего менеджмента - знать достаточно обо всем, не нужно знать каждую деталь, достаточно, чтобы передать ему знания, где они должны быть.
- Добавляйте уровни по своему усмотрению, но на каждом уровне должен быть один человек, ищущий, все делают более или менее одни и те же вещи. Он будет отвечать за то, чтобы поднять тревогу, если две группы будут действовать совершенно по-разному.
- Поддерживайте хороший информационный поток. Наличие стандартов важно, но еще лучше позволять людям ЗНАТЬ, что они выходят, и обеспечение их использования посредством пересмотра кода и еженедельных встреч совершенно необходимо, если вы хотите продолжать делать вещи правильно.
Я знаю, что многим не нравится "менеджмент". Они думают, что это дополнительный слой, который ничего не делает. Что ж, это неправда. Именно управление помогает решать подобные проблемы. Помогите общаться в больших командах и иметь общее представление о том, что происходит ... существует множество «техник» для определения стандарта того, как что-то делать ... все эти методы терпят неудачу, когда нет человека следить за тем, чтобы люди следовали этим стандартам.
Можно многое сказать о CSS-фреймворках, таких как CSScaffold Шона Инмана. Он позволяет вам разделять таблицы стилей, определять константы, легко обрабатывать локальные контексты и т. Д. Это не решает вашу проблему, но может оказаться большим подспорьем.
Что касается Javascript, то возможно работать с локальными контекстами, хотя я редко, если вообще когда-либо, сталкивался с проблемами.
Именование элементов HTML определенно сложно, но HTML 5 должен помочь (требуется меньше идентификаторов и классов), и предварительная компиляция, как вы упомянули, может быть другим вариантом.
Я работал с несколькими проектами одностраничных веб-приложений, по моему опыту
вашим командам разработчиков следует сесть один раз, чтобы настроить простое соглашение css
например
mod-search.css
.mod-search .title { }
.mod-search .text { }
mod-news.css
.mod-news .title { }
.mod-news .text { }
в производстве используйте ваш любимый интерфейс, объединяйте все ресурсы в один
также делайте то же самое с js, на самом деле js проще управлять, чем css
убедитесь, что каждый модуль заключен в собственное закрытие
я использую YUI в качестве примера
mod-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>
Моя компания занимается бизнес-веб-приложениями.
В большинстве случаев мы используем SOA Architectre с ADF или интерфейсом PHP, поэтому не имеет значения, как называются объекты, потому что большая часть HTML визуализируется из компонентов (это уменьшает свободу, которую вы имеете в бесплатном HTML, но быстрее развиваться).
Также наши команды не организованы по темам, они относятся к различным техническим областям, таким как база данных, графический интерфейс или производительность.
Большим преимуществом является то, что вы можете повторно использовать некоторые веб-службы в различных приложениях, без необходимости связываться с исходным разработчиком.
Проблему конфликтов пространств имен можно избежать, используя соглашение об именах. Дополнительное чтение:
- Практика 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 ключевое слово! Используйте Буферизацию вывода , чтобы вывести его позже.
Если вы действительно хотите знать, просто откройте firebug и исследуйте сайт facebook.
Через 30 секунд вы обнаружите, что они редко применяют css к div через идентификаторы; и вместо этого используйте много обозначений классов точек.
Если вы пойдете по этому пути, разделение групп разработчиков на функциональные возможности станет намного проще. У вас может быть одна основная группа, которая отвечает за основную «оболочку» с использованием идентификаторов. Всех остальных вы заставляете использовать точечные классы.
Вы можете дополнительно ограничить это, присвоив каждой группе префикс для работы.
Соглашения пользовательского интерфейса должны быть задокументированы, когда несколько команд разрабатывают пользовательский интерфейс.
Желательно, чтобы одна и та же команда писала / разрабатывала пользовательский интерфейс для всех компонентов, а затем разбивала другие уровни по мере необходимости.
Это не то, что должно происходить на лету, это заложено в структуру компании. Неизвестно, как это делает Facebook или любой другой конкретный сайт/компания, но это может быть так же просто, как ведение одной таблицы базы данных. Например:
project_namespace
- id
- namespace
- directory
Итак, у вас есть основное приложение (1, 'core', '/htdocs/core'). Вероятно, есть руководитель или старший, отвечающий за него, и несколько обезьян для его создания и поддержки - дополнительная таблица базы данных, если HR еще не управляет этими отношениями, но это не имеет отношения к делу. Каждое пространство имен требует общей структуры, ./css для CSS файлов, ./templates для HTML шаблонов, ./js, ./images, и так далее. Опять же, для этого может существовать таблица db, но для данного примера это не имеет значения. Добавьте любое количество других команд - поиск (2, 'search', '/htdocs/search'), учетные записи (3, 'users', '/htdocs/users'), веб-сервисы (4, 'services', '/htdocs/services/') и так далее. Каждое значение уникально, и я просто придумываю это, так что, пожалуйста, не обращайте внимания на отсутствие деталей.
Теперь у вас есть процесс сборки - сценарий или серия сценариев, которые извлекают все из контроля исходных текстов, запускают минификаторы CSS и JS и вообще компилируют все разрозненные части в веб-сайт. Он загружает пространства имен из таблицы базы данных и добавляет их (или только уникальные идентификаторы) к каждому соответствующему правилу CSS, идентификатору элемента HTML, классу Javascript или чему-либо еще. "Основное" пространство имен, вероятно, будет иметь некоторые специальные правила, позволяющие другим пространствам имен обращаться к нему, своего рода мета-API (опять же, не столь актуально для примера, но реалистично).
Такова, по крайней мере, суть, но она не обязательно включает в себя все, что я только что упомянул. Для одних команд это может быть просто напоминание по электронной почте: "Присылайте свои изменения по FTP сюда, но, придурок, лучше не перезаписывайте мой материал", а для других - это папка с тремя кольцами правил, реализованная на жестком конвейере, подключенная к любому количеству баг-трекеров и инструментов проверки кода, автоматов, выполняющих модульные тесты, обрабатывающих make-файлы, проверяющих разрешения и так далее, и тому подобное. Я бы предположил, что Facebook больше склоняется к последнему варианту.
Короче говоря: организация информации и процесс сборки для ее поддержания.
Так что да, каждый может (и должен) знать, как другие называют свои теги div, функции JS и все остальное важное, благодаря этой зловещей структуре, похожей на MCP, которая поддерживает правила и раздает имена. С правильным процессом и инструментами вы никогда не узнаете.
Некоторые приложения используют сервер портала, который используется в качестве прокси. Он находится перед всеми этими веб-серверами / серверами приложений. Сервер портала получает данные / каналы HTML этих серверов, а затем добавляет префикс / суффикс к тегам, делая их уникальными.
В некотором смысле вы правы, есть компонент, который занимается такими вещами.