It's a really ugly corner that JPA paints us into here. There aren't any
vendor-neutral APIs for programmatically wiring entities up, so it's going
to have to be some sort of trickery.
On Fri, Sep 25, 2009 at 4:23 PM, Timothy Perrett <timo...@getintheloop.eu>wrote:
> Are you feeling OK david? For a moment I thought you said *runtime*
> bytecode generation?!
>
> Cheers, Tim
>
> On 25 Sep 2009, at 23:06, David Pollak wrote:
>
> I've been thinking about vomitting (I mean creating) bytecode at runtime
> that creates a mock class for Hibernate consumption.
>
> On Fri, Sep 25, 2009 at 3:01 PM, Derek Chen-Becker
> <dchenbec...@gmail.com>wrote:
>
>> I've been thinking about it in the back of my head. I may be able to get
>> something working that's vendor specific (e.g. Hibernate) by using their
>> internal API to have the Record+JPA driver wire up the entities at runtime
>> based on Record metadata. Feels kinda dirty, but if it works that would be
>> great.
>>
>> Derek
>>
>>
>> On Mon, Sep 21, 2009 at 4:29 PM, Timothy Perrett <timo...@getintheloop.eu
>> > wrote:
>>
>>>
>>> I know we've discussed this before, but ultimately we'd like to wrap
>>> JPA with a Record front end somehow...
>>>
>>> Cheers, Tim
>>>
>>> On Sep 21, 10:42 pm, David Pollak <feeder.of.the.be...@gmail.com>
>>> wrote:
>>> > On Mon, Sep 21, 2009 at 2:03 PM, glenn <gl...@exmbly.com> wrote:
>>> >
>>> > > David,
>>> >
>>> > > Does this mean you could write an entity class, like so:
>>> >
>>> > > class User(val firstName: String, val lastName: String, val userName:
>>> > > String, val email: String, val password: String) with myTrait {...}
>>> >
>>> > > and it would be useable in either a JPA or mapper or record
>>> > > implementation?
>>> >
>>> > No. Mapper/Record require a richer representation of fields than
>>> Pojos.
>>> > The reason for this can be found athttp://
>>> blog.lostlake.org/index.php?/archives/19-Keeping-the-meaning-w...
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > > That would be the ticket.
>>> >
>>> > > Glenn
>>> >
>>> > > On Sep 21, 12:47 pm, David Pollak <feeder.of.the.be...@gmail.com>
>>> > > wrote:
>>> > > > This is an impedance mis-match between POJOs (what JPA expects) and
>>> the
>>> > > > richer fields that Mapper and Record have.
>>> > > > I'm working on an interface (
>>> > >
>>> http://github.com/dpp/liftweb/blob/master/lift-util/src/main/scala/ne..
>>> .)
>>> > > > that should be a base trait on everything in Lift that's gettable
>>> or
>>> > > > gettable/settable.
>>> >
>>> > > > Then you could write a trait that looks like:
>>> >
>>> > > > trait MyThing { def name: PSettableValueHolder[String]
>>> > > > *
>>> > > > *
>>> > > > * def getName(): String = name.is*
>>> > > > * def setName(in: String) = name.set(in)*
>>> > > > *
>>> > > > *
>>> > > > * ....*
>>> >
>>> > > > }
>>> >
>>> > > > Such a trait should be able to bridge a JPA implementation and a
>>> Lift
>>> > > mapper
>>> > > > implementation.
>>> >
>>> > > > If you've got a better solution, please code it up and let's talk
>>> about
>>> > > it.
>>> >
>>> > > > On Mon, Sep 21, 2009 at 9:31 AM, glenn <gl...@exmbly.com> wrote:
>>> >
>>> > > > > Forgive me. I'm bringing up the subject of modularization in Lift
>>> > > > > under a new heading, but the last discussion was, sadly, all over
>>> the
>>> > > > > map and only served to emphasize the problem. So let me narrow it
>>> > > > > down, a bit, here, and ask:
>>> >
>>> > > > > How is it possible to create two different snippet
>>> implementations, or
>>> > > > > two different models, one JPA and one not, or one using the
>>> mapper
>>> > > > > framework and another the record, and replace one with the other
>>> > > > > without having to recompile the application?
>>> >
>>> > > > > We're not talking here about interface design - you still have to
>>> deal
>>> > > > > with boot. And traits, as has been suggested by others...well,
>>> you'd
>>> > > > > better not expose them to the world outside your implementation,
>>> as
>>> > > > > any changes would require recompilation. In other words, you
>>> can't
>>> > > > > really use traits for your interface.
>>> >
>>> > > > > To use Lift in the enterprise does require that teams be able to
>>> work
>>> > > > > independently, doesn't it.
>>> >
>>> > > > > Glenn
>>> >
>>> > > > --
>>> > > > Lift, the simply functional web frameworkhttp://liftweb.net
>>> > > > Beginning Scalahttp://www.apress.com/book/view/1430219890
>>> > > > Follow me:http://twitter.com/dpp
>>> > > > Git some:http://github.com/dpp
>>> >
>>> > --
>>> > Lift, the simply functional web frameworkhttp://liftweb.net
>>> > Beginning Scalahttp://www.apress.com/book/view/1430219890
>>> > Follow me:http://twitter.com/dpp
>>> > Git some:http://github.com/dpp
>>>
>>>
>>
>>
>>
>
>
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---
