ммм. действительно, я неверно воспринял вопрос. вы правы.
основной трабл в том, что соединение-то через wi-fi, а почему-то при работе с iphone'ом оно там медлено и отваливалось.
там не 128, а что-то около 80ти метров память это раз, половина из нее понятно чем занята, это два, проц там вообще arm это три.
но если есть желание поставить туда mysql, мне будет интересно посмотреть на результат.
из вики: "Гуманизм (от лат. humanitas — человечность) - ...". от слова человек. этот термин не может быть применен к ИИ до тех пор, пока вы не будете воспринимать ИИ как человека.
раньше кодировали зендом 3 файлика из ядра, где проверяется лицензия. сейчас оставили кодирование только в младшей линейке, бесплатных и trial дистрибутивах.
с точки зрения защиты кода зендование не спасет отца русской демократии, а проблемы от него бывают очень оригинальные (не считая проблемы наличия на хостинге, но она как раз легко решается).
на самом деле, открывать достаточно только прикладной код модулей. но разницы особо никакой, поэтому проще открыть все. кому-нибудь обязательно пригодится, "спасибо" скажут.
с точки зрения потери налички, лично я в этом опасности не вижу. покупают-то не код.
Смитаныч, я не знаю, что у тебя там произошло, но в тут что-то не сказано. Я знаю и тебя и Сергея достаточно давно и пока не представляю, что могло послужить поводом для этой истории.
А вообще так не делают, Юра. Даже если ты действительно обижен на ген. директора, то не нужно кидать какашки во всю студию, потому что там работает еще много хороших людей. Тем более, что это ваш личный конфликт ИМХО.
По поводу все, что кроме GET-параметров, я уже ответил ниже.
Теперь насчет параметров. Я тоже размышлял об их необходимости, и тут достаточно неоднозначно. Зачастую это не нужно.
Если кратко, то параметры могут управлять отображением. Больше особо с ними ничего не сделаешь. Судя по наличию в xslt инструкции "xsl:param", с помощью которой в т.ч. можно передавать параметры в шаблон, так считали и разработчики стандарта. А передать в качестве параметров что-то из get'а вполне разумно. В конце концов шаблон имеет право это знать.
Если бы в xslt можно было использовать переменные (не константы), такую возможность давать было бы действительно небезопасно. :)
так точно. я занимаюсь непосредственно проектированием системы.
сейчас объясню, почему работает именно так.
1. По поводу xslt, xml в принципе.
У нас прижился принцип: давать ровно столько данных, сколько необходимо не больше и не меньше. Это продиктовано все той же необходимостью уменьшить размер XML-документа, который необходимо генерить. + еще это достаточно элегантно.
2. Принцип, на котором построены внутренние url-схемы.
Этот подход обусловлен желанием соответствовать идеологии REST.
С этой точки зрения CMS предоставляет набор сервисов. Совсем не важно, как они сгенерировались. Возможно, из кеша, возможно, еще откуда-то. Это неважно. Важно то, что они там есть, что они нужного формата.
И системе тоже неинетерсно, откуда эти сервисы вызываются: через XSLT, из FLASH-версии сайта, через AJAX, через десктопное приложение, и т.д..
Это тот же вариант, что и mash-up. При желании я всегда могу, например объединить список новостей со своего сайта со списком новостей с сайта-сателита. Или брать их из интранет-системы.
Такой подход дает и такое преимущества как:
1. Независимость тестирование. можно тестировать не всю систему, а отдельный сервис. и это наглядно.
2. Если какой-то сервис "отваливается": внутренний или внешний, то это не смертельно.
3. Всякие гаджеты и плагины собираются практически мгновенно. К примеру малополезный, но показательный плагин к firefox'у: http://www.umi-cms.ru/extensions/umi_lic… собран меньше чем за пол часа в процессе изучения плагинов firefox'а.
4. Это поддержка AJAX'а и, наример, флеш-сайтов без лишних движений.
И все эти сервисы учитывают права доступа, и прочее, что у нас делается на бэк-энде.
PS1. Хочу отметить, что внутренние схемы придумали не мы, а подсмотрели у достаточно крутого XSLT-фреймворка.
PS2. Хорошим примером в пользу REST для нас явился google. Не помню, чтобы он когда-либо сильно ошибался в технологическом плане.
Делюсь опытом тезисно :)
1. Браузеры умеют рендерить XSLT, по-разному
2. Не все версии браузеров это умеют (к примеру, opera)
3. В мобильных версиях браузеров тоже проблемы
4. До сих пор не знаю, как будет индексироваться такой сайт. (в яндекс, внятно не ответили. больше не писал. может, и умеет)
5. Если xsl'ка не догрузится, мы вообще ничего не увидим
Из плюсов - удобно в ajax'е. Небольшие шаблоны можно использовать и для серверной обработки и грузить на клиенте. Бывает удобно и вообще повторное использование кода это добро.
основной трабл в том, что соединение-то через wi-fi, а почему-то при работе с iphone'ом оно там медлено и отваливалось.
но если есть желание поставить туда mysql, мне будет интересно посмотреть на результат.
ps. жизнь без секса? нет, спасибо.
pss. оч. понравилось, спасибо.
или моральные проблемы создания искусственного интеллекта
с точки зрения защиты кода зендование не спасет отца русской демократии, а проблемы от него бывают очень оригинальные (не считая проблемы наличия на хостинге, но она как раз легко решается).
на самом деле, открывать достаточно только прикладной код модулей. но разницы особо никакой, поэтому проще открыть все. кому-нибудь обязательно пригодится, "спасибо" скажут.
с точки зрения потери налички, лично я в этом опасности не вижу. покупают-то не код.
А вообще так не делают, Юра. Даже если ты действительно обижен на ген. директора, то не нужно кидать какашки во всю студию, потому что там работает еще много хороших людей. Тем более, что это ваш личный конфликт ИМХО.
match="item[position() div 2 = 1]"
ps. буду рад вашим предложениям )
Теперь насчет параметров. Я тоже размышлял об их необходимости, и тут достаточно неоднозначно. Зачастую это не нужно.
Если кратко, то параметры могут управлять отображением. Больше особо с ними ничего не сделаешь. Судя по наличию в xslt инструкции "xsl:param", с помощью которой в т.ч. можно передавать параметры в шаблон, так считали и разработчики стандарта. А передать в качестве параметров что-то из get'а вполне разумно. В конце концов шаблон имеет право это знать.
Если бы в xslt можно было использовать переменные (не константы), такую возможность давать было бы действительно небезопасно. :)
сейчас объясню, почему работает именно так.
1. По поводу xslt, xml в принципе.
У нас прижился принцип: давать ровно столько данных, сколько необходимо не больше и не меньше. Это продиктовано все той же необходимостью уменьшить размер XML-документа, который необходимо генерить. + еще это достаточно элегантно.
2. Принцип, на котором построены внутренние url-схемы.
Этот подход обусловлен желанием соответствовать идеологии REST.
С этой точки зрения CMS предоставляет набор сервисов. Совсем не важно, как они сгенерировались. Возможно, из кеша, возможно, еще откуда-то. Это неважно. Важно то, что они там есть, что они нужного формата.
И системе тоже неинетерсно, откуда эти сервисы вызываются: через XSLT, из FLASH-версии сайта, через AJAX, через десктопное приложение, и т.д..
Это тот же вариант, что и mash-up. При желании я всегда могу, например объединить список новостей со своего сайта со списком новостей с сайта-сателита. Или брать их из интранет-системы.
Такой подход дает и такое преимущества как:
1. Независимость тестирование. можно тестировать не всю систему, а отдельный сервис. и это наглядно.
2. Если какой-то сервис "отваливается": внутренний или внешний, то это не смертельно.
3. Всякие гаджеты и плагины собираются практически мгновенно. К примеру малополезный, но показательный плагин к firefox'у: http://www.umi-cms.ru/extensions/umi_lic… собран меньше чем за пол часа в процессе изучения плагинов firefox'а.
4. Это поддержка AJAX'а и, наример, флеш-сайтов без лишних движений.
И все эти сервисы учитывают права доступа, и прочее, что у нас делается на бэк-энде.
PS1. Хочу отметить, что внутренние схемы придумали не мы, а подсмотрели у достаточно крутого XSLT-фреймворка.
PS2. Хорошим примером в пользу REST для нас явился google. Не помню, чтобы он когда-либо сильно ошибался в технологическом плане.
1. Браузеры умеют рендерить XSLT, по-разному
2. Не все версии браузеров это умеют (к примеру, opera)
3. В мобильных версиях браузеров тоже проблемы
4. До сих пор не знаю, как будет индексироваться такой сайт. (в яндекс, внятно не ответили. больше не писал. может, и умеет)
5. Если xsl'ка не догрузится, мы вообще ничего не увидим
Из плюсов - удобно в ajax'е. Небольшие шаблоны можно использовать и для серверной обработки и грузить на клиенте. Бывает удобно и вообще повторное использование кода это добро.