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
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
