OK, I realised that I could specify a CodeGenerator to ReverseMappingTool and so I am writing my own CodeGenerator.
I can do most of what I want, but one thing (currently) eludes me which I used to do in the sql2java templates, but I can not see how to do it here. When I bind a field to a screen widget, I want to be able to set the maximum length of the string (in the case of a string) so that I can stop the user entering more than the maximum number of characters (I would much rather stop him at source than put up an error message saying too big). It also means that I can set the field physical widths correctly. In sql2java I could find the SQL length of the field, and use that, but I can not seem to find that information anywhere. It is probably hidden in the FieldMetaData somewhere, but I can not spot it. Anyone familiar enough with FieldMetaData to know where I might get this kind of data. I suppose this also would allow for more general validation constraints that the DB is going to require to be reflected in the UI but for the moment the field length (for strings) would be just dandy. I want to be able to generate static fields derived from the field name (so if there was a field call customer then the generated field would be:- public static final int customer_length = 10; so that I can use them in my application. I am already generating static Property objects (given the lack of property support in the compiler yet), so this will complement this along the way. David On Wednesday 06 February 2008, Patrick Linskey wrote: > Hi, > > Neither are available currently, but both sound useful. > > For superclass specification, you'll want to change > ReverseMappingTool.java:1017 and basically copy the > 'setPackageName(String)' code (including the changes to the Flags > inner class and the usage in the run method, called from main). > > I'm not familiar with the changes you'll need for property change > support, so can't provide much help there. But again, you'll want to > add a flag to configure whether or not to generate classes with > property change support, and then presumably do something different > when generating setter method bodies. If you can post what you'd like > a simple class to look like, I might be able to provide a couple of > pointers. > > -Patrick > > On Feb 6, 2008 11:05 AM, David Goodenough > > <[EMAIL PROTECTED]> wrote: > > Craig, > > > > So do I take it that that neither of these are possible with the current > > code? > > > > David > > > > On Wednesday 06 February 2008, Craig L Russell wrote: > > > Hi David, > > > > > > I can't point you to the code offhand, but we're always looking for > > > contributions that make OpenJPA easier (or in your case even possible) > > > to use. > > > > > > Craig > > > > > > On Feb 6, 2008, at 3:04 AM, David Goodenough wrote: > > > > I recently came across OpenJpa, and it looks like it might be a good > > > > fit > > > > for my application (well actually I have a number of similar apps). > > > > I had > > > > previously looked at using Sql2Java but that is not following > > > > standards > > > > (JPA) and as a project seems to be come and go. > > > > > > > > But on first inspection there were a couple of things that I could > > > > not work out how to do, mainly with ReverseMappingTool (I have > > > > existing DBs > > > > to use). > > > > > > > > 1) I need the beans that are generated to have PropertyChange > > > > support, but I can not find an option that enables this. Although I > > > > am not using this > > > > in an EJB environment, given that EJBs are a large part of openjpa's > > > > existance this seems odd. I actually need PropertyChange support as > > > > I am > > > > using BeansBinding (JSR-296). > > > > > > > > 2) I need the ability for the generated bean to be declared as > > > > extending > > > > an existing class. > > > > > > > > Now with both of these I could go in and modify the generated source > > > > code > > > > myself, but in at least one case I have around 100 tables and the > > > > thought > > > > of this not being an automated process is not good. > > > > > > > > If neither of these are possible in the existing code, is there any > > > > objection to my adding both of these and submitting a patch? If > > > > this is > > > > the route I am to follow, can anyone point me in the right direction > > > > as to > > > > where to look for the bits of ReverseMappingTool that generate the > > > > getters and > > > > setters, and generate the class header? > > > > > > > > David > > > > > > Craig Russell > > > Architect, Sun Java Enterprise System http://java.sun.com/products/jdo > > > 408 276-5638 mailto:[EMAIL PROTECTED] > > > P.S. A good JDO? O, Gasp!
