<!--toc--> |
|
####Вы сумасшедший или мазохист? |
|
Насколько мне известно — нет. |
|
####Зачем создавать веб-сайты на C++? |
|
Есть много причин, смотрите [Обоснование CppCMS](/wikipp/ru/page/rationale). |
|
####CppCMS — это такая же готовая система управления контентом (CMS), как Drupal? |
|
Нет, CppCMS не является системой управления контентом (CMS) аналогичной Drupal, это фреймворк веб-разработки, такой как Django или RoR. |
|
####Если CppCMS не CMS, откуда пришло это название? |
|
Оригинальная идея — «Напиши собственную _CMS_ на _C++_» |
|
####Зачем делать веб-сайты на C++? Это опасный язык! |
|
Современный C++ — безусловно сложный язык и требует гораздо больше времени для ознакомления, по сравнению с динамическими языками вроде Python или PHP, или статическими вроде C#/Java, которые очень популярны в веб-разработке. |
|
Однако если Вы в нем разберетесь, у Вас есть огромный набор средств, позволяющих писать приложения быстро и безопасно, без утечек памяти и случайных падений. Если Вы придерживаетесь принципов [RAII](http://ru.wikipedia.org/wiki/RAII), пишете защищенный код с использованием исключений и _понимаете,_ как работает STL, для вас всё будет простым и вполне ясным. |
|
####Разве главным узким местом любого веб-приложения не является SQL-движок, а не язык серверной части? |
|
Это весьма распространенное заблуждение. И его весьма легко проверить. Запутив простые тесты производительности типичной CMS вы обнаружите, что она может создавать около 5-50 страниц в секунду. |
Это весьма распространенное заблуждение. И его весьма легко проверить. Запустив простые тесты производительности типичной CMS вы обнаружите, что она может создавать около 5-50 страниц в секунду. |
|
Если Вы возьмете лог SQL-запросов к базе данных и запустите их аналогично тому, как если бы они были запросами от движка CMS, то обнаружите, что можете достичь 1000 запросов в секунду (запросов, не SQL-запросов)... Таким образом, SQL создает около 5% от Вашей общей проблемы производительности. |
|
Фактически, если взять действительно большие проекты вроде Википедии, можно обнаружить, что гораздо больше вычислительных ресурсов тратится на обработку PHP, чем на обработку SQL-запросов. |
См.: ["Являетя ли база данных узким местом веб-сервиса?"](http://art-blog.no-ip.info/cppcms/blog/post/42) |
См.: ["Является ли база данных узким местом веб-сервиса?"](http://art-blog.no-ip.info/cppcms/blog/post/42) |
|
####Как я могу помочь? |
|
Прочитайте [это руководство](/wikipp/ru/page/contrib) |
|
####Какова политика лиценизрования? |
####Какова политика лицензирования? |
|
фреймворк лицензируется на условиях [LGPL](http://ru.wikipedia.org/wiki/GNU_Lesser_General_Public_License) и других, совместимых с LGPL лицензий. Это означает (в основном): |
|
1. Вы можете создавать коммерческие и FOSS приложения с этим фреймворком. |
2. Вы **обязаны** свободно распространять изменения, сделанные в фреймворке самостоятельно. Однако это не заставляет Вас также распространять свой собственный код приложений. |
|
Приложения основанные на CppCMS, являющиеся часть Проекта CppCMS Project (как этот wiki) лицензируются на условиях [GPL](http://ru.wikipedia.org/wiki/GPL). |
|
####Планируете ли Вы изменить лицензию фреймворка в будущем? |
|
Пока я не сошел с ума (см. Q1), я не не собираюсь менять лицензию на проприетарную или жесткую [копилефт-лицензию](http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BF%D0%B8%D0%BB%D0%B5%D1%84%D1%82). Т.е.: |
|
1. Я не закрою исходники. |
2. Я не переключусь на что-то вроде GPL и заставлю коммерчексих пользователей приобретать лицензии (как Trolltech или C++ Web Toolkit). |
2. Я не переключусь на что-то вроде GPL и заставлю коммерческих пользователей приобретать лицензии (как Trolltech или C++ Web Toolkit). |
|
Я могу изменить лицензию на что-то более разрещающее. |
Я могу изменить лицензию на что-то более разрешающее. |
|
|
####Какие из текущих фреймворков на Вас повлияли? |
|
В основном Django. Иногда, когда я хочу добавить какое-нибудь новшество в CppCMS, я читаю документацию Django и пытаюсь понять, как они это сделали. |
|
Хорошие примеры: наследование темплейтов и форм. |
|
####Это кроссплатформенный проект? |
|
_Короткий ответ:_ Да |
|
_Более длинный ответ:_ Зависит от того, какой Вы видите кросс-платформенную переносимость. |
|
_Длинный ответ:_ |
|
Версия 0.0.x этого фреймворка написана для [POSIX](http://ru.wikipedia.org/wiki/Posix)-совместимых/Unix-подобных платформ. Известно, что она работает на Linux, FreeBSD, Solaris и Windows/Cygwin. |
|
Windows не поддерживает стандарты POSIX, поэтому CppCMS 0.0.x можно собрать только через уровень совместимости с POSIX — Cygwin. |
|
Фреймворк не работает в виде «родного» приложения Win32API, его нельзя собрать или отладить с помощью средств Microsoft. |
|
Будущий релиз CppCMS 1.x.x поддерживает нативные сборки Windows без слоя совместимости POSIX, включая поддержку компилятора MSVC9. Однако, поддержка Windows — это поддержка вторичного приоритета, что сязано с сущностью CppCMS, не соответствующей «стилю разработки Micrsoft». |
Будущий релиз CppCMS 1.x.x поддерживает нативные сборки Windows без слоя совместимости POSIX, включая поддержку компилятора MSVC9. Однако, поддержка Windows — это поддержка вторичного приоритета, что связано с сущностью CppCMS, не соответствующей «стилю разработки Micrsoft». |
|
####Когда будет выпущен CppCMS 1.x.x? |
|
Надеюсь скоро. Ожидается: |
|
- Первая бета версия будет доступна в начале 2010Q3. |
- Первый стабильный релиз будет доступен в конце 2010. |
|
_Примечание:_ Ветка CppCMS 0.0.x будет поддерживаться как минимум год после релиза стабильной версии CppCMS 1.x.x. |
|
|
####Зачем откомпилированные темплейты?<br/>Почему не использовать систему интерпретации темлейтов или XSLT? |
|
Давайте начнем с истории. Первая система темплейтов CppCMS (CppCMS 0.0.1b) была интерпретируемой и динамически типизируемой. Она требовала от пользователя обеспечения некоторой склейки между используемыми ими данными и системой рендеринга. |
|
Но эта система темплейтов была отброшена в пользу статически типизируемых компилируемых темплейтов по следующим причинам: |
|
- C++ нерефлективный, статически типизируемый язык, поэтому выполнение проверок типов времени компиляции потребовал бы реализации C++ парсера, что почти невозможно. |
|
- В компилируемых темплейтах множество проверок может осуществляться самим C++ компилятором. |
|
Это очень важно для генерации HTML, потому что Модульное Тестирование пользовательских интерфейсов крайне сложно и потому статическая типизация дает значительное преимуществом, перенося большую часть тестирования в этап компиляции. |
|
- Гораздо более сложные типы данных могут поддерживаться всего лишь введением оператора `<<` над `std::ostream`. |
|
- Введение наследования темплейтов, поддержка стандартных структур данных (контейнеров), таких как list, map, hash-таблиц и даже типов определенных пользователем - становится тривиальным. |
|
Есть несколько недостатков компилируемых темплейтов: |
|
- Обновление темплейта требует перекомпиляцию и перелинковку отображения или даже самого приложения. |
- Такие обновления требуют перезапуск приложения. |
|
Первое еще не так критично, потому что при использовании темплейтов, компилируемых в совместно используемые объекты или dlls, время компиляции значительно сокращается и пользователю не требуется ждать долго. Например, компиляция и линковка темплейтов wikipp, занимает около 1.5 секунд. |
|
Второе относится к CppCMS 1.x.x, в котором темплейты могут автоматически перезагружаться как совместно используемые объекты отображения или dll, обновляемые без рестарта всего приложения. |
|
_Доп. примечание:_ Ничто не запрещает Вам использовать любую другую систему темплейтов. Если Вы находите это удобным, можете всегда писать вывод напрямую без темплейтов. |
