Hi,
You don't have to add JPA specific jars to your classpath at all, that is ONLY if you use the wicket-rad-jpa package.
All the form generation resides in wicket-rad-core under the org.wicketrad.propertyeditor package (PropertyEditPanel and sub-classes thereof).
What is in the JPA specific extension module only uses that and adds the JPA aspect to it, but it is by no means required or included by wicket-rad-core.
jwcarman wrote:
Well, I took a look at Wicket-RAD, but I had some concerns. When I tried to use the form generation stuff (from the example), I had to add the JPA-specific jar to my classpath to get the component class. I didn't like that. In my mind, the components should be in the "core" and they should be written against some "core" api that abstracts away the persistence technology. I've started a project called "Wicketopia" that sits on top of domdrides and does some of what I'm looking for. I haven't implemented the automatic form generation piece yet, because I want to see if we can work together (or if I can provide my own extension to Wicket-RAD). If you've got time, take a look:
http://wicketopia.sourceforge.netIn particular, take a look at my CreateEntityForm, UpdateEntityForm, and RemoveEntityLink (they're in the "wicketopia" module). I think you'll find that they're somewhat similar to what you guys have, but they're also somewhat simpler (no complex class hierarchy to deal with for one). Let me know what you think and if you think we might be able to join forces. Wicket really needs a library like we're talking about and I really want it to be slick! Thanks for taking the time to discuss ideas with me.
James