Заметьте, по ссылке на мой багрепорт от 10 июня с жалобой на то, чтобы они поправили карты и не пользовали там eval, они не исправили карты, а через 2 месяца предложили sandboxing. Не буду себе льстить, вряд ли они это сделали из-за меня, но тем не менее это им показалось проще чем починить карты, а в расширениях просто запретить eval к черту.
Внедрение CSP вообще очень болезненно проходит, авторы больших расширений плюются и, не осилив (или осознав, скольких фич лишится их расширение), возвращаются обратно на первую версию манифеста.
Мне кажется, все это дело еще неплохо попилят. Лучше бы попилили до выдачи требований разработчикам.
Что забавно, карты Google без sandbox'а использовать не получится, а Яндексовые — получится :)
Не стоит потому что объект не нужен. Создавать объект только ради того, чтобы дернуть у него метод init — это рак мозга.
Еще больший рак мозга, к примеру, метод объекта blurOnEnter, который нужен как обработчик собырия keypress в одном из полей. Это просто мешанина ненужных методов, которые никак не связаны с объектом. Можно сказать что это не просто полезный объект, а неймспейс с кучей мусорных функций.
Все это дело можно написать гораздо «более лучше» при сохранении компактности.
Да не, я не говорю что он плохой, наоборот, он мне очень помог и подкинул пару идей. У меня просто задача специфическая и мне все равно придется писать что-то вроде этого самому :)
Ваш код помог разобраться с IndexedDB чуть глубже, чем я его знал :)
Но он тоже какой-то громоздкий и в window создает несколько объектов. Кстати, зачем идет привязка к jQuery? Вроде нигде не пользуется.
В любом случае, мне кажется, что indexedDB не проживет долго в таком виде, его либо упростят, либо тоже сделают deprecated.
Не надо их больше проводить.
Мне кажется, все это дело еще неплохо попилят. Лучше бы попилили до выдачи требований разработчикам.
Что забавно, карты Google без sandbox'а использовать не получится, а Яндексовые — получится :)
Мой путь — красивый код.
Закончим на этом бесполезную дискуссию.
Еще больший рак мозга, к примеру, метод объекта blurOnEnter, который нужен как обработчик собырия keypress в одном из полей. Это просто мешанина ненужных методов, которые никак не связаны с объектом. Можно сказать что это не просто полезный объект, а неймспейс с кучей мусорных функций.
Все это дело можно написать гораздо «более лучше» при сохранении компактности.
Но выносить абсолютно все в разные методы ненужного объекта без какой-нибудь необходимости не стоит точно.
А почему realtime? Зачем?
Зачем столько злости? Предлагаю на этом закончить дискуссию :)
скорее для каждой комбинации темы и включенных настроек, которые меняют css/js
Но он тоже какой-то громоздкий и в window создает несколько объектов. Кстати, зачем идет привязка к jQuery? Вроде нигде не пользуется.
В любом случае, мне кажется, что indexedDB не проживет долго в таком виде, его либо упростят, либо тоже сделают deprecated.