Доброго времени суток!

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

Что нам понадобится?

Всего лишь небольшие знания HTML5+jQuery+PHP.

Введение

В прошлой статье, вот ссылочка, я обещал выложить плагин по «ползункам», доработав его учитывая большинство комментариев получилось «это»:



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

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

От полуподвальных контор из 3-5 человек до больших фирм 25-40 человек, работающих на рынке дорогих сайтов для крупных заказчиков. Но независимо от размера компании задачи были одни и те же.

• нужно продать дизайн
• сделать сайт, который не стыдно положить в портфолио
• сделать оригинально, как еще не делали конкуренты

Таким образом, задачи верстальщикам и дизайнерам ставились одинаковые: «давайте что-то креативное, свежее, интересное».

Я очень хорошо понимаю верстальщиков, дизайнеров и владельцев веб-студий, поэтому чтобы облегчить им поиск плагинов под готовый функционал и в то-же время показать что-то свежее, чего еще многие [возможно] не видели, решил уволиться отовсюду, и запустить проект Plugin Detector



В этой статье будет затронуто:

В чём проблема?

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

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

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

Взятие этого рубежа, достижение этого охвата радует меня немало. В России лишь четыре энциклопедические вики превосходят Традицию по числу статей: это две специализированные энциклопедии про кино («Энциклопедия кино RuData», насчитывающая 340 769 статей, и «Всё о кино», насчитывающая 47 406 статей), а также два научно-образовательных проекта («Виртуальная лаборатория», содержащая 204 082 статьи, и проект «Летописи», где 43 091 статья).

Кажется, это повод рассказать о Традиции на Хабрахабре.

Каждый web-разработчик сталкивается с задачей изменения положения того элемента списка, который хранится в базе при выводе. Решается эта задача следующим образом: создается поле order(INT) в таблице, записи, которой мы выводим. Затем в бэкенде мы видим что-то вроде этого:

или этого:

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

id	name	order
1	name1	1
2	name2	2
3	name3	3
4	name4	4

то для того, чтобы запись с id=4 переместить между 1 и 2, нам потребуется изменить order записей 2 и 3, таблица будет выглядеть следующим образом:

id	name	order
1	name1	1
2	name2	3
3	name3	4
4	name4	2

Это, довольно, нетривиальная задача.

Для организации варианта со второй картинки, требуется телодвижений поменьше, но это неудобно для пользователя. Если у нас в базе 30-40 записей, ему придется 30-40 раз тыкать мышкой на стрелочку вверх. Но ведь для этого есть справа текстовое поле для установки order вручную. Но этот способ не такой очевидный для пользователя. Хочется чего-то интуитивно-понятного и простого по коду.

Статья рассчитана не на профессиональных кодеров(у них есть 5-10 велосипедов для решения этой задачи с много меньшим количеством запросов к БД).

Судя по комментариям в этой статье, создание веб-приложений с возможностью аякс-навигации является интересной для сообщества темой и пока еще немногие сталкивались с подобной задачей. Я расскажу о ее решении с помощью небольшой библиотеки под названием jQuery-Pjax (либо моего форка ее).

Моя мотивация: в проекте нужно было реализовать mp3-плеер, играющий независимо от навигации на сайте. Далее потребовалось добавить поддержку браузеров без pushState — и я сделал форк библиотеки.

Основные особенности

• навигация по сайту и обработка форм без полной перезагрузки страниц
• чистые url, доступные для прямого доступа
• поддержка #!/hash для устаревших браузеров (добавлено в моей версии)
• работа с кнопками «назад» и вперед» для современных браузеров
• а теперь и для старых — благодаря benalman.com/projects/jquery-hashchange-plugin/
• похоже, есть проблемы с ИЕ7 (спасибо Nc_Soft) (тем более, большое спасибо за участие Nc_Soft) и, возможно, opera 11.5 (пока не могу подтвердить, но нахожу крайне удивительным из-за dev.opera.com/articles/view/introducing-the-html5-history-api/) — сообщение artishok — проверено и работает на сборке 1074 (not_ice)
• imsamurai (https://github.com/imsamurai) предложил улучшения библиотеки (и я радостью слил изменения): встроенная функция для отправки форм, улучшения работы с хешами и более развитая система триггеров. (у imsamurai, к сожалению, нет аккаунта на хабре — будем рады помощи)

Ссылки

• jQuery Pjax github.com/defunkt/jquery-pjax
• мой форк с поддержкой хеш-навигации github.com/ckald/jquery-pjax
• работа библиотеки на примере моего проекта amsterdamusic.com.ua/
• пример от создателя pjax.heroku.com/

Принцип работы Pjax

Как нетрудно прочесть на сайте MediaWiki, нынешняя линейка стабильных версий (1.16.x) поставляется со встроенною библиотекою jQuery, код которой лежит по адресу «skins/common/jquery.min.js». Это jQuery сравнительно старой версии (1.3.2, вышедшая в феврале 2009 года), слегка запатченная для преодоления одного из её багов, и она запускается в режиме совместимости («noConflict()») таким образом, чтобы поместиться в переменную $j вместо $. Этот код jQuery не содержит никаких плагинов и является, в сущности, необязательным, подключаясь к странице только в том случае, когда код MediaWiki содержит вызов метода $wgOut->includeJQuery(). Скажем, расширение UsabilityInitiative содержит именно такой вызов на строке 128 своего файла «UsabilityInitiative.hooks.php», так что jQuery появляется в некоторых темах оформления (например, в Vector), когда расширение UsabilityInitiative подключено к вики.

Предлагаю встать на точку зрения вики-техника, то есть администратора сервера MediaWiki, имеющего прямой доступ (наподобие SSH) и возможность менять настройки вики (LocalSettings.php), доустанавливать расширения MediaWiki и проводить другие подобные действия. Какие обстоятельства могут вызвать у вики-техника MediaWiki 1.16.x стремление переменить к лучшему то положение дел, которое упомянуто в предыдущем абзаце? Каким путём уместнее всего действовать вики-технику на пути воплощения этого своего стремления?

Первотолчком такого стремления является естественное и почти неизбежное осознание того, как неудобна та необязательность появления jQuery в коде страниц, которая настроена по умолчанию. Всякий вики-техник, если он имеет достаточно досуга для размышлений, рано или поздно постигает, что простота и могущество функции $(…), если бы она была всегда в распоряжении администраторов, сочиняющих скрипты для вики, всенепременно породили бы JS-код куда компактнее, чем прежний. Возьмём для примера версию от 22 мая 2011 года страницы «MediaWiki:Common.js» из россияноязычной Википедии. В ней нетрудно заметить вот какой код функции: