Mojave MVC vs Sitebricks

[Nikolay Georgiev]

At our company we are looking for a lightweight Java MVC framework, which integrates very well with Guice. Our finalists, as the subject suggests, are Mojave MVC and Sitebricks. Can you please tell us something more on that and give a small comparison on both frameworks. We would like to know what Mojave MVC does better then Sitebricks, and maybe what is better with Sitebricks.

Thank you.

[Luis Antunes]

Hi Nikolay,

Thanks for your inquiry. First, I'd like to say that, until now, I hadn't really looked closely at the Sitebricks framework. So, I am certainly not the best person to comment on the details of the Sitebricks framework. Nevertheless, I did have a quick read through its documentation, and I can offer some comparison between Mojave and Sitebricks:

1. Sitebricks seems to use its own templating engine, in addition to some others, such as MVEL and FreeMarker. Mojave (in version 1.0.6) uses JSP, which is more widely known. In the next release, 1.0.7, Mojave will support FreeMarker, Velocity, and Mustache, and possibly MVEL, in addition to JSP.

2. There doesn't seem to be any out-of-the-box support for asynchronous HTTP functionality in Sitebricks. Similarly, in version 1.0.6, Mojave also does not support this. However, in the upcoming 1.0.7 release, Mojave will support asynchronous HTTP through integration with the Atmosphere framework.

3. In terms of deployment, a Sitebricks app is deployed to a servlet container, as is a Mojave app. However, Sitebricks has an added dependency on guice-servlet, as it uses its GuiceFilter. This is not necessarily a disadvantage, though Mojave does try to minimize the number of dependencies it has by providing its own servlet (and in 1.0.7, its own filter as well).

4. Sitebricks allows you to configure your application either through package scanning of annotated classes or through code, declaratively. Mojave currently only supports package scanning. According to Sitebricks, this might be an issue in some environments. In practice, however, Mojave has been deployed on Google App Engine without issue, using its package scanning approach. Nevertheless, you should consider your environment when choosing between the frameworks: if your environment will not allow for package scanning, you should not go with Mojave.

5. Both Sitebricks and Mojave support building both web service- and web form-type applications. Mojave makes working with forms quite easy, through its @Model annotation, and makes file uploads easy. I couldn't determine from reading the Sitebricks documentation what support is offered for handling file uploads, though it does seem to integrate well with forms. This might be something you should investigate further if these things are important to you.

6. Sitebricks provides a web client component, whereas Mojave does not.

7. Sitebricks has support for localization, whereas Mojave does not.

8. In terms of DI, presumably resources can be injected into Sitebricks Page classes, using @Inject, as they are injectable into Mojave controllers, though I didn't see any examples in the documentation. You should look for more of examples of DI with Sitebricks if this is important to you.

9. Sitebricks seems to map URL patterns at the "Page" level (which is similar to the Mojave "Controller"), but then the methods in the Page class cannot seem to be further mapped to handle more specific URLs; in this sense, Mojave is more similar to the JAX-RS approach. Mojave views a controller and its actions in a hierarchical relationship with respect to URL mappings, whereas in Sitebricks the relationship exists at the Page-level alone. In my opinion, this approach is more restrictive in terms of how your code must be organized with respect to URL mappings. (I may be mistaken, but this is what I gathered from reading through the Sitebricks documentation.)

10. Sitebricks does not appear to be an action framework: that is, instead of defining controllers with explicit actions, one defines classes that represent pages, or embeddable portions of pages. This a little different from the typical action controller approach, as seen in frameworks such as Struts or Spring MVC, and of course, Mojave. This is not a disadvantage, but rather a conceptual difference.

11. Mojave gives you a lot of control during the server startup process, by allowing you to create init controllers, and in 1.0.7, to additionally create initializer classes. Also, servlet resources, such as the HttpServletRequest, are injectable in Mojave, giving you great control should you need it. I was not able to determine to what extent this is possible in Sitebricks. You should investigate further if these things are important to you.

12. Mojave has its own support for intercepting actions and controllers, in addition to allowing you to use Guice AOP, should you decide to take that approach. Presumably, Guice AOP can be used with Sitebricks, though you should investigate further if that is important to you.

13. Finally, I'll add that Sitebricks has been around longer, and currently has a larger user base. As it has a larger community, you have a larger user base to seek help from, should you require it. That being said, getting assistance for Mojave issues should not be a problem.

To summarize, I am not very familiar with Sitebricks, but aside from the technical differences, the biggest difference is a conceptual one: Mojave takes an action controller approach, whereas Sitebricks views an app as a collection of pages. I hope this helps you make your decision. As always, if you have any more questions, I'll be glad to answer them.

Thanks,

Luis

[Nikolay Georgiev]

Hi Luis,

thank you very much for the fast and comprehensive response. It certainly is very informative and it gives me some anchor points on how to further proceed with the comparison and evaluation of the two frameworks. I think it will be interesting for others too, because there only few MVC frameworks, which integrate well with Guice.

Keep up the good work.

Best Regards,
Nikolay