Я бы пользовался серсивами гугла будь они немного более кроссбраузерными. Знаете неприятно, когда с Оперой гугл отсылает всех куда подальше. Плюс наверное большинство людей ещё психологически не доросло до веб-офиса.
Насчет локализации пока ничего не скажу. Сейчас дочитываю документацию и делаю свой сервер.
А вот насчет " нужно лишь реализовать эти методы на JS так, как ожидают приложения для OpenSocial." то для этого всё равно Shindig нужен как сервер гаджетов. Такие методы как GetFriends это state приложения и в тестовых контейнерах их предлагают грузить с XML-файлов. То есть вам остается нужен сервер гаджетов для осуществления всего их функционала, а вот задать параметры своей социалки действительно крайне просто: создать контейнер, загрузить в него гаджет и сгенерированый XML со всеми параметрами.
Ну это конечно да, серьёзный проект может и свои виджеты разработать. Но не знаю, тут я против изобретения велосипедов.
Через конфигурацию Shindig можна настроить использование нужных бекендов и переписать их под свой проект. Но вот переписывать всё... У меня есть небольшой проект и я действительно хочу встроить в него OpenSocial. Но вот не знаю стоит ли с этим связываться, если в самом Shindig написано, что пока он только подходит для тестирования гаджетов.
Да, спасибо, про Shinding нужно было написать подробнее. Вот что говорит про него официальный сайт:
The architectural components of Shindig can be broken down as follows:
Gadget Container JavaScript core JavaScript foundation for general gadget functionality. This JavaScript manages security, communication, UI layout, and feature extensions, such as the OpenSocial API.
Gadget Server an open source version of Google's gmodules.com, which is used to render the gadget XML into JavaScript and HTML for the container to expose via the container JavaScript.
OpenSocial Container JavaScript JavaScript environment that sits on top of the Gadget Container JavaScript and provides OpenSocial specific functionality (profiles, friends, activities, datastore).
OpenSocial Gateway Server (does not yet exist in the repository) an implementation of the server interface to container-specific information, including the OpenSocial REST APIs, with clear extension points so others can connect it to their own backends.
А насчет остальных вопросов, то я сам хочу в них разобраться. Пока что мне быо интересно поставить свой контейнер, а что и как там происходит буду смотреть завтра на свежую голову :)
Ну я ничего действительно универсального предложить не могу. Действительно подход указывания в шаблоне настроек кеша самый гибкий. Но тут ниже уже говорили, что верстальщикам такая радость не нужна.
Мне действительно кажеться логичнее задавать настройки кеша по имени фрагмента шаблона. Учитывая, что в Джанге есть их наследование, то "хранить несколько версий основываясь на контексте вызова". С параметрами система может кешировать и сама, искусственного интеллекта, чтоб создавать разные кеши под разные параметры не нужно.
Всё равно оно как-то непрозрачно, а написание отдельного костыля для вполне обыденной задачи тоже как-то не впечатляет. Я сужу только по этой статье, так что если я не прав - не пинайте сильно. Но всё равно, я за отделение конфигурации и кода, и всё-таки было бы лучше если бы фреймворк сам умел это делать.
Что-то мне принцип не нравиться, так как параметры кеширования загоняются в сам шаблон. Если нужно поменять таймаут нужно лазить по всем шаблонам где используется данный фрагмент и его менять. Как-то нелогично получается. Да и засорять код всякими cache_ не считаю красивым, имхо удобнее выкинуть это в конфигурационные файлы.
Если интерфейсов не существует их изобретают. В питоне изобрели протоколы. Имхо, всё-таки немного более громоздкое решение, чем интерефейсы. Да и просто интерфейсы как-то привычнее.
18 мегабайт основная программа
это в свернутом режиме
А вот насчет " нужно лишь реализовать эти методы на JS так, как ожидают приложения для OpenSocial." то для этого всё равно Shindig нужен как сервер гаджетов. Такие методы как GetFriends это state приложения и в тестовых контейнерах их предлагают грузить с XML-файлов. То есть вам остается нужен сервер гаджетов для осуществления всего их функционала, а вот задать параметры своей социалки действительно крайне просто: создать контейнер, загрузить в него гаджет и сгенерированый XML со всеми параметрами.
(если какая-то крупная американская компания затребует права на него - не ведитесь)
Через конфигурацию Shindig можна настроить использование нужных бекендов и переписать их под свой проект. Но вот переписывать всё... У меня есть небольшой проект и я действительно хочу встроить в него OpenSocial. Но вот не знаю стоит ли с этим связываться, если в самом Shindig написано, что пока он только подходит для тестирования гаджетов.
The architectural components of Shindig can be broken down as follows:
Gadget Container JavaScript core JavaScript foundation for general gadget functionality. This JavaScript manages security, communication, UI layout, and feature extensions, such as the OpenSocial API.
Gadget Server an open source version of Google's gmodules.com, which is used to render the gadget XML into JavaScript and HTML for the container to expose via the container JavaScript.
OpenSocial Container JavaScript JavaScript environment that sits on top of the Gadget Container JavaScript and provides OpenSocial specific functionality (profiles, friends, activities, datastore).
OpenSocial Gateway Server (does not yet exist in the repository) an implementation of the server interface to container-specific information, including the OpenSocial REST APIs, with clear extension points so others can connect it to their own backends.
А насчет остальных вопросов, то я сам хочу в них разобраться. Пока что мне быо интересно поставить свой контейнер, а что и как там происходит буду смотреть завтра на свежую голову :)
Сейчас почитаю...
Мне действительно кажеться логичнее задавать настройки кеша по имени фрагмента шаблона. Учитывая, что в Джанге есть их наследование, то "хранить несколько версий основываясь на контексте вызова". С параметрами система может кешировать и сама, искусственного интеллекта, чтоб создавать разные кеши под разные параметры не нужно.