Hi Lukas, Thanks very much for the response. At first blush, I think the record listener looks like the way to go for me. I'll have a read of the other stuff too.
Cheers, Joe On Saturday, 3 May 2014 02:52:22 UTC+10, Lukas Eder wrote: > > Hello, > > (Ryan and Dan, I've put you guys on CC, because you have previously raised > similar issues. Maybe you have up-to-date ideas for Joe here) > > Yes, this issue has been previously discussed in this thread: > - https://groups.google.com/d/msg/jooq-user/BNWthTVXH7c/qCSGjWqBZwwJ > - https://github.com/jOOQ/jOOQ/issues/2721 > > And also in this one: > - https://groups.google.com/d/msg/jooq-user/tMN1n3HCDz8/xK9A2f1z9M0J > > It's never too late to re-discuss interesting topics with new points of > view :-) > > Although, unfortunately, we haven't progressed into any direction as far > as these features are concerned. Some more comments inline: > > > 2014-04-30 23:49 GMT+02:00 <[email protected] <javascript:>>: > >> Sorry if this is already solved elsewhere, but I haven't been able to >> find this here or on StackOverflow. >> >> First off, great framework! So happy to find it. >> >> I'm building a small swing GUI, and have found myself writing a lot of >> stub classes that extend Observable for the BlahRecord classes generated by >> jOOQ so I could do MVC "properly". >> >> Things like >> >> public class MyClass extends Observable >> { >> private MyClassRecord wasGeneratedByJOOQ; >> >> public void setSomeField(String newValue) >> { >> if (!newValue.equals(wasGeneratedByJOOQ.getSomeField())) >> { >> setChanged(); >> wasGeneratedByJOOQ.setSomeField(newValue); >> notifyObservers(newValue); >> } >> } >> >> ...etc for each field >> } >> >> There seem to be three ways to go about this, but I was wondering if >> someone had already just solved the whole binding issue for swing anyway. >> >> For what it's worth, the three ways I think this could be solved would be >> >> >> 1. Find the right place in the Record<> class hierarchy to make >> something extend Observable and change the definition of "setField()" in >> updatable record (this seems a poor choice, because it's classes all the >> way up to AbstractStore, which really has no business being Observable) >> >> Observable per se is probably not a good idea. This API originates from > the JDK 1.0. Today, things would be implemented quite differently. I would > tend to allow for something similar to the existing RecordListener, in > order to implement property change listener support. In fact, > RecordListener could probably be extended to accommodate such functionality. > > More details here: > > - > http://www.jooq.org/doc/latest/manual/sql-execution/crud-with-updatablerecords/crud-record-listener/ > >> >> 1. Generate something like at PoJo at the class generation time, but >> that just wraps a record-derived class for its implementation, as per the >> above code (this seems like a reasonable choice, but might be missing >> something very obvious) >> >> You can already do this. You can use the generator strategies to have > custom base classes for your POJOs: > > - > http://www.jooq.org/doc/latest/manual/code-generation/codegen-generatorstrategy/ > - > http://www.jooq.org/doc/latest/manual/code-generation/codegen-matcherstrategy/ > > And then add custom code sections to those POJOs: > > - > http://www.jooq.org/doc/latest/manual/code-generation/codegen-custom-code/ > > Of course, you could always just generate your own POJOs and throw away > those generated by jOOQ's code generator. > >> >> 1. Find out what someone who's already solved this problem would do :) >> >> Well, maybe someone else might chime in? > > Cheers > Lukas > -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
