Я проверил плагин на реальном проекте. Действительно хорошая помощь в деле создания сложных форм.
Я нашел ряд ошибок (версия 0.0.2):
Строка 14, ошибка в названии переменной (code вместо codes):
jQuery('input,textarea').live('keyup change',function(e) {
var codes= [33,34,36,35,45,38,40,37,39]//arrows and others
if(e.keyCode && jQuery.inArray(e.keyCode,code)<0)//skip this keyUps to let this keys work as expected
jQuery(this).attr('value',this.value)
});
Строки 115, 477, вызов функции trim объекта String. Этот метод ввели совсем недавно (если не ошибаюсь, в версии 1.8.1, Firefox 3.5), и далеко не во всех популярных браузерах (особенно понимаете где) он работает. Я бы заменил на jQuery.trim().
Так же есть вызовы функции debug, которая, к тому же, использует console, что вызывает ошибки в браузерах, где консоли нет.
Я не ищу оправданий в стандартном стиле IDE, я привел его как пример зависимости тонкостей стиля написания кода от вкусов человека, пишущего код.
Наверно, конечно, вы правы в том, что при публикации материалов о фреймворке приведение кода к его стандартам является плюсом. Но разве при разработке под каждый фреймворк обязательно нужно соблюдать индивидуальный стиль кода его дистрибутива? Например, у Zend framework'а другие стандарты, а переключаться в голове между разными стилями не так просто )
Свойства я обычно не делаю публичными, поэтому не выделяю их. Я разделяю мнение, что прямого доступа к свойствам следует избегать.
Методы бывают как публичные, так и защищенные, поэтому защищенные я выделяю подчеркиванием в начале, чтобы при чтении кода было понятно, что вызывается защищенный метод, вызов которого извне не предусмотрен.
В основном я использую CamelCase. Здесь через подчеркивание назвал аналоги методов из класса Cache_File.
Поскольку я не претендовал на включение моего модуля в дистрибутив, я позволил себе некоторые вольности.
Многие вещи в соглашении Коханы расходятся с моими моральными принципами. Например, для того, чтобы написать так:
// Correct:
$db = new Database;
мне нужно фактически переступить через себя ) Я привык писать «неправильно»:
// Incorrect:
$db = new Database();
Все-таки, в случае, если код не будет включаться в какой-то общий проект, тонкости оформления кода, такие как, где ставить скобки или пробелы — это вопрос вкуса. К примеру, автоматическое форматирование кода в NetBeans нарушает куда больше пунктов этого соглашения, чем нарушил я.
Да, здесь не предполагается добавление информации пользователями, ограничение существенное. Но в сфере сайтов, например, для небольших фирм, это не требуется. Модуль разрабатывался именно для подобных случаев. В других условиях, конечно, нужно было бы применять более оптимальные методы, а еще лучше — Memcache и другие хорошие вещи.
С одной стороны, это решение действительно привело бы к оптимизации поиска по тегам. Но нужна ли она в тех условиях, которые я описал? Ведь это привело бы к увеличению времени поиска по ключу, что здесь более критично, так как поиск по ключу — для клиентов, поиск по тегам — для администратора.
Почти на все вопросы ответ содержится в постановке задачи )
На файлах потому, что нет другого выхода — ограничения хостинга. Записывать все данные в имена файлов было бы можно, но для конкретной задачи, как мне кажется, не обязательно. К тому же, скорость чтения файла будет выше, если обратиться к нему по полному имени, а не по маске.
Как я уже говорил, предполагается использование на небольших сайтах, администрируемых одним человеком или небольшой группой людей. Информация обновляется нечасто, а ведь именно при обновлении происходит чтение всех файлов.
Таким образом, СУБД разгружена, у клиентов скорость чтения увеличена. А администратор может потерпеть ) Тысяч файлов, опять же, не будет из-за относительно небольшого объема информации.
А для сайтов, где огромная база данных, частое обновление информации и все такое, нужен серьезный хостинг. И для этого случая во фреймворке уже есть хорошие стандартные решения, и ничего изобретать не надо.
Это верно. Но вопрос в том, стоит ли использовать Sqlite для кэширования данных, извлеченных из MySQL? Особенно если можно использовать более быстрые методы.
Я имел в виду, что если теги хранятся внутри файла, к нему можно обратиться по хорошо известному имени напрямую, без применения маски и функции glob(). Это ускоряет чтение данных. Хранение же тегов внутри файла снижает скорость поиска по тегам, но в рассмотренном случае это не критично.
Ну да ) Правда, в приведенном случае теги используются только при очистке кэша. А поскольку она происходит только при редактировании информации администратором сайта, трагизм ситуации снижается. Возможно, это даже делает преимуществом хранение тегов внутри файла.
Как было сказано в постановке задачи, в данном случае подходят только файлы )
К тому же, я придерживаюсь мнения, что если есть возможность использовать использовать софт из дополнительного набора, лучше использовать Memcache или Xcache. Например, в документации скорость работы Sqlite оценена как «Poor» — так же, как и у файлового кэша: kohanaframework.org/3.1/guide/cache#choosing-a-cache-provider
Может быть. Но в условиях сайтов с невысокой посещаемостью, размещенных на стандартных хостингах, такие варианты не применимы из-за отсутствия Memcache и других замечательных вещей. Остаются только файлы.
Интересное решение. Но в моем случае использование имен таблиц в качестве тегов было бы не очень целесообразно в связи с тем, что из одних и тех же таблиц извлекаются разные наборы данных в зависимости от ситуации.
Сказать честно, я пользуюсь Kohana с версии 3.0, поэтому файловый кэш с тегами не застал. Нужно будет изучить эту реализацию. Остальные замечания всенепременнейше учту в JetCache 2.0 )
Я нашел ряд ошибок (версия 0.0.2):
Строка 14, ошибка в названии переменной (
codeвместоcodes):Строки 115, 477, вызов функции
trimобъектаString. Этот метод ввели совсем недавно (если не ошибаюсь, в версии 1.8.1, Firefox 3.5), и далеко не во всех популярных браузерах (особенно понимаете где) он работает. Я бы заменил наjQuery.trim().Так же есть вызовы функции
debug, которая, к тому же, используетconsole, что вызывает ошибки в браузерах, где консоли нет.Наверно, конечно, вы правы в том, что при публикации материалов о фреймворке приведение кода к его стандартам является плюсом. Но разве при разработке под каждый фреймворк обязательно нужно соблюдать индивидуальный стиль кода его дистрибутива? Например, у Zend framework'а другие стандарты, а переключаться в голове между разными стилями не так просто )
Методы бывают как публичные, так и защищенные, поэтому защищенные я выделяю подчеркиванием в начале, чтобы при чтении кода было понятно, что вызывается защищенный метод, вызов которого извне не предусмотрен.
В основном я использую CamelCase. Здесь через подчеркивание назвал аналоги методов из класса Cache_File.
Многие вещи в соглашении Коханы расходятся с моими моральными принципами. Например, для того, чтобы написать так:
мне нужно фактически переступить через себя ) Я привык писать «неправильно»:
Все-таки, в случае, если код не будет включаться в какой-то общий проект, тонкости оформления кода, такие как, где ставить скобки или пробелы — это вопрос вкуса. К примеру, автоматическое форматирование кода в NetBeans нарушает куда больше пунктов этого соглашения, чем нарушил я.
На файлах потому, что нет другого выхода — ограничения хостинга. Записывать все данные в имена файлов было бы можно, но для конкретной задачи, как мне кажется, не обязательно. К тому же, скорость чтения файла будет выше, если обратиться к нему по полному имени, а не по маске.
Как я уже говорил, предполагается использование на небольших сайтах, администрируемых одним человеком или небольшой группой людей. Информация обновляется нечасто, а ведь именно при обновлении происходит чтение всех файлов.
Таким образом, СУБД разгружена, у клиентов скорость чтения увеличена. А администратор может потерпеть ) Тысяч файлов, опять же, не будет из-за относительно небольшого объема информации.
А для сайтов, где огромная база данных, частое обновление информации и все такое, нужен серьезный хостинг. И для этого случая во фреймворке уже есть хорошие стандартные решения, и ничего изобретать не надо.
К тому же, я придерживаюсь мнения, что если есть возможность использовать использовать софт из дополнительного набора, лучше использовать Memcache или Xcache. Например, в документации скорость работы Sqlite оценена как «Poor» — так же, как и у файлового кэша: kohanaframework.org/3.1/guide/cache#choosing-a-cache-provider
Правда, у них уже есть готовое решение. Интересно, почему оно не вошло в 3 версию.