- I'm pretty close to having a releasable version of the maven-scala-plugin that supports compiler plugins. - Adding integration between the maven-pom and eclipse is going to take some time (but is "possible"). I'm not sure about the netbeans/IntelliJ tools, but this could be an awkward integration for all of them.
Don't know if that helps. (Personally I think compiler plugins are better for POCs). On Mon, Dec 1, 2008 at 1:22 PM, David Pollak <[EMAIL PROTECTED]>wrote: > My 2 cents: > > - I'm strongly opposed to any compiler plugins as they (1) mean that > IDEs will work less well and (2) they require some sort of installation (if > they can be rolled into the Maven building stuff, it makes this objection > go > away) > - I'm strongly opposed to mixing annotations and the Record stuff. > It'll just make for wicked ugly looking code. > > I believe there are ways to use Record's deep knowledge of class layouts to > generate data structures and/or XML to send to JPA to "do the right thing." > > > On Sun, Nov 30, 2008 at 7:45 AM, Derek Chen-Becker <[EMAIL PROTECTED]>wrote: > >> The whole point of integrating (and I use the word integrating here >> loosely) is so that there's a common form framework for people to use. >> Really, the point of Record as far as I can tell is to loosen and/or remove >> the tight coupling with the datastore, and in that sense Record is >> succeeding. As Tim points out, there are going to be people with existing >> JPA libraries and what we're trying to propose is a means for them to >> leverage their existing libraries alongside the nice work done in Record. As >> ugly as the boilerplate for delegation may seem, I don't see any better >> solution without adding significant complexity. I've done bytecode >> manipulation in the past and while it can be very handy, it makes things a >> lot more complex on the backend and I'm really trying to avoid complexity >> (this includes a compiler plugin, too). >> >> Delegation provides the cleanest approach I can come up with; it actually >> helps in the case where someone wants to use an existing JPA library because >> you could simply wrap an instance and delegate to it: >> >> class MyEntry extends Record[MyEntry] { >> var inner : RealEntry = _ >> >> object name extends StringField(this) with Delegation >> name.delegate(inner.name, inner.name = _) >> >> ... >> } >> >> By adding a few lines of boilerplate in each class you get validation, >> form generation, presentation HTML, JSON representation, etc. It's up to the >> end-user to determine whether these features are worth the cost of a few >> LoC. >> >> I'm not saying this is a perfect solution, just that I think that this is >> the best first cut at it. Also, no one is saying that people have to use JPA >> with Record. I'm assuming that the majority of new Lift apps will probably >> use Record/Mapper because they're simple, easy to use and quite capable of >> handling most data models. But for the people with existing JPA libraries, >> or for people who would like to use JPA for the additional features, >> compatibility with Java apps, etc, I'd like to have a better answer than an >> absolute "Don't use Record" or "Switch to Record". >> >> Derek >> >> >> >> On Sun, Nov 30, 2008 at 1:40 AM, Marius <[EMAIL PROTECTED]> wrote: >> >>> >>> I totally agree with you Viktor! ... although it seems like a workable >>> solution in this case a Record contains to distinct entities to >>> represent the same data and of course the boilerplate. >>> >>> It was mentioned above compiler plugins which I expressed my opinion >>> about it (I'd stay away) but there might be another way to "alter" the >>> bytecode at runtime. I'm talking about dynamic class weaving. >>> Basically it is a class loader that before returning the actual >>> updated class. Kind of what AspectJ is doing. A while ago a wrote a >>> bytecode level manipulation framework and combined with a "special" >>> classloader I was able to modify a class dynamically and use it. >>> >>> Of course there are caveats: >>> >>> 1. Complexity induced by bytecode level manipulation >>> 2. How a dynamic class loader cope with container's classloader that >>> essentially loads the web application. Of course it would delegate the >>> loading to the container's classloader but these "modifiable" classes >>> should probably not live in WEB-INF/classes or WEB-INF/lib folder. >>> >>> >>> But all in all I'm not convinced that this effort really worth it. >>> AFAIC I still don;t get the whole point of integrating Record/Field >>> with JPA. If someone wants to switch easily from JPA to Record or vice- >>> versa, to have this flexibility perhaps consider to abstract these >>> layers from the rest of the application and using other persistence >>> technologies would not affect the application "business logic" ... but >>> this is about how the appliation is designed etc. >>> >>> Br's, >>> Marius >>> >>> On Nov 30, 9:56 am, "Viktor Klang" <[EMAIL PROTECTED]> wrote: >>> > IMHO: >>> > >>> > " @Column{val name = "my_name"} >>> > var name : String = _ >>> > object nameField extends StringField(this,100) with Delegated >>> > nameField.delegate(name, name = _)" >>> > >>> > That's just too much boilerplate. For me, who went to scala to lose >>> > boilerplate, this is not a viable solution. >>> > >>> > Unfortunately the JPA spec is kind of weak when it comes to adaptation, >>> so >>> > my suggestion to make it work with Hibernate first still stands. >>> > >>> > What do you guys think? >>> > >>> > Cheers, >>> > Viktor >>> > >>> > On Sat, Nov 29, 2008 at 10:23 PM, Derek Chen-Becker >>> > <[EMAIL PROTECTED]>wrote: >>> > >>> > >>> > >>> > > No big deal. In the example code I did a by-name in the delegate >>> method so >>> > > at least it's transparent to the end-user. >>> > >>> > > Derek >>> > >>> > > On Sat, Nov 29, 2008 at 11:06 AM, Jorge Ortiz <[EMAIL PROTECTED] >>> >wrote: >>> > >>> > >> Just wanted to chime in real quick... >>> > >>> > >>> type Getter = () => MyType // Can this be by-name in any way? >>> > >>> > >> No. By-names are not first-class types. It's gotta be () => MyType >>> > >>> > >> --j >>> > >>> > -- >>> > Viktor Klang >>> > Senior Systems Analyst >>> >>> >> >> >> > > > -- > Lift, the simply functional web framework http://liftweb.net > Collaborative Task Management http://much4.us > Follow me: http://twitter.com/dpp > Git some: http://github.com/dpp > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---