Приветствую всех!

На днях я экспериментировал с плагином jQuery Panel Gallery и хочу поделиться впечатлениями, а заодно рассказать, как с ним работать. Кроме того, использование подобных плагинов имеет некоторые особенности, которые касаются не их самих, а JavaScript анимации вообще.

Итак, начнем с плагина.

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

Как это выглядит можно посмотреть на демонстрационной страничке.

И, конечно, вы можете скачать архив с примером.

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

Выглядит это примерно так

Правда есть несколько нюансов, о которых нужно помнить.

1) Картинки должны находиться внутри блока с позиционированием. Т.е. для этого блока должно быть установлено CSS правило position:relative или position:absolute или position:fixed.

2) Вы можете использовать картинки разного размера, но атрибуты width и height должны быть одинаковыми, т.е. браузер подгонит их под заданный размер. На мой взгляд лучше заранее подготовить картинки одинакового размера.

3) Нормально работать плагин начнет только после того, как все картинки будут загружены, поэтому если вы решите сделать слайдшоу из сотни-другой картинок, то посетителю придется немного подождать

4) Плагин имеет довольно много настроек, с помощью которых можно контролировать анимацию. Их перечень в конце этой статьи.

Теперь самое главное – анимация, а точнее нагрузка на систему.

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

Но если этот код будет работать постоянно (как в случае этого плагина), то нагрузка резко возрастает.

Этот плагин не исключение. Во время смены картинок нагрузка на процессор достигает 20-30%.

Причем она может быть и больше. Уменьшите задержки между запуском анимации, увеличьте количество сегментов, поднимите скорость и, думаю, вы легко возьмете планку в 40-50%

В общем, глядя на эти цифры, возникает острое желание поискать какое-нибудь решение на Flash или Silverlight

А вы как думаете?

P.S. Настройки плагина.

sections – количество блоков, на которые разбивается изображение (по-умолчанию 3).

imageTransitionDelay – пауза (в мс) перед началом показа следующего изображения (по-умолчанию 3000).

startDelay – пауза перед запуском первой анимации (по-умолчанию 2000).

sectionTransitionDelay – задержка между показами секций изображения (по-умолчанию 700мс).

overlap – позволяет начать анимацию следующей секции до того как закончится анимация предыдущей. Задается как доля от значения параметра sectionTransitionDelay (изменяется от 0 до 1). Например, если sectionTransitionDelay:1000, а overlap:0.5, то следующая секция начнет появляться через 500мс после предыдущей.

enablePause – если равен 1, то анимация будет остановлена при наведении курсора на картинку.

repeat – если равен true, то картинки будут повторяться по кругу.

direction – направление переходов. “lr” (слева направо), “rl” (справа налево), “tb” (сверху вниз), and “bt” (снизу вверх) (по-умолчанию: “lr”).

Что-то давно я ничего не писал о CSS, а ведь использовать эту технологию приходится практически постоянно.

Кроме того, последнее время я начинаю замечать, что все чаще использую CSS фреймворки. Поэтому сегодня речь пойдет именно о них. А точнее, об одном из них, под названием 960 Grid System.

Почему именно о нем? Тут все очень просто. Я более-менее плотно работал с двумя фреймворками: Blueprint и 960 grid. При этом, на мой взгляд, разработчикам 960 grid system удалось добиться очень хорошего отношения возможности/размер фреймворка.

Рассмотрим его подробнее.

Начнем с недостатков.

Если вы хоть немного интересовались темой, то, конечно, знаете, что есть много возражений против применении CSS фреймворков как таковых.

Основные возражения такие.

1) Фреймворки увеличивают размер страницы.

2) Загоняют разработчика в определенные рамки. Например, 960 grid предназначен для верстки страниц с шириной 960рх.

3) Многим не нравятся имена классов вроде «grid-16».

4) Кто-то считает, что нужно самому создавать фреймворк «под себя».

Но давайте посмотрим насколько существенны эти недостатки.

1) Объем файлов действительно увеличивается. Но 960 Grid System состоит из трех файлов, суммарный размер которых – 8 кБ (сжатая версия). Если использовать архивацию размер уменьшается до 1,6кБ.

Вы, конечно, сможете обойтись меньшим количеством кода для конкретной страницы, но разница вряд ли будет больше 1 кБ, т.е. если на вашей страничке есть хотя бы парочка картинок, выигрыш в общем объеме окажется менее 1%.

2) По поводу ограничений. Фреймворк, как и любую библиотеку, имеет смысл использовать в случаях, для которых он разрабатывался. Т.е. если нужна «резиновая» верстка, 960 Grid – не подходящее решение (хотя есть проект Fluid 960 Grid System). Но если в тех. задании сказано, что страница должна иметь фиксированную ширину 960px, то ситуация меняется.

3) Имена классов. На мой взгляд – это вопрос привычки. Цифры в имени означают ширину блока и по ним достаточно просто ориентироваться. Кроме того, никто не запрещает использовать одновременно несколько классов, например,

Класс grid_4 будет использовать фреймворк, sidebar – вашими стилями.

4) Свой фреймворк – это хорошо… если у вас есть время на его разработку и вы уверены, что он получится лучше существующих решений.

Теперь о преимуществах.

1) Время разработки. Оно сокращается и значительно, особенно если у вас есть минимальный опыт работы с фреймворком и вы используете его в подходящей ситуации. Т.е. нужно потратить какое-то время на изучение, но окупается оно очень быстро.

2) Фреймворки содержат «хаки» для наиболее распространенных браузеров. Каждый раз решать одни и те же проблемы с позиционированием элементов в IE очень быстро надоедает

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

Примечание. Кстати, если вы интересуетесь темой, очень советую почитать статью "Верстка с помощью Grid".

А теперь небольшой пример.

Допустим, нам нужно сверстать страницу с таким размещением блоков.

Я сразу покажу решение.

Как видите, мы обошлись практически минимальным количество тегов div. Вложенные дивы использовались только для левой и центральной колонок, т.к. они содержат несколько блоков.

Теперь о номерах классов.

Общая ширина макета 960px. Фреймворк позволяет разбить ее на 12, 16 и 24 равных части. В данном случае нам достаточно разбиения на 12 частей. Т.е. класс grid_12 имеет ширину 940px плюс отступы по 10px справа и слева.

Точно также класс grid_4 имеет ширину 960 * 4 / 12 = 320px из которых 20px приходится на отступы.

Если мы поместим подряд три блока с классами grid_1, grid_7 и grid_4, то они займут всю ширину страницы.

Кроме того, есть несколько специальных классов, например, alpha и omega. Они позволяют убрать отступы слева (alpha) и справа (omega) у блока. В данном примере эта возможность используется для того, чтобы убрать отступы у вложенных блоков. Иначе они будут прибавлены к отступам контейнера и, например, расстояние между левой колонкой и центральной будет не 20, а 40px.

Также вы можете использовать класс clear для завершения строки с блоками, а также классы prefix_X, suffix_X, push_X и pull_X для создания различных отступов (вместо X нужно подставить число).

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

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

В заключение хочу провести небольшой опрос.

(форма для голосования не видна в RSS ридере, поэтому заходите на сайт )

Удачи!

Я думаю, многие блоггеры пользуются возможностью отложенной публикации постов в WP. Действительно, функция очень удобная, т.к. позволяет публиковать новые материалы через более-менее равномерные промежутки времени. К тому же для ее использования делать практически ничего не нужно, достаточно просто указать в админке WordPress дату публикации.

Но недавно у меня возникла задача публиковать посты через XML-RPC и, сразу же обнаружилось несколько не совсем очевидных нюансов, которые касаются указания даты. О них я и хочу сегодня рассказать.

Для начала немного теории.

WordPress имеет встроенный XML-RPC сервер, который позволяет выполнять практически все операции с постами и страницами (создание/чтение/изменение/удаление).

Примечание. По-умолчанию в целях безопасности поддержка XML-RPC отключена. Вы можете включить ее на странице Settings – Writing – Enable the WordPress, Movable Type, MetaWeblog and Blogger XML-RPC publishing protocols.

Для публикации поста нужно сформировать и отправить XML-RPC запрос со всеми необходимыми данными.

Естественно, формировать его вручную не самое увлекательное занятие. Гораздо удобнее использовать одну из многочисленных библиотек для работы с XML-RPC.

Для этого примера я решил использовать библиотеку под названием IXR_Library, которую, кстати, использует и движок WordPress.

Только WP ее использует для создания XML-RPC сервера, а нам нужен XML-RPC клиент.

Нам потребуется выполнить 3 несложных действия.

1) Создать объект типа IXR_Client (XML-RPC клиент).

2) Создать массив с данными.

3) Опубликовать пост с помощью метода query.

Наибольшие проблемы вызывает второй этап. При формировании массива важно не ошибиться с именами ключей массива и форматом значений, которые в них передаются.

Взгляните на пример кода.

Мы подключили библиотеку, создали объект типа IXR_Client (при этом мы указали адрес блога) и начали заполнять массив с данными ($requestData).

Первым элементом этого массива должен быть id автора. Если вы единственный автор блога, ставьте 0.

Второй и третий элементы – ваши логин и пароль.

Четвертый элемент – массив с данными. Это ассоциативный массив, поэтому последовательность элементов роли не играет. В данном случае мы указали заголовок поста (title), разрешили комментарии (mt_allow_comments) и запретили пинги (mt_allow_pings).

Обратите внимание. Элементам mt_allow_comments и mt_allow_pings нужно присвоить числовые значения, элементу title – текстовое.

Затем мы указали перечень тегов (mt_keywords) и добавили текст поста (description).

Теперь о дате. Передавать нужно объект типа IXR_Date, а в его конструкторе указать дату в формате «ггггммддТчч:мм:сс». Букву «Т» в принципе можно заменить любой другой или пробелом, она просто игнорируется. Но все остальные значения должны быть введены в строгом соответствии с этим форматом, а длина строки должна равняться 17-ти символам.

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

Пятый элемент массива – булево значение, указывает, публиковать пост или нет. Если дата, указанная в элементе dateCreated еще не наступила, то статус поста будет scheduled.

Для отправки поста мы используем метод query. В его первом параметре указываем название функции XML-RPC сервера, которую мы хотим вызвать. В данном случае это metaWeblog.newPost. Во втором – передаем массив с данными.

Примечание. Подробнее о функциях, которые поддерживает XML-RPC сервер WP можно почитать в статье «Публикация постов в WordPress с помощью XML-RPC и CodeIgniter». Но основными источниками информации остаются Codex WP и, конечно, сам файл xmlrpc.php.

Получить id опубликованного поста можно с помощью метода getResponse.

Как видите, ничего принципиально сложного нет. Главное правильно сформировать массив с данными

А вообще XML-RPC интерфейс позволяет делать очень интересные вещи. Например, можно сделать общую панель управления несколькими блогами или систему для получения расширенной статистики (частота публикаций, среднее количество комментариев и т.п.).

Возможности ограничены только вашей фантазией

Все мы любим получать что-то бесплатно И статистика этого блога – совершенно точно подтверждает эту теорию.

Судите сами, самая популярная статья этого блога – «Как самостоятельно и бесплатно зарегистрировать домен» была написана 2 года назад и собрала более 200 комментариев. Причем периодически на неё приходило больше людей, чем на главную.

Но за 2 года появились дополнительные возможности, которые значительно упрощают процедуру регистрации, поэтому я решил написать новую инструкцию.

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

1) В зоне .org.ua существует ограничение – нельзя подавать более 3-х заявок на регистрацию в сутки с одного почтового домена. Обратите внимание, именно почтового домена, а не ящика, т.е. 3 заявки на весь ukr.net. Это конечно не проблема, если у вас уже есть зарегистрированный домен, и вы можете создавать ящики вида admin@mycooldomen.com (такую возможность предоставляют практически все хостеры). В противном случае нужно было искать какой-нибудь экзотический бесплатный почтовый сервис.

2) Теперь сложнее сделать ошибку при составлении заявки. Т.к. часть данных вводится автоматически (например, поле changed).

3) Не нужно следить в каком формате уходит письмо с заявкой. Много ошибок было связано с тем, что письма отправлялись в HTML формате. Правда, письмо с подтверждением регистрации все равно нужно отправлять, поэтому эта проблема решена не полностью.

Теперь подробно разберем порядок создания домена

1) Если вы первый раз регистрируете домен, нужно получить nic-handle. Эта процедура сводится к заполнению формы, поэтому на ней я останавливаться не буду.

2) Внимательно читаем две странички. Особенности регистрации домена org.ua и Правила реєстрації доменних імен в домені ORG.UA. (Если возникли проблемы с украинским языком, обращайтесь, я переведу).

3) Выбираем доменное имя. На этом этапе основной инструмент – whois. Кроме того, будут не лишними сервисы для подбора доменных имен. В блоге SmashingMagazine есть интересная статья на эту тему.

4) Создание записей на name серверах. Я обычно использую name сервера хостера, поэтому пример приведу для cPanel.

4.1) Выбираем в меню пункт Домены – Дополнительные домены.

4.2) Заполняем форму

5) Регистрация. О регистрации с помощью email я уже писал, поэтому сейчас рассмотрим процедуру регистрации через сайт.

5.1) Выбираем пункт «Реєстрація домена»

5.2) Заполняем форму.

Я указал только адрес первичного dns (без IP), вторичный система определила сама.

5.3) После нажатия на кнопку check вы увидите сформированную заявку, такую же, как раньше нужно было отправлять почтой. Проверяем её и отправляем.

5.4) Дальнейшая обработка заявки происходит как обычно, т.е. на ваш email будут приходить письма с результатами.

6) Одно из писем, которые вы получите, будет с темой «ADD sitename.org.ua processing approval request». Вам нужно:

6.1) Скопировать текст письма.

6.2) Удалить из него строку approve: N.

6.3) Ответить на это письмо (в ответ вставить это же письмо без строки approve: N). Убедитесь, что письмо отправляется как обычный текст (не HTML).

7) Завершающий этап. Вы получаете письмо с темой «CREATED: sitename.org.ua (Domain Record #…)», т.е. подтверждение успешной регистрации домена.

8 ) Празднуете успешную регистрацию

Процедура регистрации довольно простая и если вы все внимательно делаете, то проблем быть не должно. Тем не менее, ситуации бывают разные, поэтому советую почитать статью «Как самостоятельно и бесплатно зарегистрировать домен. Типичные ошибки.».
И, конечно, вы всегда можете задать вопрос или поделиться своими впечатлениями в комментариях.

Удачи!

Интересно почитать

заработок в интернете на сайте – деньги нужны всем!

Приветствую всех!

Сегодня я хочу рассказать о небольшой ORM библиотеке под названием RedBean с которой я на днях экспериментировал.

Прежде всего, пару слов о ORM (англ. Object-relational mapping, русск. Объектно-реляционная проекция) вообще.

Основное назначение таких библиотек – преобразование объектов, которые используются в программах, в записи реляционных баз данных и обратно.

Дело в том, что все данные в БД хранятся в таблицах (аналог двумерных массивов), а объекты могут быть организованы в сложные иерархии (например, объект типа «Post» может содержать массив объектов типа «Comment»). И для того, чтобы сохранить такую структуру в БД нужно использовать несколько таблиц с дополнительными полями, которые устанавливают связи между записями.

Все это увеличивает сложность SQL запросов и время разработки.

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

Вернемся к RedBean.

Проиллюстрировать работу любой библиотеки проще всего на примере. Поэтому я написал небольшой скрипт.

Посмотрим, что он делает.

1) Подключаем библиотеку (строка 2). Тут объяснять нечего, RedBean состоит всего из одного файла.

2) Подключаемся к базе данных и создаем объекты, которые будем в ней хранить (строка 5).
Обе операции выполняются с помощью метода kickstartDev. В первом параметре мы указываем перечень нужных объектов (они будут создаваться динамически). В остальных параметрах – данные, необходимые для подключения к базе (dns, имя пользователя и пароль).

Предварительно от нас требуется только создать пустую БД. Созданием таблиц, сохранением и чтением данных будет заниматься RedBean.

Примечание. Метод kickstartDev переводит библиотеку в т.н. fluid режим. При этом если вы измените, количество или названия свойств объектов, то RedBean автоматически изменит структуру таблиц в БД. Этот режим имеет смысл использовать во время разработки. После переноса приложения на «боевой» сервер kickstartDev лучше заменить на kickstartFrozen. Библиотека перейдет во frozen режим, при этом таблицы автоматически изменяться не будут, но и потребление ресурсов сократится.

3) Создаем данные и сохраняем их в БД (строки 7-15).

В данном случае создано два объекта типов Post и Comment, каждый из которых содержит несколько свойств.
Обратите внимание, что свойства создаются автоматически. От нас требуется указать только название свойства и его значение.
Мы просто присваиваем значения нужным свойствам и вызываем метод save(), который записывает объект в БД (строка 10).

Объект Comment принадлежит Post. Эту связь мы устанавливаем с помощью метода belongsTo. При этом использовать save не нужно. Сохранение в БД произойдет автоматически.

4) Читаем данные из базы (строки 29-40).
Тут тоже все достаточно прозрачно. С помощью статического метода listAll мы получаем массив со всеми объектами типа Post, находящимися в БД.

Чтобы получить доступ к комментариям мы создаем объект типа Post (строка 31) и при этом в качестве параметра указываем id.

После этого мы можем использовать метод getRelatedComment для получения массива с комментариями.
Примечание. Название метода getRelatedComment формируется следующим образом. К приставке getRelated добавляется имя объекта, который мы хотим получить.

Затем в цикле мы выводим комментарии.

В результате выполнения скрипта вы увидите такую страницу.

Теперь посмотрим, что у нас делается с базой данных.

Прежде всего, взгляните на перечень таблиц.

Как видите, RedBean создал 6 таблиц. Три из них (post, comment_post и comment) используются для хранения данных приложения, остальные – используются самой RedBean.

Теперь посмотрим, что сохранено в самих таблицах.

post

comment_post

comment

Думаю, вы уже догадались, в чем дело.

Между объектами Post и Comment отношение типа ОДИН-К-МНОГИМ и для его реализации не нужна промежуточная таблица. Т.е. если бы база создавалась вручную, мы бы обошлись всего двумя таблицами. Соответственно, упрощаются и SQL запросы.

Использовать или не использовать?

Это вопрос философский . RedBean не единственная ORM библиотека. Например, существуют более мощные Propel и Doctrine.

Ответ будет зависеть от требований к конкретному приложению. В общем случае при использовании ORM увеличивается скорость разработки и упрощается поддержка, но при этом растет потребление ресурсов.

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

В общем, думаю, что в ряде случаев использование RedBean будет вполне оправданно.

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

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

На днях мы с Serator'ом обсуждали эту тему и речь зашла о новом плагине от Google для Internet Explorer под названием Google Chrome Frame.

Для читателей, которые, как и я , пропустили эту новость, кратко поясню, о чем речь. Этот плагин интегрирует рендерер из движка WebKit в IE.

Т.е. с IE внешне ничего не происходит, но странички он начинает показывать по-другому, также как и Chrome.

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

Для того, чтобы плагин заработал нужно в заголовок страницы добавить тег

<meta http-equiv="X-UA-Compatible" content="chrome=1">

При этом плагин совместим с 6-ой версией IE и более поздними.

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

С одной стороны, установив его, вы сохраняете привычный интерфейс, и это, безусловно, плюс. Но с другой стороны, во-первых, требуется поддержка со стороны разработчиков сайта и, во-вторых, возникает вопрос: «Что проще для пользователя? Перейти на другой браузер? Или обновить IE до 8-ой версии? Или этот плагин установить?».

В общем, нам с Serator'ом очень интересно узнать ваше мнение.

Итак, вопрос.

Примечание. Форма опроса в RSS ридерах не работает, поэтому чтобы проголосовать вам нужно перейти на сайт.

Все дополнения, пожелания, замечания оставляйте в комментариях, обсудим

Приветствую всех!

Сегодня я хочу обсудить два способа передачи параметров в JavaScript файлы.

Прежде всего, объясню, в чем заключается проблема. Обычно в конфигурационных файлах серверных (PHP) скриптов хранится множество настроек. И к некоторым из них нужно получить доступ из JavaScript. Если все эти параметры собраны в одном месте (конфигурационном файле или БД), то значительно упростится поддержку приложения.

Существует два широко распространенных решения этой задачи.

1) Генерация JS кода с помощью серверного скрипта.

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

Поясню сказанное на примере.

Допустим у нас есть страница (index.php) и js файл (my-scripts.js). Нам нужно передать несколько параметров из массива $config.

Страница будет выглядеть так.

Как видите, мы создали глобальный хеш ($.config) и установили для его элемента par1 значение из массива $config.

Примечание. Для работы этого примера нужно подключить библиотеку jQuery.

Теперь хеш $.config можно использовать в my-script.js. Например, так

Примечание. Если вам нужно передавать сложные структуры с параметрами, то будет удобнее использовать JSON формат.

2) Передача параметров в атрибуте src скрипта.

Этот способ используется загрузчиком библиотеки Script.aculo.us.

Идея следующая.

1) Необходимые параметры добавляются прямо к адресу скрипта. Напрмер, так

src="my-script.js?par1=myValue&par2=value2

Т.е. мы формируем GET запрос. Но естественно статичный JS файл его обработать не может.

2) Чтобы получить доступ к этим параметрам, мы добавляем в JS файл код, который:

2.1) находит соответствующий тег script;

2.2) читает его атрибут src;

2.3) получает строку с параметрами, например, с помощью такого регулярного выражения
/my-script\.js(\?.*)?$/

2.4) разбирает строку с параметрами (это можно сделать с помощью функции split).

Приводить пример для этого способа я не буду, т.к., во-первых, его можно посмотреть в исходниках script.aculo.us (файл scriptaculous.js, строки 48-56), а во-вторых, на мой взгляд, он обладает несколькими серьезными недостатками.

1) Вы не сможете передать большой объем данных таким способом, т.к. существуют ограничения на длину URL.

2) Значительно усложняется код как серверной, так и клиентской частей приложения. Сервер должен преобразовать массив с данными в строку, а браузер выполняет обратную операцию.

В общем, я понимаю, почему этот способ использовали разработчики script.aculo.us. Они передают только названия компонентов библиотеки, которые нужно подключить. И для пользователя такая запись перечня компонентов выглядит проще, чем вставка отдельного тега script. Но для передачи более сложных параметров этот метод подходит плохо.

На этом известные мене способы передачи параметров заканчиваются

Если у вас возникли идеи, пишите, буду рад обсудить!

Приветствую всех читателей!

На днях я закончил работу над второй версией ToDo скрипта и теперь хочу о нёй рассказать И, самое главное, почитать ваши отзывы.

Т.к. после релиза первой версии прошло уже больше месяца, я кратко напомню, о чем идет речь.

Думаю, представить себе простейший ToDo список могут все. Это просто перечень дел с отметками «выполнено / не выполнено».

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

Для этого скрипта я использовал одну из таких систем обозначений. Её разработал Sigurdur Armannsson. Подробно её описание вы найдете в предыдущей статье.

Сейчас речь пойдет именно об изменениях по сравнению с предыдущей версией.

Сразу дам ссылки на страницу с демо версией и архив.

Для входа можно использовать demo аккаунт (логин: admin@todo.loc, пароль: password) или создать нового пользователя (ссылка «Регистрация» под. формой входа). Только учтите, что приложение позволяет изменять пароль, и если кто-то успеет изменить его до вас, то вам останется только регистрация.

1) Изменилось название . Теперь скрипт называется Circle Tasks. Это название ближе к названию оригинала.

2) Изменился дизайн. Тут изменения не очень большие. Подобраны более подходящие иконки для операций «Изменить» и «Удалить», перерисованы иконки состояний задач. Изменена цветовая гамма (надеюсь в лучшую сторону ).

3) Интерфейс. Вот здесь изменений больше всего.

Во-первых, я учел отличные рекомендации Steward и убрал inline редакторы. Сначала мне казалось, что они будут ускорять работу, но оказалось что это не так. Теперь чтобы изменить задачу нужно кликнуть по кнопке «Изменить», откроется форма, содержащая все необходимые поля.

Во-вторых, в меню добавлен пункт «Настройки». Он ведет на страницу, которая позволяет изменить язык приложения и пароль.

Предпочитаемый язык сохраняется отдельно для каждого пользователя в базе данных. Если точно определить язык не возможно (например, вы не залогинились), то используются данные из заголовка Accept-Language, который отправляет ваш браузер.

На данный момент доступны русский и английский языки.

4) Поддержка неограниченного количества пользователей.

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

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

В общем, если я когда-нибудь и займусь такой разработкой, то это будет совершенно другое приложение, а не очередная версия Circle Tasks.

5) Уменьшился размер JS файлов. В основном за счет замены jQuery UI () на JQuery Tools.

Кстати я первый раз использовал JQuery Tools и впечатления самые положительные. Функционала, конечно, меньше, чем в jQuery UI, но его должно хватить в 90% случаев. Легко изменяется оформление компонентов. И главное преимущество – размер. В общем, всем рекомендую попробовать.

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

Вы, конечно, знаете, что новые версии WordPress поддерживают древовидные комментарии.

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

В идеале разработчик темы WordPress должен использовать только параметры функции wp_list_comments (выводит список комментариев) и CSS стили.

Но идеальных вещей не существует в природе и WordPress – не исключение

В общем, стандартное оформление комментариев содержит несколько очень неприятных недостатков.

Например.

После имени комментатора выводится слово says:, которое нельзя изменить с помощью параметров wp_list_comments. Хотя, текст ссылки Reply можно изменить с помощью этой функции

Вывод даты имеет фиксированный формат, что-то вроде сентября 7, 2009 at 9:29 am

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

Проблема заключается в том, что эти настройки прописаны в файле wp-includes/comment-templates.php. Т.е. если мы внесем в него изменения, они будут перезаписаны после очередного обновления движка, которые, кстати, появляются довольно часто.

Кстати, строка 1226 в файле wp-includes/comment-templates.php выглядит так:

Видите, мы может изменить оформление слова says: (с помощью CSS класса says), но не можем изменить сам текст.

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

1) В файле comments.php вашей темы в параметре callback функции wp_list_comments указываем имя функции, которую нужно использовать для вывода комментариев.

В данном случае это mytheme_comment.

2) Создаем саму функцию. Она должна находиться в файл functions.php вашей темы.

Заново писать всю функцию целиком нет никакого смысла (разве что вы хотите сделать что-то неповторимое ). Лучше использовать готовый шаблон

Он полностью совпадает со стандартным выводом комментариев в WP.
Теперь можно немного его подправить.

Примечание. Почитать о форматировании дат можно здесь.

У меня получилось примерно следующее.

Строка с форматами даты и времени.

Слово says: я просто удалил.

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

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

В общем, тщательно тестируйте все ваши нововведения.

Удачи!

Интересно почитать

Разработка сайтов в Минске. Студия веб-дизайна в Минске.

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

Проблема оказалась мелкой и я все быстро исправил, но эта ситуация напомнила мне о законе подлости. Как только забываешь о тестировании – скрипты сразу перестают работать. Не зависимо от того, насколько они простые.

В данном случае дело было во включенных Magic Quotes (волшебных кавычках, хорошее название, появляются как по волшебству там, где не надо ).

Вообще-то, использование Magic Quotes не рекомендуемая практика.

В соответствующем разделе PHP manual ясно об этом сказано.

Warning

This feature has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 6.0.0. Relying on this feature is highly discouraged.

Предупреждение

Эта возможность считается устаревшей начиная с PHP 5.3.0 и будет удалена начиная с PHP 6.0.0. Рассчитывать на эту возможность крайне не рекомендуется.

Кратко поясню смысл этой функции. Она перехватывает данные, которые получает скрипт (массивы $_POST, $_GET и т.д.) и экранирует в них специальные символы.

Была разработана для защиты от хакерских атак вроде SQL Injection.

Но на практике от нее больше проблем, чем пользы.

Во-первых, 100% защиты она не обеспечивает. Т.е. вам все равно нужно самостоятельно проверять полученные данные (их тип, диапазон допустимых значений и т.п.). К тому же экранирование символов выполняется автоматически практически всеми библиотеками для работы с БД.

Во-вторых, часто нужны не экранированные данные.

Например, в моем случае ситуация была такой.

1) Клиент (браузер) передавал строку в формате json.
2) PHP при включенной Magic Quotes экранировал спец. символы.
3) функция json_decode возвращала NULL.

Почему хостеры включают Magic Quotes – вопрос отдельный. Может быть, хотят немного подстраховаться от начинающих разработчиков Или есть какие-то другие причины. Но в любом случае, вы можете легко ее отключить.

Посмотреть текущие настройки можно с помощью phpinfo(). (если Magic Quotes включена, в разделе Configure Command будет строка --enable-magic-quotes).

Для отключения создаем в папке со скриптами файл .htaccess с одной строчкой.

php_flag magic_quotes_gpc Off

Отключает Magic quotes для входящих данных из массивов GET/POST/Cookie.

Или добавляем эту же строчку в существующий .htaccess.

Примечание. Естественно, Magic Quotes можно отключить и в php.ini, но на shared хостинге у вас к нему доступа нет.

Подробнее об отключении Magic quotes можно почитать в PHP Manual.

Кстати, в нем есть пример функции, которая выполняет обратную операцию (удаляет слеши) – это на случай если хостер отключил поддержку .htaccess. Но, честно говоря, в такой ситуации я бы подумал о смене хостера.

До встречи!