Все зависит от того, как вы работаете с CSS - если вам нужно применить небольшие изменения, сначала протестируйте их «вживую» в Firebug / аналогичном инструменте. На этапе разработки (когда у вас еще нет окончательного представления о том, как вы хотите стилизовать свое приложение), вы можете захотеть работать с обычными файлами CSS, но как только общий стиль прояснится, вам следует переключиться на ClientBundle / CssResource.
Почему? Позвольте мне ответить, написав некоторые мысли о целях , перечисленных на документации CssResource страница:
Первичный
- Совместимость с синтаксическими анализаторами CSS, не поддерживающими GWT (т. Е. Любые расширения должны иметь допустимый синтаксис CSS)
Это не означает, что таблица стилей обязательно будет иметь смысл, если вы просто отобразите ее в браузере - это означает, что мы хотим использовать только правильный синтаксис CSS, а не какой-то синтаксический сахар, который напрасен на другие парсеры - может быть не так важно ваша точка зрения (хотя в результате вам не нужно менять синтаксис существующих стилей)
- Проверка синтаксиса - очень важный момент, ИМХО. Вы получаете такие вещи, как проверка на отсутствие (возможно, с ошибками) классов CSS, синтаксические ошибки и т. Д. - что-то, что должно было (как правило, мучительно) отслеживаться с помощью какого-то специального инструмента для браузера (Firebug). Здесь вы получаете эти ошибки рано, во время компиляции (или даже быстрее, с помощью плагина Google Eclipse).
- Минификация - это не обычное минимизация, вы также получаете селектор и свойство слияния. Смотрите также следующий пункт.
- Использование GWT-компилятора - если класс CSS не используется (GWT-компилятор может провести такое различие, поскольку он имеет обзор всего приложения), он сокращается и не включены в скомпилированный код. Сколько раз вы находили классы CSS, которые оставались там после некоторых изменений в дизайне? Это позаботится об этом (см. Также пункт модуляции CSS)
- Разные CSS для разных браузеров, автоматически - поскольку сгенерированный таким образом CSS включен в ваш код JS, он может (и является) оптимизирован для целевого браузера - нет необходимости включать длинные хаки IE в каждую перестановку!
- Статическая оценка содержимого - уже упоминалось ранее
Вторичный
- Базовая модуляризация CSS
- С помощью API-интерфейса внедрения зависимостей - вы можете внедрять CssResources по мере необходимости (например, для облегчения создания пользовательских тем в вашем приложении)
- Виджеты могут внедрять свой собственный CSS только тогда, когда это необходимо - это один из моих любимых моментов, хотя сначала я не видел его значения - вы разделяете свой (обычно) огромный монолитный файл CSS на небольшие модули, по одному для каждого виджета, который использует UiBinder (который, в свою очередь, использует
CssResource внутри), плюс, вероятно, один глобальный CssResource для стилей для всего приложения. Это приводит к гораздо более чистому и легкому в обслуживании стилю CSS (по крайней мере, по моему опыту). Это также означает, что если ваш код не использует этот конкретный виджет (возможно, потому что вы использовали разделение по ocde, и он еще не загружен), вы не будете загружать эти стили.
- BiDi (в стиле Януса?) - поддержка двунаправленного текста, не использовал его, но документы выглядят многообещающе:)
- полосы изображений CSS - автоматические спрайты изображений * поколение 1087 * - что еще я могу сказать? ;)
- "Улучшение CSS"
- Константы - я всегда пропускал эту функцию в спецификации CSS - когда вы меняете свой основной цвет, вы должны найти и заменить его во всем файле (возможно, ведущийк некоторым ошибкам, когда вы хотите использовать старый цвет в некоторых местах) - это делает его более интуитивным, ИМХО, путем введения констант (через допустимый синтаксис CSS и без штрафа за время выполнения)
- Простые выражения - вы должны просмотреть документы, чтобы увидеть возможности, действительно классные вещи
Третичный
- Манипуляции во время выполнения (StyleElement.setEnabled () обрабатывает много случаев) - вклВнедрение таблицы стилей (во время выполнения), некоторые значения оцениваются - это позволяет создавать скины и т. д.
- Проверка имени класса во время компиляции (Java / CSS) - уже упоминалось (очевидное)Преимущества этого
- Запутывание - этот тоже действительно классный, GWT Compiler может смутно запутать все стили в CssResources, потому что он имеет обзор всего приложения - таким образом, столкновения имен невозможны.Это означает, что вы можете использовать длинные (но не слишком длинные;)) значимые имена классов, не беспокоясь о том, как это повлияет на размер приложения - все это будет запутано до изящных, коротких (даже 1-2 символов),случайные строки.Это также позволяет вам определить стиль
.warning в двух виджетах, и компилятор поймет, что эти два стиля находятся в разных пространствах имен (разные виджеты) и, следовательно, должны обрабатываться по-разному (то есть скрываться под разными именами).
О внедрении стилей
Класс StyleInjector позволяет внедрять стили во время выполнения.Кроме того, CssResource позволяет (по крайней мере, в соответствии с документами, я еще не пробовал) для замены во время выполнения.Например, когда вы вводите CssResource, содержащий следующее:
@eval userBackground com.module.UserPreferences.getUserBackground();
div {
background: userBackground;
}
userBackground будет оцениваться и вводиться (в отличие от констант , которые разрешаются во время выполнения).