We are pleased to announce some major improvements in the Spring MVC 3 application that SpringFuse generates.
We introduce:
More details and screenshots on our blog:
Congratulations !
The scaffolding looks good, the UI is nice and clean. is it possible to modify the templates that generates code ? I believe, it supports the validations and would reverse engineer constraints from columns. How does it compare with appfuse ?
Is it possible to generate CRUD from entity, OR it needs a database only. oslo
I personally use grails, and grails scaffolding works for me.
Hello,
We reverse constraints such as not null, unique, or even in certains cases the length. Try our example, you can see in the generated entities some validation annotations.
You can change the code generation template in our commercial version (Celerio product).
Starting from entity would be nice, but we do not support it for the moment.
However, our reverse approach is quite complete and can be refined through configuration (to change the variable names, set up inheritance, etc...)
It is possible to modify the template in our commercial version, the online version allows you to do almost everything, except modifying the template and
Finally, compare to appfuse, we have less back/front-end options but we go in depth in what we do.
If it does almost the same thing as the appfuse does, why should we choose it over appfuse ? Appfuse generates CRUD very well, is opensource and hence the code generation templates and every thing can be modified, and not just code generation but is a framewok too. what are the plus for which I would use springfuse (or even commercial version?
Appfuse really does shine when you want to compare data stacks (ibatis, jpa, hibernate) and web stacks (jsf, struts, spring mvc, tapestry).
We think for the stacks we have chosen our code is always cleaner and have state of art best-practices.
We also produce front-end that leverages jsf 2, primefaces 2.2, webflow 2 etc. These technologies are essential for complex business applications. This stack is not yet supported by Appfuse.
The Appfuse generation templates are open source, that's right, but most of our users and customers do not have time to customize them by lack of expertise or just because they are busy working on producing business value.
If you choose to go the commercial route you would benefit from more packs options, have access to our templates, enjoy round trip code generation, framework updates, support etc.
A quick note on the "appfuse is a framework too", the code we generate code has zero dependency on springfuse. We think it is not our role to produce yet another framework.
Give springfuse.com a shot, and tell us what you think.
Now if someone would take this, combine it with:
* JAG (http://jag.sourceforge.net) since it's not actively developed anymore, and
* ZK's Zeta Form Builder (http://www.zkoss.org) since it's Eclipse based but they don't allow custom templates
then you'd end up with a really nice product.
Heavy gereration of boilerplate code is a clear sign that the used technologies are suboptimal. Indeed, Spring and Hibernate are over-engineered frameworks that increase the complexity of applications instead of reducing it. Code generation tries to fight the complexity symptoms but doesn't address the root cause of the problen, the underlying frameworks.
I do agree with you that code generation is in itself an expression of a problem.
Yes java is not expressive enough and yes frameworks such as hibernate and spring can be sometime complex.
But tools are not the sole reason.
If we could use a magical language, with magical tools, and magical frameworks we would still have to handle many concepts and many integration points with your business code.
Be it i18n, security, caching, transactionality, logging, repository, auditing, performance, pagination, constraints, web, scalability, frontend etc.
Developing applications would be easier, but nonetheless it would still remain complex.
Services like Springfuse help developers raise their awareness of tools, practices and frameworks.
And cherry on the cake it does it by producing working code on their domain model so they can use it right away !
Heavy gereration of boilerplate code is a clear sign that the used technologies are suboptimal. Indeed, Spring and Hibernate are over-engineered frameworks that increase the complexity of applications instead of reducing it. Code generation tries to fight the complexity symptoms but doesn't address the root cause of the problen, the underlying frameworks.
Most of my experience has been on large enterprise applications with lots of messy integration. I honeslty don't buy the "framework" as the core problem. Maybe for some things, but a blanket statement like that feels like a hammer. If a project never has to integrate with a dozen different systems, with security constraints, fault tolerance and SLA, one might be able to avoid using frameworks.
I'm not a fan of spring, but it does do certain things well. There are parts of Spring that are PITA and other parts that make life easier. If you ignore the hype about spring and use it in a practical manner, I find it works fine. The same is true of Hibernate. Hibernate does certain things well and other things not so well.
At the end of the day, they're just tools. I wouldn't use a jackhammer to brush my teeth or a tooth brush to break concrete.
Heavy gereration of boilerplate code is a clear sign that the used technologies are suboptimal. Code generation tries to fight the complexity symptoms but doesn't address the root cause of the problen, the underlying frameworks.
Well not exactly. Provision of an API means that the amount of code that an application writes is less. Experience with that API highlights that further code could be simplified, hence a second pass will reduce the code to be written even further. This is no demonstration that the "underlying framework" is the cause of the problem. It simply demonstrates that the original API (that the framework provides) didn't go far enough to cater *for the simple use-cases*. But then the original API is also catering for many other use-cases not present in such noddy examples.
