Small cycling web framework?

Question

Java

I want to introduce you to my bike, which I do in my free time, so that my brain does not get fat from constantly writing boring code for enterprise applications: code.google.com/p/nop . I wrote a tutorial on the framework: the first and second parts. In the process of writing a wiki engine based on the framework: code.google.com/p/xthl . I would like to know if anyone is interested in the project? If someone who would experience the same perverse fun that I did when coding for the sake of the process itself, and it does not matter that nothing fundamentally new is created? And in general, will some of the components of the project be of interest in themselves, such as a JSON-based RMI analogue, a database migrator, and a LinQ-like DSL for Java?

Answer 1

Judgment on the pluses for the question, someone was interested in this topic. But I would like to get not pluses, but feedback. I generally want to hear people's opinions, to discuss.

Answer 2

Looks very cool. I understand you have implemented DI? It is very similar to Google Guice. At the same time, there is no normal web framework in the juice itself, but this is a bit not what we would like. Do not want to make your library as an extension to Juice?
Another question: what is the use of typing template parameters? Somehow there is a validation regarding the correspondence of properties in the interface and placeholders in the template? If it is not there, then there is no special point in typing, it could be done just like in Spring MVC: type view.add("title", title), i.e. through the string value of the fieldholder.
And another question. How componentized is your framework? For example, it is possible to fasten XSLT as a template engine without much torment?

Answer 3

Add a link to the demo.

Answer 4

There is no demo version. It's the same framework. What should I show on it? To expose on it an example application? Not indicative. After all, the application is outwardly uninteresting, much more interesting is how it is written. That's why I gave links to the tutorial. There will be an interesting application on top of the framework - I will definitely make a demo version. But this is a completely different project.

Answer 5

Wrote a review article on the nop.sql library, which is part of the framework. Who wants me to publish it - throw karma.

Answer 6

Looks very cool. I understand you have implemented DI? It is very similar to Google Guice. At the same time, there is no normal web framework in the juice itself, but this is a bit not what we would like. Do not want to make your library as an extension to Juice?

Yes, DI is implemented, but I looked and figured out that making your own simple DI is easier than thinking how to screw Guice. So I made my simple DI

Another question: what is the use of typing template parameters? Somehow there is a validation regarding the correspondence of properties in the interface and placeholders in the template? If it is not there, then there is no special point in typing, it could be done just like in Spring MVC: type view.add("title", title), i.e. through the string value of the fieldholder.

Yes, validation happens at the template compilation stage. All templates are compiled at application startup. The template language is statically typed. This is, as it were, one of the features of the template engine, for the sake of which I began to do it. By the way, the template itself is compiled into JVM bytecode, and typing is also taken into account inside it. There, each template is compiled into a class, and the parameters are physically represented as class fields.

And another question. How componentized is your framework? For example, it is possible to fasten XSLT as a template engine without much torment?

Well, not quite without much pain. You will need to implement your own Dispatcher. However, in future versions I will provide a mechanism for extending the DefaultDispatcher, which now renders templates in HTML. By the way, there are simpler workarounds, but they smack of crutches. For example, controller methods can return an array of bytes. No one bothers to process the XSLT template and output it to ByteArrayOutputStream. The second option is to write your own implementation of Template. You can also, on the contrary, use a template engine without a framework.
Concerning XSL. The template engine was conceived as some replacement for XSLT. XSLT transforms XML -> XML. And I had an idea to make a Bean -> XML transformation, with a similar language. Well, with reduced capabilities compared to XSLT, because the template sets the presentation, not the logic, and therefore it is impossible to endow the template engine with excessively cool features, otherwise another you-know-what-language will come out.

Answer 7

You have an interesting SQL DSL, but it seems that jooq has gone further in this matter.