On Dec 1, 8: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 not sure about people hat love lift but hate maven (if there are
any) ... would we want to "force" them to love maven if they want JPA
& Record :) ?
> - 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:
>
> >> > " [EMAIL PROTECTED] 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 frameworkhttp://liftweb.net
> Collaborative Task Managementhttp://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
-~----------~----~----~----~------~----~------~--~---
