С описания и скриншотов видно, что очень хороший продукт.
На Вашем месте, я бы не продавал его за копейки, а развивал бы его как опен-сурс проект или как закрытый коммерческий проект.
Спасибо. Продавать за копейки — это, конечно, последнее дело.
Закрытым коммерческим проектом мне его сложно представить, так как весь фронтэнд открыт по определению (JavaScript), а протокол взаимодействия с бэкэндом легко отследить.
Очень хочется сделать хороший открытый проект, но мало опыта...
Если планируете развивать проект как опен сурс, готовьтесь к тому что вам понадобиться _куча_ времени на его поддержку. И не факт что отдача будет от этого хорошая. Скорее всего отдачи никакой, только время потеряете, но приобритёте какой-то опыт :)
Имхо, определитесь чего бы _вы_ хотели получить в итоге от своей CMS? Конечные цели?
И уже далее решайте сами что делать.
Сейчас мне кажется что это неплохой проект для совершенствования своих навыков и хороший пункт в портфолио. Не больше.
Имхо конечно ^_^
Не факт! Отдача вполне может быть при грамотном подходе. Если продукт действительно полезный и станет популярным можно будет организовать студию и делать серъезные проекты. Кроме того можно делать коммерческие расширения и модули.
Факт.
> Если продукт действительно полезный и станет популярным
Вот я как раз по это "если" говорю. Чтобы он стал полезным и популярным нужно его развивать себе в убытов (теряем время, деньги) какое-то время.
А _если_ он не станет полезным и популярным? Разных CMS в рунете - валом, полезных и популярных не так уж и много ^_^
Админский интерфейс — да, полностью AJAX. Процессы загрузки отображаются (в ExtJS многие AJAX-инструменты есть уже готовые). С моим ADSL на 128Кбит/с работает вполне нормально.
Мне тоже было бы интересно взглянуть на демо-версию. Раньше у меня тоже был свой опен-сорсный проект - SetCMS. Может кто и слышал/видел. Забросил его по самой простой причине - не стало времени для дальнейшей разработки... Зато опыта я действительно прилично на нём получил...
а будет ли в нём мобильность? Через время уже люди будут больше сидеть через телефоны, кпк и прочее. Если смотреть как на долгосрочный нужна будеит мобильность.
Да, у них есть лицензия Open Source LGPL 3.0 и коммерческая лицензия. Если ориентироваться на продажу CMS, то можно купить лицензию на одного разработчика (289$).
На форуме ExtJS встречал много интересных применений этого фреймворка, но удачных админок не заметил.
Немножко не так. Недавно связывался с суппортом экста. Можно спокойно использовать библиотеку на условиях ЛГПЛ, если ты не пишешь подобного фреймворка, как сам экст, используя саму библиотеку. А это значит, что вам желательно указать в теле лицензии вашей системы, что частично используется ЛГПЛ и она будет распространятся на файлы экста
Скрины понравились. Возможно из этого ничего косвенно-денежного не выйдет (по крайней мере я бы в эту сторону не развивался) но опыт приобретен думаю довольно-таки хороший. Поэтому сейчас советую занятся разработкой уникальных решений, под ниши определенных рынков.
Кстати вы заметили - некоторые комментарии выше сразу определили ваше творение как "интересный, симпатичный, хороший" зная цмску только по скриншотам!! Вот это и есть маленький секрет успешных продаж - продукт должен быть отлично отрисованным, манить пользователя своим дизайном - пощупай, стяни демку! Большинство потенциальных клиентов ведь не гики, удовольствие от функционала они получают меньше чем от визуального взаимодействия с софтом. Именно поэтому огромное количество отличных програм банально не продается - кому интересен софт с дизайном времен 95 винды? Еще любят разработчики на главной странице продукта вывалить список использованных алгоритмов, технологий и прочей ненужной клиенту белиберды. А клиенту надо показать : Секси интерфейс. Зачем ему этот софт нужен. Какие проблемы он решит. Все! Остальное в документацию и хелпы.
для обычного приложения это да, вполне логично и понятно. Но тут момент спорный. Ведь это ЦМС и далеко не всегда она используется без правок в исходниках (то тут финтифлюшки не хватает, то тут лишняя, то тут она делает немного не то; и это в лучшем случае, если есть все нужные компоненты (модули и т.д.)). Следовательно потребительская часть рынка состоит не только из обычных пользователей, которым до лампочки что внутри, лишь бы оно работало...еще есть и девелоперы, которые на основе цмс уже пишут что-то свое, и вот как раз им в большинстве своем без разницы (ну за исключением случаев, когда в тз прописана гламурность и всякие красивости (в том числе и на бекенде)). Девелоперам нужна функциональность движка, его масштабируемость, понятность и уж только в последнюю очередь красивости.
Согласен. Второй абзац моего поста как раз относился к приложениям в целом. Автор показал классные скрины - пользователям понравилось, я лишь развил мысль и поддержал его в том что направление правильное :)
Сделайте проект открытым, а его поддержку возмездной. Если ЦМС удачная, с внятным, логичным и вменяемым интерфейсом, то люди к ней потянутся сами. Не все умеют программировать, создавать модули и делать шаблоны.
Красота - страшная сила, да. :) Это на счет скриншотов...
В качестве предпочтительного варианта развития я бы рекомендовал второй: "сделать то же самое, но в обратном порядке (чтобы в открытый доступ вышел уже более-менее сильный продукт)".
Я думаю, максимум, чего можно добиться с таким орудием в руках - имя. С именем - уже гораздо проще, чем с хорошим продуктом.
Имя - это известность.
А известность - это множественные факты применения этого движка. Т.е. надо привлечь внимание разработчиков (прежде всего - армии фрилансеров) к этой CMS.
Как это сделать? :)
Очевидно, что надо исходить из того, что рыба не любит клубнику (хотя Вам она, может, и нравится).
В качестве червяков, так милых сердцу любого разработчика конечного продукта, я бы обозначил:
1. Простота наполнения сайта конечным заказчиком (не конечным разработчиком, а именно - заказчиком, или его офисным планктоном). Т.е. конечный разработчик должен с легким сердцем отдать сайт на наполнение любой девочке, которая Девида Бэкхема от углового флажка не отличит.
Тут надо пояснить. Акцент надо делать именно на простоту наполнения, а не работы, скажем, с внешним видом - изменение внешнего вида в жизненном цикле сайта имеет место нечасто.
2. "Ясный стиль" архитектуры системы и собственно кода.
3. Документация на систему (для облегчения написания новых модулей).
4. Демо-ферма :)
Т.е. надо сделать так, чтобы разработчику, который возьмет эту CMS за основу своей очередной нетленки, было просто на ней заработать.
Скорее всего, очевидно, что я пишу как практик. Да, так оно и есть. :)
Если хочется поподробнее - обращайтесь в контакты.
Тоже сделал админку на extjs. CMS - ее назавать нельзя - слишком большая привязка к конкретному проекту. Наверное, у меня все покорявее будет, я скорее на пути становления как яваскрипт-программер. Для одного проекта сделал на версии 1.1 , теперь начинаю для другого на 2.0.1 делать. Конечно, хотелось бы глянуть ваши исходники :)
ИМХО, лучший вариант, это развивать opensource проект. И вам глядишь кто-то что-то подскажет и люди поучаться. Хотя если есть предложения по покупке проекта...
Хм, я тоже подумываю насчет написание подобной CMS. Но дело не движется, т.к. заказчикам интереснее админка заточенная под конкретный проект. Поэтому с радостью бы воспользовался вашими наработками.
Ну тут есть всётаки реальный вариант сделать опенсорс движок и ещё денег на этом собирать. Думаю стоит проследить путь таких движков как WordPress например или SugarCRM.. ещё чего нить сходу в голову не пришло...
Полностью согласен. На данный момент для меня XSLT тоже не удобен, работал с ним очень мало. Но он позволяет сделать очень правильную реализацию универсальных шаблонов, без придумывания велосипеда.
Расскажите как "понять" то что "переменные" нельзя изменять, а конструкция "else" отсутствует. Я уже не говорю про простейшие циклы методом рекурсии и прочие прелести. Кое-что конечно фиксится расширениями и примочками, но это еще больше всё запутывает.
А зачем в нем нужна рекурсия, сложные логические конструкции и «прочие прелести»? Для преобразования данных из XML формата в страницу сайта его вполне хватает.
К примеру, задача рекурсивного построения дерева сайта должна решаться не в XSL, а до его применения.
Единственное с чем соглашусь — возможность изменить переменную была бы все-таки не лишней ;)
Ну например эффект зебры на списке, тут вроде как нужна какая-то проверка, причем она имеет отношение к представлению, а не к контенту. А ведь бывают и более сложные случаи.
Зебра-то как раз делается легко, проверкой остатка от деления :)
Вариант разбиения списка на несколько колонок более сложен, хотя тоже реализуем. По крайней мере, я его когда-то делал. Но тут вы правы, такие вещи в XSL делаются не так просто, как хотелось бы.
1. В XSLT переменные можно изменять, но с определенными ограничениями
2. Если Вы попали в ситуацию когда вам необходима "полноценная переменная" значит Вы не совсем поняли назначение XSLT и выносите в шаблон лишнюю логику, которая должна была отработать до трансформации.
3. Конструкция else присутствует - почитайте про
4. Рекурсия организовывается щелчком пальца - очень просто.
5. примочки плохо - согласен :) все реализовывается на pure xslt, или изначально отрабатывает до трансформации...
Я тоже так думал. Специально проверял — делал сложные шаблоны с разными условными операторами и всем, что смог придумать... И гонял его в цикле. Максимум, чего удалось добиться - 0.04 секунды на одну трансформацию. Возможно, для мегапорталов и это много, но для простых сайтов (на которые движок и ориентирован) с посещаемостью до 10000 в сутки — должно быть нормально.
DOMDocument создается модулем страницы на основе данных из БД ("ядро" предоставляет их модулю) и каких-то своих соображений.
Время генерирования DOM-документа не должно быть заметно больше времени создания HTML. Скорее — наоборот, т.к. кода меньше.
В исходниках сайта http://www.slavoniancup.org можно увидеть строчку:
<!--XSLT: 0.003 с, 0.091 с, 15:28 12.02.2008, 10 запросов-->
Это время XSLT трансформации, полное время работы, просто время и количество запросов в базу. Сайт работает на виртуальном мастерхостинге.
>Время генерирования DOM-документа не должно быть заметно больше времени создания HTML.
>Скорее — наоборот, т.к. кода меньше.
То что кода меньше ничего не значит. При формировании HTML мы используем простейшую конкатенацию ".". При формировании DOM все гораздо печальнее. Если вы меня разубедите то пойду искать ошибку в своих размышлениях.
ps. Еще хотелось бы знать объем XML данных и количество узлов
А... Мысль понял. Сейчас xml настолько простой, что формируется, фактически, тем же ".". Количество узлов чуть больше, чем количество ссылок в навигации.
Как разработчик скажу что ответить на ваши вопросы по представленным данным не возможно. Покажите хотя бы основные моменты в исходном коде. как что реализовано?
выглядит она может и ничего, но по скриншотам судить о том что с ней делать крайне не правильно. яркий пример тому битрикс, который выглядит может и хорошо но #rm -rf bitrix* для неё самый лучший вариант.
Точно. А я-то думаю, что мне скриншоты так сильно напоминают. Годик поразрабатывала под Битрикс - щас связываюсь с этим, только если ОЧЕНЬ хорошо заплатят, ибо нервотрёпки и тормозов больше чем реального дела. Ибо интерфейс должен быть не только "гламурным" - он ещё и интуитивно понятным должен быть, и по возможности - не тормозить...
Даёшь исходники в массы! Вы, кстати, фронтенд с бэкэндом перепутали, это бэкэнд построен на extjs :)
Выглядит аппетитно, но действительно нужно посмотреть как оно устроено. Устроить i18n, написать немного документации для начала, расписать features, сделать красивое демо - наверняка начнёт строиться комьюнити, которое само же будет развивать проект, отлавливать и править баги. А там, наверное, и до какого-никакого заработка недалеко.
Касаемо фронтэнда и бэкенда - это по-разному разграничить можно. Да, на уровне сайта админка - это бэкенд, а то, что отдаётся юзеру - фронтенд. Но если смотреть уровни развёртывания системы, то ядро на Парсере - это бэкенд, а клиентская часть в браузере - фронтенд.
У меня похожая разработка по идеологии и по ситуации.
Я буду в opensource выходить, как только пойму что все созрело, и вам советую. Все равно надежно защитить свой программный продукт такого типа невозможно по сути.
я не про оформление и в принципе не про технологию XML/XSLT.
Я глянул на шаблоны и так понял что для каждой страницы формируется свой xslt документ. Как в принципе устроено формирование страницы в движке?
XML создается модулем страницы на основе данных из БД ("ядро" предоставляет их модулю) и каких-то своих соображений. Дальше происходит xslt-преобразование. Всё. Для каждой страницы формируется отдельный документ.
По опыту написания своей цмски могу сказать, что это действительно занятие скорее для опыта, чем для денег. Вернее деньги на этом можно зарабатывать, но только упрощая себе же разработку заказных проектов. Коробочная версия именно в виде самостоятельного продукта - это гемор нереальный с поддержкой и всеми прочими вытекающими, не говоря уже о затратах на нормальный маркетинг и т.п.
Я свою штуковину так и забросил по большому счету, хотя она вполне жизнеспособна и прекрасно себя чувствует на ряде проектов, хотя и писана давно и там есть ряд известных мне проблем (основная - работает только под ИЕ, т.к. там куча самописного корявого яваскрипта, но писать я это начал еще года 4 назад, да и проект был изначально только под себя, так что простительно).
Кстати, ее продажу я с командой нынешних коллег даже пытался поставить на поток, но ресурсов на развитие столь малобюджетного проекта - нет. Если интересно, можно глянуть тут demo.podelkin.ru. На мой взгляд, там реализовано весьма много полезных и интересных фич, которых я в свое время нигде не нашел. Собсно, от того и стал писать свой софт, хотя и амбиций по молодости было немало :)
Хелпа там, конечно, нет, но если заинтересует кого-то, могу выслать кой-какой материал, который в свое время был сделан для этих целей.
Может даже как-нить выложу это добро в открытый доступ, но за некоторые части кода мне сейчас реально стыдно, это и останавливает от сего широкого жеста :)
Действительно, было бы очень интересно посмотреть на исходники этого дела. Сам недавно задумывался над разработкой CMS именно по такому принципу, пользователю - редактирование, программистам - настройка всего остального. Можно было бы скооперироваться, т.е. если оно станет опен-сорсом и вполне подходящим для использования - дописывать вместе с комьюнити, при этом никто не мешает получать деньги с разработки конкретных экземпляров сайтов (насколько я понимаю, та же GPL это вполне допускает).
Кстати, подскажите, у вас на скриншотах редактирование хтмл-я с подсветкой синтаксиса, чем такое делается?
ExtJS.. интересная штука. Сама недавно познакомилась с этим делом - нравится. Но не для CMS она ИМХО создана, а для серьёзных бизнес-приложений. Для банального управления контентом куда лучше пойдут простые AJAX-фреймвоки вроде mootools или JQuery - маленькие, шустренькие, непритязательные. А Ext... ну из разряда "из пушки по воробьям". Учебные примеры поразительны, да. На Ext впору писать свой Gmail... а CMS-ка ИМХО должна быть шустренькой и нетяжеловесной (привет MODx). Как говорится - "шашечки или ехать"...
Позволю себе не согласиться. ИМХО, самое явственно проглядывающееся применение для Ext, ввиду его тяжеловесности - это подобные описанному в посте backoffice'ы. Пишутся сравнительно легко и быстро, отдаются долго и тормозят - ну и фиг с ним, это же не тыще мильонов пользователей на дню показывать, а человеку, который сайт админит. А админку на Ext'е написать и не очень сложно, и выйдет она наверняка хорошо, что и показано нам в данном посте. Автору - определенно респект.
open-source и исходники в массы :)
Дорабатывать cms начну сразу же, как получу исходники. Потому что как раз сейчас собирался небольшой проект с использованием ExtJS делать.
Tiny MCE мне меньше нравится. FCKeditor выбрал, почитав их планы на будущее.
Изначально хотел использовать что-то из разряда WYSIWYM, например, WYMeditor.
Админка — не редкость, но хороших работающих проектов сделать еще просто не успели, видимо...
На внешний вид интересна, но как эта админка будет работать не на мало страничных "корпоративных" сайтах а на порталах с десятками тысяч разных статей, объявлений и других сервисов?
У меня лично слева "куча куча кнопочек", нажимаете - появляется чуть правее еще "ну очень много кнопочек"
И вся красота.. ф трубу :(
Правда люди ценят мою админку за простоту.
очень и очень симпатично. продолжай развивать, никого не слушай.
у тебя специфика такая, что код и так во многом открыт, так что я бы делал opensource-продукт.
ну а как быть - решать только тебе. :) желаю удачи и новых релизов.
ЗЫ. да, а название все же смени...)
Хм. Да. Скриншоты впечатляют. Меня, далекого от дизайна человека. Вообще, сделайте несколько сайтов при помощи админки, продайте сайты. Создайте сообщество пользователей, даже небольшое поможет. Распространяйте свободно. Может имеет смысл брать деньги только за консультации (не обновление, а консультации).
Успехов.
По поводу дизайна... Не знаю, но меня не поразило сильно, ибо уже видел эту тему, только без такого количества иконок :)
Тема для EXT 2.x SlateTheme (http://extjs.com/learn/Extension:SlateTheme)
как то мне вообще идея управления сайта пользователем собственноручно не нравится. Как бы не пыжились разработчики - но хорошего получается мало.
Однако это может просто потому что я совсем такими проектами не занимался - везде поддержка осуществляется за денешку и постоянно (в 99% - собственные сотрудники).
Самому понятна это "идея" так как сам сделал уже (95% готовности) CMS.
По прочитанному и увиденному скажу.
1. Не с того начали писать CMS.
Обьясню. Красивый backend - это не cms еще. Надо было начинать с АРХИТЕКТУРЫ.
2. Привязка к XSLT. Думаю многие не поймут... итог cms обречена в узконаправленность. Избавление - читай п.1
3. OS - идея хороша. Как писал NLS. donation + платная поддержка при хорошей cms дадут заработать как денег так и имя + ко всему этому платный функционал на заказ от "разработчика" (и-нет магазины, модули и т п). В итоге на хлеб с маслом хватит + и на варенье.
4. Что надо... чтобы п.3 реализовать.
1. Отличная архитектура (гибкая и не зацикленная на одном стандарте)
2. Кроссбраузерность
3. ExtJS - опять же комьюнити... jquery здесь на порядок выше. + проблемы с лицензированием
Кстати мне в cms как раз бы не помешала бы такая админка :) пиши может вместе с кооперируемся. У меня cms (и самое главное архитектурно) готова.
А с Parser вы под Лебедева писали? Опять как и с XSLT и ExtJS узкозаточенность. Для хорошего OS проекта уж очень узкозаточены вы. Надо поработать над архитектурой.
Начать с БД. (ну понятное дело mysql, вот только как.. вопрос спорный. Можно реляционную, а можно уже и на иерархическую замахнуться), я бы соведовал ибд + унификация + денормализация + поинтеры
Потом архитектура MVC. Начинать с контроллера (триггера) (это как голова), потом модули (спинной мозг)
Потом фронтенд (модулем) исходя из этого. (как вы поняли ж...па) :)
Ну и ноги - админка!
А к админке в последнюю очередь приступать. Посмотрите на drupal например ... сразу видно что админку просто лень писать было (или времени нет) :)
Пока не поздно начинаем с начала... или можно подключиться к моему проекту :)
Проект весьма и весьма интересный...но насчет того что многие пишут "даешь opensource!" - напоминает крики крестьян - "Давайте всех раскулачим!!". Без обид...
В своем проекте выбрал немного другой путь - на данный момент активно создается mini-framework (только пожалуйста ненужно кричать, что уже есть Cake, Zend и иже с ними), который при удачном раскладе пойдет в массы и по ходу разрабоки вышеобозначенного на нем пишется CMS.
Одминко: CMS на ExtJS 2.0. Что с ней теперь делать?