btw. I didn't understand why you referred to "wasting memory" at runtime ? The metamodel is not required at runtime?

The primary use case for this kind of automatic CRUD app is not top-down like MDA, but bottom-up, from an existing database schema.

Probably the "wasting memory" is trivial in this case, but as I understand if you will put build time metadata to mapping it will be loaded at run time too. And I am sure you will need model for communication, prototyping, documentation, ... after you will have code generator and solve development productivity problems and start to solve model transformation problems, modeling tools, DSL, ... (probably people "disappear" for this reason, code generator solves the most trivial problem only)

So, are you volunteering to lead this? Because I don't see the value in talking about it in the open air and come to conclusions how it will perform before even the first line of code is written.

Yes I can help to develop this stuff (modeling tools is the most interesting part to develop) and I recommend to use separate model for this stuff (It is not a bad idea to use custom metamodel too, I prefer EMF).
BTW I see build time metadata size is not so trivial on real projects, ~75 MB on disk.

No, it should be based on the Hibernate meta model.

Let me outline some basic steps how we could proceed:

1. Write a new subtask for the HibernateTool Ant task, name it java2jsf, this is the controller for the transformation and it integrates into the reverse engineering stack, cfg2hbm, hbm2java.

2. To access the meta model it should create a Configuration using the POJOs and mapping metadata (so it might need hbm files as well if no AnnotationConfiguration is used).

3. From there run transformers using templates, probably adapted from the hbm2java Velocity-based transformers to output

3.a JSF HTML forms, configuration
3.b JSP pages that include the JSF forms and Hibernate Session/Query tags OR
3.c JSP pages that include the JSF forms bound to Hibernate backing beans

The power is in the templates and the quality of the produced result. Before any of this work is started I recommend a survey of existing DB-to-Web reverse engineering tools to match their feature set as a target. It's likely we'll be able to add much more on top if the user customizes the metadata (through annotations or the HBM files) and/or templates.

I'm not interested in any MDA or EMF war stories, this should be done pragmatically or not at all.

I have some practice with this stuff, probably you will need the same metamodel for JBPM too (data flow models for example). It must be better to have "neutral" metamodel and to generate/transform all artifacts from this stuff with some tool (but hibernate metamodel can be usefull for reverse transformation).

NO!

We really have to apply some common sense here. Over-engineering is not going to get this done. Yes, it would be great if everybody would use EMF and we could generate everything from and to everything. This is the goal of MDA, as far as I understand. It has nothing to do with what I proposed in this thread: a simple CRUD application generator. For trivial things like Create, Update, Delete, and some search/find operations on maybe a dozen tables. Something that maybe is customized with a nice stylesheet, some additional validation rules, and then is used in production when any bigger solution would be overkill. To replace stupid Access applications, for example.

OK, I understand, I was very sceptical about this stuff too :)

Of course, if you are sure you can write it faster, better, and less resource intensive using some independent model, go ahead. But as long as it looks like a 5x bigger effort I don't think it is a viable option.

The tags that I wrote for Hibernate, which as Christian says lack both tests and commits, mimic the JSTL design. They are generic and simply wrap common Session functions, much as how the JSTL sql tag lib wraps standard JDBC functions. For example, there is <h:find>, <h:filter>, <h:load>, and <h:save>. I took this approach since JSTL and EL are excellent at dealing with POJOs, which of course is what you get with Hibernate.

I'm not familiar with nor very interested in JSF. From what I have seen, I think that tags or tag generation for JSF would be independent of the tags I wrote. Non-JSF JSP development does not need tags that are tied to the mapping layer, and I cannot speak to whether this is useful for JSF.

One of the challenges to my tags that we might be able to share in is how to access the SessionFactory. I don't know if JSF will provide the SessionFactory, but my tags need to be able to grab the SessionFactory from JNDI, an application context variable, ThreadLocal, and probably many other practices. And provide a default for this so you do not embed this approach in every use of the tag.

If we developed a standard convention for how to lookup and specify a session factory from within JSPs, perhaps both these generic tags and your JSF tags could benefit.

Yes, the stuff I'm interested in has more to do with getting data INTO the db, rather than being able to bring data "to the surface" w/ complex HQL, a feature that has obvious RAD possibilities for reporting apps. Compromising on SessionFactory access should not be a problem. How are your tags doing this now?

I don't work for the next three days, so I'll take a look at your stuff and work on a feature matrix of the competition.

Another idea I'm toying with is to skip the code generation and build tags that can dynamically generate the CRUD form. It's been done, but the more I look into JSF the more I see that a lot of the work is already complete ... you could probably do this with any crappy little web framework.

Some of the ideas in this thread have a tendency to get developers swept away with the possibilities. I am very interested in producing a library for small to mid sized projects, w/ a small learning curve and quick ROI for users, at least in the short term.

I'm also not going to fight for a delay on a release if the CRUD side isn't ready. When the tests for your stuff are complete, we both stand to gain if we can get it out there and get feedback from users.

Dennis Byrne
907-250-8719
dennis@dbyrne.net

I'd love to help out on a project like this.

I agree that the best first step is to produce something relatively simple for small-to-mid apps, and add the bigger/more complex features later. There is a ton of potential.