I just thinked again. As I understand, Record like Mapper have no special
support for one-to-many or many-to-many relations. And lazy-loading is used
mostly in such scenarios. So maybe this code is really enough to blend
Record features with JPA's:
object name extends StringField(this,100)
@Column{val name = "my_name"}
def getName() = name.value
def setName(newVal : String) = name.set(newVal)
Or am I wrong now? And can this work with Mapper too?
Maybe an interesting thing to do as part of JPA integration effort would be
to wrap JPA query language in a typesafe API like one in Mapper. Maybe it is
far easier than to code support for JPA/Hibernate object-oriented query
features in Mapper/Record. What do you think?
On Sun, Nov 30, 2008 at 5:45 PM, 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
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
