Please check out my new framework called ExpressUI for rapidly building CRUD applications. It offers predefined UI components for handling common CRUD operations so that you can focus more on the domain layer.
Of course, you can customize certain things in the UI, like positioning input elements on a form. On the domain layer, you have full flexibility to design the entity model, using JPA/Hibernate. It also uses Spring and Maven to provide an integrated technology stack. My goal is to reduce development costs by 90% for the right kind of project.
I would greatly appreciate feedback from experts on this forum, since the framework is tightly integrated with Vaadin. I’ve put up tutorials, code and Javadoc on my website:
www.expressui.com . I’m also releasing it under a dual-license, but I’d consider giving away free commercial licenses to any company that could help me prove its value.
Feature highlights include: end-user configurable security, tabbed forms, validation, paging/sorting large result sets, nested-property binding, Maven scripts to generate database and run under Jetty, etc.
Don’t know how Juan did it, but with FormBinder and CustomField you should get that done pretty easily. I have heard that in several real projects the default Vaadin Form is ditched in complex cases and forms are built manually, which is a shame.
I’ll have to check out FormBinder. The way I did it was to remove and reattach fields to the form, whenever user changes tab. Fields themselves are cached. Other tricky Form problems solved include setting some tabs as optional (so user can add/remove them with right-mouse), nested-property binding and placing labels to the left rather than the top of input elements. You can see the code for
FormComponent .
As for Spring, I’m using Spring Core, Spring MVC and Spring Security. In my framework, most UI components are also Spring beans. So, the app developer can pretty much inject anything wherever they like. DAOs are also beans. I’ve even added a mechanism to inject Spring service beans into JPA entities (non-beans), although that might not necessarily be appropriate, depends.
Spring MVC and Security are used rather lightly. The goal here is provide a minimalist configuration for developers to embed their ExpressUI applications into larger applications in the enterprise. I figured that would likely be common, since ExpressUI is only appropriate for solving a very specific kind of problem.
However, I do want to clarify that ExpressUI is not really intended to compete head-to-head against these other solutions. ExpressUI makes a stark trade-off between UI flexibility and productivity. The idea is to offer a predefined UI design that eliminates a huge part of the development effort. So, it really comes down to whether you think this UI design meets the needs of your project. If so, then ExpressUI offers huge cost savings.
This is similar to the approach taken by portals and content-management systems, like Magnolia or Wordpress. These systems provide predefined UI structures and components, eliminating much of the complexity of UI development. ExpressUI takes this concept to CRUD applications that are database-centric by offering core UI patterns for handling various kinds of data types and entity relationships.
If the framework garners enough interest, my intent is to add things like a dashboard home page, excel export, PDF generation, table trees, etc. I really need some feedback from the community to see if this approach is worthwhile and where I should take it next. So, the more feedback, the better!
Yes, I’ve been looking at Spring Data. If I see enough confirmation from the community that it is solid, then perhaps I’ll refactor ExpressUI to use it.
However, one the best features of ExpressUI is that it handles the problem of combining paging with fetch joins. Normally, if you use these features together in Hibernate, Hibernate fetches the entire result set and pages through it in memory. You get a warning in the log that says “applying in memory.” This means that using paging and fetch joins doesn’t scale for large result sets, as it is not feasible to suck millions of records into memory.
My framework works around this problem using a pattern where the query is divided into three parts: count, fetch of IDs and fetch joined data based on IDs. I’m not sure how Spring Data deals with this problem. I can’t find any posts that confirm or deny that it handles this problem gracefully.
The paging-fetch-join problem is the same reason why I avoid using any of the JPA add-ons. I’m not sure if or how they might handle this problem. I’d be curious to do know if others on this forum have been able to page through million-record result sets using complex relational fetch joins to avoid the N+1 select problem.
BTW, another thing that is a little cheesy about Spring Data is generating queries from method names. IMO, the coolness factor of that approach doesn’t outweigh the possibility that it will confuse developers and my IDE, which is better at parsing in-line queries. Also, it seems like that approach is only suitable for simplistic queries. Anyway, I like the overall concept of Spring Data. So, I’m keeping my eye on it!