Показаны сообщения с ярлыком CSS. Показать все сообщения
Показаны сообщения с ярлыком CSS. Показать все сообщения

суббота, 29 сентября 2012 г.

Codeigniter Bootstrap Pagination

Twitter Bootstrap стал безумно популярным фронт-энд фреймворком. Всё чаще и чаще слышу от клиентов, хочу «бутстрэп» (хотя они до конца сами не понимают что это), это больше дань моде, ну это такое. В этой статье хочу рассказать, как адаптировать стандартый pagination класс CodeIgniter-а под новомодный Bootstrap style.

Я находил много решений, вплоть до кастомного MY_Pagination класса для стилизации Bootstrap под CI, каждый ухитряется, как может. Но, я полагаю, это не лучший выход. Вы лишаетесь гибкости, перекрывая нативный класс пагинации кодигнайтера, если выходит новая версия CodeIgniter обновился класс Pagination, то прийдётся заново его адаптировать и искать что изменилось.

Гораздо более удобный способ, это через конфигурацию самого Pagination навесить все необходимые стили и изменить только «обвёртку» для стандартных элементов интерфейса. Сделать это легко. Создаём в папке application/config/ файл с именем pagination.php. В этот файл дописываем следующий конфиг для Pagination Class:

/* twitter bootstrap overrides */
$config['full_tag_open'] = '<div class="pagination pagination-centered"><ul>';
$config['full_tag_close'] = '</ul></div><!--/pagination-->';

$config['first_link'] = '&laquo; First';
$config['first_tag_open'] = '<li class="prev page">';
$config['first_tag_close'] = '</li>';

$config['last_link'] = 'Last &raquo;';
$config['last_tag_open'] = '<li class="next page">';
$config['last_tag_close'] = '</li>';

$config['next_link'] = 'Next &rarr;';
$config['next_tag_open'] = '<li class="next page">';
$config['next_tag_close'] = '</li>';

$config['prev_link'] = '&larr; Previous';
$config['prev_tag_open'] = '<li class="prev page">';
$config['prev_tag_close'] = '</li>';

$config['cur_tag_open'] = '<li class="active"><a href="">';
$config['cur_tag_close'] = '</a></li>';

$config['num_tag_open'] = '<li class="page">';
$config['num_tag_close'] = '</li>';
/* END twitter bootstrap overrides */

Ну и финальный штрих, это подгрузить наш конфигурационный файл в место, где происходит инициализация pagination в самом контроллере, например:

…
$this->config->load('pagination', TRUE);
$config = array_merge($this->config->item('pagination'), Array(
  'base_url'   => site_url('items/'),
  'total_rows'  => $total,
  'per_page'   => 10,
  'uri_segment'  => 2
  ));
$this->load->library('pagination');
$this->pagination->initialize($config);
…

Всё, теперь в любом месте, где вы будете рендерить элементы для постраничной навигации, будет выводиться Codeigniter Bootstrap Pagination. Приведеный выше пример гарантированно рабочий и отлаженный, работает на версии CodeIgniter Framework 2.1.2 и Twitter Bootstrap Version 2.1.1.

четверг, 11 марта 2010 г.

Вёрстка, "overflow:hidden" для ячейки таблицы

Появилась задача сверстать таблицу так, чтобы столбцы и ячейки table не разъезжались, не тянулись, при изменении количества содержимого внутри ячейки. Оказалось, не всё так просто. Повесив свойство overflow:hidden для ячейки таблицы - не будет работать. Как растягивал таблицу контент внутри ячеек, так и будет тянуть.

Нашёл, что к тегу <table> или к элементу, у которого свойство display установлено как table или inline-table можно применять свойство:

table-layout: auto | fixed

Применив для таблицы table-layout:fixed задача решилась сама собой, таблицу не растягивает, но и скролл не появляется.

Дело в том, что значение fixed ещё при этом и повышает производительность построения таблиц. Ширина колонок в этом случае определяется либо с помощью тега <col>, либо вычисляется на основе первой строки. Если данные о форматировании первой строки таблицы по каким-либо причинам получить невозможно, в этом случае таблица будет делиться на колонки равной ширины. При использовании этого параметра содержимое, которое не помещается в ячейку указанной ширины, будет «обрезано» либо наложено поверх ячейки.

Работает под браузерами: IE6+, IE7+, Firefox 2+, Firefox 3+, Opera 9.52+, Safari 3.1+, Chrome 0.3+.

вторник, 18 августа 2009 г.

Эмулирование border-color:transparent в IE6

Все браузеры, как браузеры, нормально работают со свойством border-color:transparent, один Internet Explorer 6 его не понимает. Приведу кусочек кода для примера:

.mydiv
{
width: 400px;
height: 200px;
border: solid 2px transparent;
}

Браузеры Internet Explorer 7, Firefox, Opera and Safari на границах элемента отобразят пустое прозрачное место шириной в 2px. Вместо прозрачного бордера в IE 6 появится чёрная сплошная полоса.

Исправить это можно, сделав небольшой хак, который поймёт только IE6:

*html .mydiv
{
border-color: pink;
filter: chroma(color=pink);
}

И вуаля! Убогий бордер исчез и стал прозрачным.

четверг, 27 ноября 2008 г.

5 аргументов не использовать inline CSS и JavaScript код

Если вы попали на мой блог, значит, вас интересует веб-программирование. Основой веб-программирования, понятное дело, является HTML, но никакой современный сайт уже не обходится без CSS и JS. В интернете можно встретить много разговоров о стандартах в web-программировании, в каком стиле лучше писать код. Ну а толку с них, - скажете вы, - если есть W3C, который занимается стандартизацией и там всё можно почитать. Конечно, можно, но там тонны информации, которую сложно переварить и надо затратить много времени на её изучение.

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

Итак, что же такое inline JavaScript и CSS, - это когда внутри html страницы идут вперемешку скрипты и описания стилей через строчку с html разметкой. Под JavaScript-ом вперемешку я понимаю не вызовы функций по событиям on_click, а непосредственно объявление этих самых вызываемых функций или объявление переменных между тегами <> < /script>, разбросанное по всей странице. Какая разница? – спросит большинство. А разница всё-таки есть, и я приведу вам 5 аргументов не использовать inline CSS и JavaScript код.


Аргумент 1: Кэширование и большинство оптимизаций не работают.
Большинство браузеров для убыстрения работы и уменьшения перегоняемого трафика используют в своей работе кэширование страниц. HTML страницы никогда не кэшируются. Что же касается графических изображений, внешних каскадных таблиц стилей (CSS) и файлов JS скриптов – то браузер пользователя наоборот, старается сохранить файлы в кэше при первом визите и при последующих запросах этих файлов не загружать их заново. Таким образом, объёмы загружаемой информации резко уменьшаются, перегружается только HTML-код страницы, а всё остальное подгружается из локального кэша браузера.

Аргумент 2: Непонятность кода и сложность нейтрализации ошибок
Допустим, у вас по большой HTML странице разбросаны JavaScript вставки. При наступлении какого-то события с неявно указанным обработчиком вам будет сложно выудить необходимый участок кода и нейтрализовать программные ошибки. А если страница компонуется из нескольких вставок, то обработчик и вовсе не будет отрабатывать, по той простой причине, что этот участок кода был случайно не включён.

Аргумент 3: HTML код становится тяжелее.
На выходе ваш HTML код получится значительно тяжелее и больше по объёму. HTML страница пронизанная JS и CSS вставками будет весить в килобайтах гораздо больше, чем аналогичная страница «чистая» по своей структуре.

Аргумент 4: Сложность модификации.
Лучше код взаимодействия вынести в одно централизованное место, чем просматривать весь текст в поисках однотипных участков кода для изменения, разбросанных по всем страницам сайта. Не каждый программист выдержит поддержку такого кода, разбросанного по всему сайту.

Аргумент 5: Невозможность повторного использования кода.
Если вы реализовали отличный по функционалу элемент интерфейса, то вы наверняка захотите его повторно использовать в остальных своих проектах. Но он намертво «вшит» по всем страницам сайта, и вам придется потратить уйму времени на его выуживание и прикручивание к другому сайту. При реализации, разнесенной по отдельным внешним файлам, всё, на что бы вам пришлось потратить время – это сделать подгрузку этих файлов, и вставить в необходимые места вызовы методов.

Надеюсь, мои 5 аргументов не использовать inline CSS и JavaScript код вас хоть немного убедили, и вы возьмёте их на заметку. Успешного кода, программист, и держи реализацию CSS и JavaScript в отдельных внешних файлах.

Рекоммендую

Попробуйте надёжный хостинг от Scala Hosting