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

Суда по плюсам за вопрос, кого-то заинтересовала эта тема. Но хотелось бы получить не плюсы, а фидбэк. Мне вообще хочется услышать мнение людей, подискутировать.

Выглядит очень здорово. Я так понимаю вы реализовали DI? Он очень похож на Google Guice. В то же время в самом джуйсе нету нормального веб-фреймворка но это немного не то, что хотелось бы. Не хотите сделать вашу библиотеку в виде расширения к джуйсу?

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

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

Ссылку на демо-версию добавьте.

А нет демо-версии. Это же фреймворк. Что мне на нём демонстрировать? Выставить на нём пример приложения? Не показательно. Ведь приложение внешне неинтересное, гораздо интереснее то, как оно написано. Вот поэтому я и дал ссылки на туториал. Вот будет интересное приложение поверх фреймворка — обязательно сделаю демо-версию. Но это уже совсем-совсем другой проект.

Написал обзорную статью по библиотеке nop.sql, которая входит в состав фреймворка. Кто хочет, чтобы я её опубликовал — подкиньте кармы.

Выглядит очень здорово. Я так понимаю вы реализовали 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, ибо шаблон задаёт представление, а не логику, и потому нельзя наделять шаблонизатор чрезмерно крутыми возможностями, а то выйдет ещё один сами-знаете-какой-язык.

У вас интересный SQL DSL, но кажется, что jooq в этом деле зашел дальше.