ckFinder - это очень хороший файл менеджер, удобный прежде всего тем, что полностью интегрируется с моим любимым wysiwyg редактором ckEditor. Закачать фото, нарезать его, переименовать, удалить и т.д., словом полный комплект из-под коробки. Все в нем отлично, но эта надоедливая надпись This is the DEMO version of CKFinder. Please visit the CKFinder web site to obtain a valid license мешает жить). При этом ckFinder совсем не ограничивает функционал менеджера в демо версии, т.е. единственный минус - эта надпись.

Да, вы правильно поняли. Продукт платный. И стоит он ни много ни мало 59$ для одного сайта. В ранних версиях ckfinder была кнопка закрытия данной надписи, надпись конечно появлялась, но на время работы о ней можно было забыть. В свежей версии, которую я скачал с офсайта, такою кнопку не нашел. Значит пришла пора удалить надоедливую надпись самим.

Рассказать друзьям

Событийная модель реализуется по-разному в IE и Firefox. В IE, есть явный объект window.event, который содержит подробности о произошедшем событии (например: OnClick), в тот момент когда оно происходит, в то время как в Firefox и других W3C совместимых браузерах, объект event автоматически передается в функцию - обработчик события,в качестве аргумента, и содержит аналогичную информацию о событии. Для кросс браузерной обработки событий это нужно обходить так:

document.onclick=function(e){
 var evt=window.event || e //evt автоматически выберет из двух значений нужное
 alert(evt.clientX) //что-то делаем с evt
}

 Кроме доступа к объекту, браузеры поддерживают разные поля и методы объекта event.  Ниже перечислены основные отличия и способы их обхода.

Рассказать друзьям

Я отношусь к той группе людей, которые плохо дружат с русским языком. Так уж сложилось, в школе больше привлекало все техническое. Для экономии времени статьи иногда выгодно писать через веб-интерфейс админки, в обход MsWord. Но вот беда, отличный WYSWYG редактор ckEditor не проверяет русскую орфографию. Более того, он еще отключает нативную проверку орфографии браузером. Те, кто пользуются TinyMCE, знают всю прелесть красной подсветки больных мест текста.

Еще в  ckeditor'е есть средство для проверки орфографии. Работает оно через сервис http://www.spellchecker.net/  и делает это как-то неуклюже, да и с русским дружит не больше моего.

Практически во всех современных браузерах Chrome,FireFox, Opera и т.д. есть своя система проверки орфографии(нативная). По дефолту, ckeditor ее отключает. Ну что же, исправим это досадное недоразумение.

В файле ckeditor/config.js добавляем строчку

config.disableNativeSpellChecker = false;

по-русски это значит следующее: отключить отключалку нативной проверки орфографии.

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

Все работает, все замечательно, но вот беда: если вызвать контекстное меню, ckeditor заменяет его на свое - копировать,вставить(кто-то им вообще пользуется?). Это вызывает большое неудобство, не всегда сразу понятно, что не так в подсвеченном красным слове. Когда видишь такое слово хочется посмотреть почему оно подсвечено и какие есть варианты написания. Если слово новое, и нативный spellchecker его не знает, то можно занести слово в словарь. Но вместо этого нам предлагают лишь копировать-вставить) Исправим и это

Рассказать друзьям

Когда вы имеете дело со временем в JavaScript, иногда хочется представить его в виде секундного хеша, как в php. Там количество секунд прошедших с 1 января 1970 года(UnixTime) возвращает функция time(). Возвращает она обычный int. Благодаря этому с этой величиной очень удобно работать: сортировать, сравнивать и т.д.

В javaScript иногда тоже нужен такой же функционал. К примеру раскидывать данные в массив, а потом сортировать его по времени. unixtime в js возвращает метод getTime объекта Date, но в отличии от php, он возвращает еще и миллисекунды.

Поэтому все надо разделить на 1000.

function time(){
return parseInt(new Date().getTime()/1000)
}
alert(time())//1300051970

Вот и все, авось кому пригодится

Рассказать друзьям

Из таких web приложений, как Google Wave, Gmail и т.п.  мы видим, что кеширование данных на стороне клиента это хорошая идея для большинства веб-приложений. Подумайте сами, для мобильного интернета очень важен объем трафика. Однотипные запросы в 70% случаях (я не делал никаких расчетов, просто выражать доводы в процентах гораздо солиднее) возвращают одни и те же данные. Кроме того кешировать можно не только данные, но и само приложение.  

До сих пор наиболее популярным методом для локального хранения были cookie. Cookie - это пара ключ-значение, которые хранятся локально в текстовом файле (4KB  или 20 пар ключ-значение максимум(IE) для одного домена). Кроме того cookie передаются на сервер при любом HTTP запросе на сервер, даже при AJAX. Закономерно, что  в стандарте должны были появится средства для более практичного хранения данных в браузере. 

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

Итак, хранилище на стороне клиента делится на 3 принципиальных методологии:

  1. Session storage.
  2. Local storage или Global Storage
  3. Database storage

 

Рассказать друзьям

Подкатегории

Все о разработке на библиотеке jQuery