Небольшой велосипедный веб-фреймворк?

Хочу представить вам свой велосипед, которым я занимаюсь в свободное время, дабы мозг не заплыл жиром от постоянного написания скучного кода для корпоративных приложений: code.google.com/p/nop. Я написал туториал по фреймворку: первая и вторая части. В процессе написание вики-движка на базе фреймворка: code.google.com/p/xthl. Хотелось бы узнать: интересен ли кому-либо проект? Если кто-то, кто испытывал бы тот же извращённый fun, что и я, при кодировании ради самого процесса, и не важно, что ничего принципиально нового не создаётся? И вообще, будут ли сами по себе интересны некоторые составные части проекта, такие как аналог RMI на основе JSON, мигратор БД и LinQ-образный DSL для Java?
  • Вопрос задан
  • 3258 просмотров
Пригласить эксперта
Ответы на вопрос 7
@konsoletyper Автор вопроса
Суда по плюсам за вопрос, кого-то заинтересовала эта тема. Но хотелось бы получить не плюсы, а фидбэк. Мне вообще хочется услышать мнение людей, подискутировать.
Ответ написан
Комментировать
@dborovikov
Выглядит очень здорово. Я так понимаю вы реализовали DI? Он очень похож на Google Guice. В то же время в самом джуйсе нету нормального веб-фреймворка но это немного не то, что хотелось бы. Не хотите сделать вашу библиотеку в виде расширения к джуйсу?

Еще вопрос: а какой есть прок от типизации параметров шаблонов? Как-то происходит валидация на предмет соответствия свойств в интерфейсе и плейсхолдеров в шаблоне? Если ее нету, то особого смысла в типизации нет, можно было бы сделать прямо как в Spring MVC: типа view.add(«title», title), т.е. через строковое значение поейсхолдера.

И еще вопрос. Насколько ваш фреймворе компонентен? К примеру можно без особых мучения прикрутить в качестве шаблонизатора XSLT?
Ответ написан
Комментировать
HarpyWar
@HarpyWar
Ссылку на демо-версию добавьте.
Ответ написан
Комментировать
@konsoletyper Автор вопроса
А нет демо-версии. Это же фреймворк. Что мне на нём демонстрировать? Выставить на нём пример приложения? Не показательно. Ведь приложение внешне неинтересное, гораздо интереснее то, как оно написано. Вот поэтому я и дал ссылки на туториал. Вот будет интересное приложение поверх фреймворка — обязательно сделаю демо-версию. Но это уже совсем-совсем другой проект.
Ответ написан
Комментировать
@konsoletyper Автор вопроса
Написал обзорную статью по библиотеке nop.sql, которая входит в состав фреймворка. Кто хочет, чтобы я её опубликовал — подкиньте кармы.
Ответ написан
Комментировать
@konsoletyper Автор вопроса
Выглядит очень здорово. Я так понимаю вы реализовали DI? Он очень похож на Google Guice. В то же время в самом джуйсе нету нормального веб-фреймворка но это немного не то, что хотелось бы. Не хотите сделать вашу библиотеку в виде расширения к джуйсу?

Да, DI реализован, но я посмотрел и прикинул, что сделать свой несложный DI проще, чем думать, как прикручивать Guice. Так что сделал свой простенький DI

Еще вопрос: а какой есть прок от типизации параметров шаблонов? Как-то происходит валидация на предмет соответствия свойств в интерфейсе и плейсхолдеров в шаблоне? Если ее нету, то особого смысла в типизации нет, можно было бы сделать прямо как в Spring MVC: типа view.add(«title», title), т.е. через строковое значение поейсхолдера.


Да, валидация происходит на этапе компиляции шаблонов. Все шаблоны компилируются при старте приложения. При этом язык шаблонов статически типизированный. Это как бы одна из фишек шаблонизатора, ради которой я его и стал делать. Кстати, шаблон сам компилируется в JVM-байткод, и внутри него так же учитывается типизация. Там каждый шаблон компилируется в класс, а параметры физически представляются в виде полей класса.

И еще вопрос. Насколько ваш фреймворе компонентен? К примеру можно без особых мучения прикрутить в качестве шаблонизатора XSLT?

Ну не то, чтобы совсем без особых мучений. Понадобится реализация своего собственного Dispatcher'а. Впрочем, в будущих версиях я предусмотрю механизм расширения DefaultDispatcher'а, который сейчас и рендерит шаблоны в HTML. Кстати, есть и более простые обходные пути, но они попахивают костылями. Например, методы контроллера могут возвращать массив байт. Никто не мешает сделать обработку XSLT-шаблона и вывод его в ByteArrayOutputStream. Второй вариант — написать свою реализацию Template. Ещё можно, наоборот, использовать у себя шаблонизатор без фреймворка.

По поводу XSLT. Шаблонизатор и был задуман как некоторая замена XSLT. XSLT преобразует XML -> XML. А у меня была идея сделать преобразование Bean -> XML, с похожим языком. Ну и с урезанными возможностями по сравнению с XSLT, ибо шаблон задаёт представление, а не логику, и потому нельзя наделять шаблонизатор чрезмерно крутыми возможностями, а то выйдет ещё один сами-знаете-какой-язык.
Ответ написан
Комментировать
asm0dey
@asm0dey
У вас интересный SQL DSL, но кажется, что jooq в этом деле зашел дальше.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы