First, It's awesome that you've been getting into the Inspectors and WidgetBuilders! I think that's great! It sounds like you starting creating a new scaffold because there were some problems with the existing one. My question is: "Are there enough differences between the Faces scaffold and the one that you are writing, that you think they should be separate?" OR do you think we should just fix what is wrong with the existing one? (I would lean toward fixing it, and adding extension points for any places where you want things to be different :) What do you think? I'd love to help you however I can to make this happen. We usually just use Pull requests and JIRA issues to track this type of work so that everyone can stay in sync! Sound like something you're interested in? It's ok that you don't have much time - this is open source! ~Lincoln PS. Which type of database engineering did you use? Forge? How did it work for you? On Sat, Feb 11, 2012 at 10:53 PM, Thomas Frühbeck <fruehbeck(a)aon.at <mailto:fruehbeck@aon.at>> wrote: Hi Lincoln, I understand absolutely, that you didn't want to open an _impl_. It is important to know, that it's not my fault, that it's not working. I do (not) think that your faces plugin is limited: No: I am really impressed by the power of the plugin, the integration of Metawidget is a great showcase! Yes: when trying to apply Forge to an existing persistence model I was confronted with some interesting questions :) After having applied the reverse engineer to my database, I found that the legacy primary keys were not picked up by the system. At first I thought, that some minor changes to the templates and the widgets would suffice, but then I realized, that the changes would be too much distributed all over the impl. The options I reviewed so far: - redesign the DB: not so bad, but more than one project use the entities - very bad - accept the (preferred) generation of "id" strings an remap the generated ID via JPA-annotations to the physical XXID Downside: a lot of legacy code (e.g. HQL statements) to refactor, very few tests :/ - use the PK-names from legacy persistence model so I can reuse legacy code a) when importing the legacy model, the scaffold will not use my PK, but render the PK as normal fields b) when changing only the templates and some widgets, the application will break between view and bean layer The beauty of Forge is the possibility to continuously use it to develop the application. In my case it would be kind of generate-repair-use-cycle (which is not so much fun) mainly because of the primary key handling. So I decided to investigate the situation in more detail and I think that I found a kinda viable solution by implementing some changes to the inspectors, widgets, templates .... I am sure you know what I mean, you did the really big part, isn't it :-) That's where I am now and I am really grateful for the insights I got into the inner workings of this bunch of brand new technology. So I decided to start a new plugin project based on the faces scaffold as close as possible, being able to follow your development without interrupting your progress. I don't know if and when I can spend enough time to get it working. In short: after having analyzed the problem I think that the primary key handling is to be fixed. Forge is a great tool and I think it's worth spending some time on this. I have started to do so, and I would be very grateful if you could take the time and have a look at it - when it works :-) Any remarks, hints appreciated, Thomas > We intentionally block this module because there should not be direct > access to the implementation classes. I know that the current Scaffold API > is very limited, but I think that in most cases, we can add SPIs and > extension points in order to give you access to what you need. > > We can try to figure out a non-impl specific way to do this depending on > what you need. Otherwise we could consider exposing the impl, but I think > that should be a last resort. > > What is it that you are trying to access in the impl, and why? _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/forge-dev -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple" _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

when building the pages (e.g. tables) you will _have_ to write the real id in the EL-expression. This is in fact a little awkward

Many thanks for your kind words, yes you are absolutely right! I did it first differently because I used to see the real Id in the legacy UI too, bad habits are hard to come by :-) What you proposed is exactly what I just implemented, now the UI just sees only the opaque id and the BackingBean will do the rest. There is just ONE issue that bothered me: when building the pages (e.g. tables) you will _have_ to write the real id in the EL-expression. This is in fact a little awkward. When replacing the id everywhere it would be easier to maintain and understand, isn't it? I just submitted the first working version, I tested it for simple beans and oneToMany until now. Time for bed! Cheers :-) Am 12.02.2012 22:25, schrieb Richard Kennard: > In particular, I'm not clear what you are doing inside IdAwareEntityWidgetBuilder. Won't your changes result in the Id field being visible in the UI > (albeit as a link)? I'm not sure we would want this. _______________________________________________ forge-dev mailing list forge-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/forge-dev

@reverse engineer: I had a go with the hibernate plugin, but I found, that it produces field access annotations, which I do not like. So I simply used Eclipse Hibernate tools (JBoss plugin??) to reverse engineer my database and then copied the sources into a Forge project. Works great, that's exactly what I expected from a tool like Forge :-))

@reverse engineer: I had a go with the hibernate plugin, but I found, that it produces field access annotations, which I do not like. So I simply used Eclipse Hibernate tools (JBoss plugin??) to reverse engineer my database and then copied the sources into a Forge project. Works great, that's exactly what I expected from a tool like Forge :-))