[Lift] Re: WAS [Lift committers] Re: Adding JPA scaffolding to lift?

2008-11-25 Thread Viktor Klang 
yes, if we resort into using xml configt' really just a matter of providing
implmentations that work with the different JPA providers.

What doyou think Derek?

On Tue, Nov 25, 2008 at 10:12 PM, Derek Chen-Becker
[EMAIL PROTECTED]wrote:

 That's a very interesting idea. It's been a long time since I've touched
 the XML mappings, but JPA definitely supports a newer version of it now. Let
 me look into that.
 Derek


 On Tue, Nov 25, 2008 at 2:55 PM, David Pollak 
 [EMAIL PROTECTED] wrote:



 On Tue, Nov 25, 2008 at 12:35 PM, Derek Chen-Becker 
 [EMAIL PROTECTED] wrote:

 I'll look at PropertyAccessor, but I would prefer something that isn't
 Hibernate specific.


 I agree that Hiberate specific stuff may be less than optimal.

 Is there a way that we can queries the models at start-up time and
 generate XML that does EJB 2.1 style mapping such that we can feed that into
 JPA to do the mapping?



 Thanks,

 Derek


 On Tue, Nov 25, 2008 at 1:24 PM, Viktor Klang [EMAIL PROTECTED]wrote:

 Derek, I still humbly suggest writing an implementation of
 PropertyAccessorhttp://www.hibernate.org/hib_docs/v3/api/org/hibernate/property/PropertyAccessor.htmlto
  map the values between JPA and the Lift business objects.

 Then, in the Hibernate-mapping or the Configuration object, just define:

 hibernate-mapping
default-cascade=none

default-access=*net.liftweb.jpa.LiftFieldAccessor* //Or something else
package=bahblah


 Cheers,
 V
 -- Forwarded message --
 From: Derek Chen-Becker [EMAIL PROTECTED]
 Date: Tue, Nov 25, 2008 at 3:54 PM
 Subject: [Lift committers] Re: Adding JPA scaffolding to lift?
 To: [EMAIL PROTECTED]


 I thought about it a bit last night. JPA infers entity members from
 either fields or getter/setter pairs. In that sense, I could create a JPA
 object like

 class MyEntity extends Record[MyEntity] {
   object nameField extends StringField(this,100)

   def name = nameField.value

   def name_=(value : String) = nameField.set(value)
 }

 But that seems a bit clunky. The other option may be to somehow come up
 with a modified Field (JPAField?) trait that can access instance fields,
 perhaps via a closure.

 Derek


 On Tue, Nov 25, 2008 at 2:42 AM, Tim Perrett [EMAIL PROTECTED]wrote:


 Hmm yeah - I wonder if record will need to be some kind of DAO for
 JPA?

 On Nov 24, 11:42 pm, Derek Chen-Becker [EMAIL PROTECTED]
 wrote:
  I'm thinking about it. I think the fact that fields on a record are
 defined
  as objects and not members may complicate things a bit, but I'm still
  digesting all of the new stuff.
 
  Derek
 
  On Mon, Nov 24, 2008 at 12:01 PM, Tim Perrett [EMAIL PROTECTED]
 wrote:
 
   How did this go Derek?
 
   Now we have the record stuff in there, are you going to take a bash
 at
   writing a JPA backend? That would rock!
 
   Cheers, Tim
 
   On Nov 13, 2:17 pm, Derek Chen-Becker [EMAIL PROTECTED]
 wrote:
Fair enough. I'll check out the Record branch and start looking
 at it.
 
Thanks,
 
Derek
 
On Thu, Nov 13, 2008 at 6:42 AM, Marius [EMAIL PROTECTED]
 wrote:
 
 +1
 
 On Nov 9, 12:56 am, David Pollak 
 [EMAIL PROTECTED]
 wrote:
  I'd rather wait until Marius and I are done with the
 record/field
   stuff
 and
  do a JPA back-end to that.
 
  On Sat, Nov 8, 2008 at 1:39 PM, TylerWeir 
 [EMAIL PROTECTED]
   wrote:
 
   We may want to also offer an archetype that has the
 skeleton of a
   JPA-
   aware app ready to go.
 
   And +1 for adding this to Lift proper.
 
   On Nov 8, 2:43 pm, Tim Perrett [EMAIL PROTECTED]
 wrote:
Sounds like a good idea Derek - this is annoying the ass
 out of
   me
right now having to copy and paste the JPA scala wrapper
 files
   from
project to project so, sure, this would be a great
 idea and
   one
welcomed by the majority of lift-jpa users.
 
+1 for including this in lift proper
 
Cheers, Tim
 
On Nov 8, 4:06 pm, Derek Chen-Becker 
 [EMAIL PROTECTED]
 wrote:
 
 I've had several requests to move the JPA.scala source
   (ScalaEntityManager
 and ScalaQuery) out of the demo site and into lift
 proper so
   that
   people can
 just extend instead of copying and pasting code. Would
 anyone
   be
   opposed to
 me making a new lift-jpa module to hold common classes?
 
 Derek
 
  --
  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







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




 



-- 
Viktor Klang
Senior Systems Analyst

--~--~-~--~~~---~--~~
You received this message because you are subscribed

[Lift] Re: WAS [Lift committers] Re: Adding JPA scaffolding to lift?

2008-11-25 Thread Viktor Klang 
On Tue, Nov 25, 2008 at 11:21 PM, Viktor Klang [EMAIL PROTECTED]wrote:

 yes, if we resort into using xml configt' really just a matter of providing
 implmentations that work with the different JPA providers.

 What doyou think Derek?


Sorry, that email turned out to get mangled.

Basically, there are a couple of good solutions available. :)



 On Tue, Nov 25, 2008 at 10:12 PM, Derek Chen-Becker [EMAIL PROTECTED]
  wrote:

 That's a very interesting idea. It's been a long time since I've touched
 the XML mappings, but JPA definitely supports a newer version of it now. Let
 me look into that.
 Derek


 On Tue, Nov 25, 2008 at 2:55 PM, David Pollak 
 [EMAIL PROTECTED] wrote:



 On Tue, Nov 25, 2008 at 12:35 PM, Derek Chen-Becker 
 [EMAIL PROTECTED] wrote:

 I'll look at PropertyAccessor, but I would prefer something that isn't
 Hibernate specific.


 I agree that Hiberate specific stuff may be less than optimal.

 Is there a way that we can queries the models at start-up time and
 generate XML that does EJB 2.1 style mapping such that we can feed that into
 JPA to do the mapping?



 Thanks,

 Derek


 On Tue, Nov 25, 2008 at 1:24 PM, Viktor Klang [EMAIL PROTECTED]wrote:

 Derek, I still humbly suggest writing an implementation of
 PropertyAccessorhttp://www.hibernate.org/hib_docs/v3/api/org/hibernate/property/PropertyAccessor.htmlto
  map the values between JPA and the Lift business objects.

 Then, in the Hibernate-mapping or the Configuration object, just
 define:

 hibernate-mapping
default-cascade=none

default-access=*net.liftweb.jpa.LiftFieldAccessor* //Or something 
 else
package=bahblah


 Cheers,
 V
 -- Forwarded message --
 From: Derek Chen-Becker [EMAIL PROTECTED]
 Date: Tue, Nov 25, 2008 at 3:54 PM
 Subject: [Lift committers] Re: Adding JPA scaffolding to lift?
 To: [EMAIL PROTECTED]


 I thought about it a bit last night. JPA infers entity members from
 either fields or getter/setter pairs. In that sense, I could create a JPA
 object like

 class MyEntity extends Record[MyEntity] {
   object nameField extends StringField(this,100)

   def name = nameField.value

   def name_=(value : String) = nameField.set(value)
 }

 But that seems a bit clunky. The other option may be to somehow come up
 with a modified Field (JPAField?) trait that can access instance fields,
 perhaps via a closure.

 Derek


 On Tue, Nov 25, 2008 at 2:42 AM, Tim Perrett [EMAIL PROTECTED]wrote:


 Hmm yeah - I wonder if record will need to be some kind of DAO for
 JPA?

 On Nov 24, 11:42 pm, Derek Chen-Becker [EMAIL PROTECTED]
 wrote:
  I'm thinking about it. I think the fact that fields on a record are
 defined
  as objects and not members may complicate things a bit, but I'm
 still
  digesting all of the new stuff.
 
  Derek
 
  On Mon, Nov 24, 2008 at 12:01 PM, Tim Perrett [EMAIL PROTECTED]
 wrote:
 
   How did this go Derek?
 
   Now we have the record stuff in there, are you going to take a
 bash at
   writing a JPA backend? That would rock!
 
   Cheers, Tim
 
   On Nov 13, 2:17 pm, Derek Chen-Becker [EMAIL PROTECTED]
 wrote:
Fair enough. I'll check out the Record branch and start looking
 at it.
 
Thanks,
 
Derek
 
On Thu, Nov 13, 2008 at 6:42 AM, Marius 
 [EMAIL PROTECTED] wrote:
 
 +1
 
 On Nov 9, 12:56 am, David Pollak 
 [EMAIL PROTECTED]
 wrote:
  I'd rather wait until Marius and I are done with the
 record/field
   stuff
 and
  do a JPA back-end to that.
 
  On Sat, Nov 8, 2008 at 1:39 PM, TylerWeir 
 [EMAIL PROTECTED]
   wrote:
 
   We may want to also offer an archetype that has the
 skeleton of a
   JPA-
   aware app ready to go.
 
   And +1 for adding this to Lift proper.
 
   On Nov 8, 2:43 pm, Tim Perrett [EMAIL PROTECTED]
 wrote:
Sounds like a good idea Derek - this is annoying the ass
 out of
   me
right now having to copy and paste the JPA scala wrapper
 files
   from
project to project so, sure, this would be a great
 idea and
   one
welcomed by the majority of lift-jpa users.
 
+1 for including this in lift proper
 
Cheers, Tim
 
On Nov 8, 4:06 pm, Derek Chen-Becker 
 [EMAIL PROTECTED]
 wrote:
 
 I've had several requests to move the JPA.scala source
   (ScalaEntityManager
 and ScalaQuery) out of the demo site and into lift
 proper so
   that
   people can
 just extend instead of copying and pasting code. Would
 anyone
   be
   opposed to
 me making a new lift-jpa module to hold common
 classes?
 
 Derek
 
  --
  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







 --
 Viktor Klang
 Senior Systems Analyst








 --
 Lift, the simply functional web framework http://liftweb.net
 Collaborative Task Management http://much4.us
 Follow me: http

[Lift] Re: WAS [Lift committers] Re: Adding JPA scaffolding to lift?

2008-11-25 Thread Derek Chen-Becker 
:) I think that we may be able to use the XML approach, but I want to check
to make sure that it's even possible to provide custom XML mappings directly
to a JPA provider. It may be something that we have do a little custom
coding for each vendor, but as long as there was a uniform interface that
wouldn't be an issue.
Derek

On Tue, Nov 25, 2008 at 4:23 PM, Viktor Klang [EMAIL PROTECTED]wrote:



 On Tue, Nov 25, 2008 at 11:21 PM, Viktor Klang [EMAIL PROTECTED]wrote:

 yes, if we resort into using xml configt' really just a matter of
 providing implmentations that work with the different JPA providers.

 What doyou think Derek?


 Sorry, that email turned out to get mangled.

 Basically, there are a couple of good solutions available. :)



 On Tue, Nov 25, 2008 at 10:12 PM, Derek Chen-Becker 
 [EMAIL PROTECTED] wrote:

 That's a very interesting idea. It's been a long time since I've touched
 the XML mappings, but JPA definitely supports a newer version of it now. Let
 me look into that.
 Derek


 On Tue, Nov 25, 2008 at 2:55 PM, David Pollak 
 [EMAIL PROTECTED] wrote:



 On Tue, Nov 25, 2008 at 12:35 PM, Derek Chen-Becker 
 [EMAIL PROTECTED] wrote:

 I'll look at PropertyAccessor, but I would prefer something that isn't
 Hibernate specific.


 I agree that Hiberate specific stuff may be less than optimal.

 Is there a way that we can queries the models at start-up time and
 generate XML that does EJB 2.1 style mapping such that we can feed that 
 into
 JPA to do the mapping?



 Thanks,

 Derek


 On Tue, Nov 25, 2008 at 1:24 PM, Viktor Klang [EMAIL PROTECTED]wrote:

 Derek, I still humbly suggest writing an implementation of
 PropertyAccessorhttp://www.hibernate.org/hib_docs/v3/api/org/hibernate/property/PropertyAccessor.htmlto
  map the values between JPA and the Lift business objects.

 Then, in the Hibernate-mapping or the Configuration object, just
 define:

 hibernate-mapping
default-cascade=none

default-access=*net.liftweb.jpa.LiftFieldAccessor* //Or something 
 else
package=bahblah


 Cheers,
 V
 -- Forwarded message --
 From: Derek Chen-Becker [EMAIL PROTECTED]
 Date: Tue, Nov 25, 2008 at 3:54 PM
 Subject: [Lift committers] Re: Adding JPA scaffolding to lift?
 To: [EMAIL PROTECTED]


 I thought about it a bit last night. JPA infers entity members from
 either fields or getter/setter pairs. In that sense, I could create a JPA
 object like

 class MyEntity extends Record[MyEntity] {
   object nameField extends StringField(this,100)

   def name = nameField.value

   def name_=(value : String) = nameField.set(value)
 }

 But that seems a bit clunky. The other option may be to somehow come
 up with a modified Field (JPAField?) trait that can access instance 
 fields,
 perhaps via a closure.

 Derek


 On Tue, Nov 25, 2008 at 2:42 AM, Tim Perrett [EMAIL PROTECTED]wrote:


 Hmm yeah - I wonder if record will need to be some kind of DAO for
 JPA?

 On Nov 24, 11:42 pm, Derek Chen-Becker [EMAIL PROTECTED]
 wrote:
  I'm thinking about it. I think the fact that fields on a record are
 defined
  as objects and not members may complicate things a bit, but I'm
 still
  digesting all of the new stuff.
 
  Derek
 
  On Mon, Nov 24, 2008 at 12:01 PM, Tim Perrett 
 [EMAIL PROTECTED] wrote:
 
   How did this go Derek?
 
   Now we have the record stuff in there, are you going to take a
 bash at
   writing a JPA backend? That would rock!
 
   Cheers, Tim
 
   On Nov 13, 2:17 pm, Derek Chen-Becker [EMAIL PROTECTED]
 wrote:
Fair enough. I'll check out the Record branch and start looking
 at it.
 
Thanks,
 
Derek
 
On Thu, Nov 13, 2008 at 6:42 AM, Marius 
 [EMAIL PROTECTED] wrote:
 
 +1
 
 On Nov 9, 12:56 am, David Pollak 
 [EMAIL PROTECTED]
 wrote:
  I'd rather wait until Marius and I are done with the
 record/field
   stuff
 and
  do a JPA back-end to that.
 
  On Sat, Nov 8, 2008 at 1:39 PM, TylerWeir 
 [EMAIL PROTECTED]
   wrote:
 
   We may want to also offer an archetype that has the
 skeleton of a
   JPA-
   aware app ready to go.
 
   And +1 for adding this to Lift proper.
 
   On Nov 8, 2:43 pm, Tim Perrett [EMAIL PROTECTED]
 wrote:
Sounds like a good idea Derek - this is annoying the
 ass out of
   me
right now having to copy and paste the JPA scala
 wrapper files
   from
project to project so, sure, this would be a great
 idea and
   one
welcomed by the majority of lift-jpa users.
 
+1 for including this in lift proper
 
Cheers, Tim
 
On Nov 8, 4:06 pm, Derek Chen-Becker 
 [EMAIL PROTECTED]
 wrote:
 
 I've had several requests to move the JPA.scala
 source
   (ScalaEntityManager
 and ScalaQuery) out of the demo site and into lift
 proper so
   that
   people can
 just extend instead of copying and pasting code.
 Would anyone
   be
   opposed to
 me making a new lift-jpa module to hold common
 classes

[Lift] Re: WAS [Lift committers] Re: Adding JPA scaffolding to lift?

2008-11-25 Thread Viktor Klang 
On Tue, Nov 25, 2008 at 11:25 PM, Derek Chen-Becker
[EMAIL PROTECTED]wrote:

 :) I think that we may be able to use the XML approach, but I want to check
 to make sure that it's even possible to provide custom XML mappings directly
 to a JPA provider. It may be something that we have do a little custom
 coding for each vendor, but as long as there was a uniform interface that
 wouldn't be an issue.


Spoken by a smart man! :)



 Derek

 On Tue, Nov 25, 2008 at 4:23 PM, Viktor Klang [EMAIL PROTECTED]wrote:



 On Tue, Nov 25, 2008 at 11:21 PM, Viktor Klang [EMAIL PROTECTED]wrote:

 yes, if we resort into using xml configt' really just a matter of
 providing implmentations that work with the different JPA providers.

 What doyou think Derek?


 Sorry, that email turned out to get mangled.

 Basically, there are a couple of good solutions available. :)



 On Tue, Nov 25, 2008 at 10:12 PM, Derek Chen-Becker 
 [EMAIL PROTECTED] wrote:

 That's a very interesting idea. It's been a long time since I've touched
 the XML mappings, but JPA definitely supports a newer version of it now. 
 Let
 me look into that.
 Derek


 On Tue, Nov 25, 2008 at 2:55 PM, David Pollak 
 [EMAIL PROTECTED] wrote:



 On Tue, Nov 25, 2008 at 12:35 PM, Derek Chen-Becker 
 [EMAIL PROTECTED] wrote:

 I'll look at PropertyAccessor, but I would prefer something that isn't
 Hibernate specific.


 I agree that Hiberate specific stuff may be less than optimal.

 Is there a way that we can queries the models at start-up time and
 generate XML that does EJB 2.1 style mapping such that we can feed that 
 into
 JPA to do the mapping?



 Thanks,

 Derek


 On Tue, Nov 25, 2008 at 1:24 PM, Viktor Klang [EMAIL PROTECTED]
  wrote:

 Derek, I still humbly suggest writing an implementation of
 PropertyAccessorhttp://www.hibernate.org/hib_docs/v3/api/org/hibernate/property/PropertyAccessor.htmlto
  map the values between JPA and the Lift business objects.

 Then, in the Hibernate-mapping or the Configuration object, just
 define:

 hibernate-mapping
default-cascade=none

default-access=*net.liftweb.jpa.LiftFieldAccessor* //Or something 
 else
package=bahblah


 Cheers,
 V
 -- Forwarded message --
 From: Derek Chen-Becker [EMAIL PROTECTED]
 Date: Tue, Nov 25, 2008 at 3:54 PM
 Subject: [Lift committers] Re: Adding JPA scaffolding to lift?
 To: [EMAIL PROTECTED]


 I thought about it a bit last night. JPA infers entity members from
 either fields or getter/setter pairs. In that sense, I could create a 
 JPA
 object like

 class MyEntity extends Record[MyEntity] {
   object nameField extends StringField(this,100)

   def name = nameField.value

   def name_=(value : String) = nameField.set(value)
 }

 But that seems a bit clunky. The other option may be to somehow come
 up with a modified Field (JPAField?) trait that can access instance 
 fields,
 perhaps via a closure.

 Derek


 On Tue, Nov 25, 2008 at 2:42 AM, Tim Perrett [EMAIL PROTECTED]wrote:


 Hmm yeah - I wonder if record will need to be some kind of DAO for
 JPA?

 On Nov 24, 11:42 pm, Derek Chen-Becker [EMAIL PROTECTED]
 wrote:
  I'm thinking about it. I think the fact that fields on a record
 are defined
  as objects and not members may complicate things a bit, but I'm
 still
  digesting all of the new stuff.
 
  Derek
 
  On Mon, Nov 24, 2008 at 12:01 PM, Tim Perrett 
 [EMAIL PROTECTED] wrote:
 
   How did this go Derek?
 
   Now we have the record stuff in there, are you going to take a
 bash at
   writing a JPA backend? That would rock!
 
   Cheers, Tim
 
   On Nov 13, 2:17 pm, Derek Chen-Becker [EMAIL PROTECTED]
 wrote:
Fair enough. I'll check out the Record branch and start
 looking at it.
 
Thanks,
 
Derek
 
On Thu, Nov 13, 2008 at 6:42 AM, Marius 
 [EMAIL PROTECTED] wrote:
 
 +1
 
 On Nov 9, 12:56 am, David Pollak 
 [EMAIL PROTECTED]
 wrote:
  I'd rather wait until Marius and I are done with the
 record/field
   stuff
 and
  do a JPA back-end to that.
 
  On Sat, Nov 8, 2008 at 1:39 PM, TylerWeir 
 [EMAIL PROTECTED]
   wrote:
 
   We may want to also offer an archetype that has the
 skeleton of a
   JPA-
   aware app ready to go.
 
   And +1 for adding this to Lift proper.
 
   On Nov 8, 2:43 pm, Tim Perrett [EMAIL PROTECTED]
 wrote:
Sounds like a good idea Derek - this is annoying the
 ass out of
   me
right now having to copy and paste the JPA scala
 wrapper files
   from
project to project so, sure, this would be a great
 idea and
   one
welcomed by the majority of lift-jpa users.
 
+1 for including this in lift proper
 
Cheers, Tim
 
On Nov 8, 4:06 pm, Derek Chen-Becker 
 [EMAIL PROTECTED]
 wrote:
 
 I've had several requests to move the JPA.scala
 source
   (ScalaEntityManager
 and ScalaQuery) out of the demo site and into lift
 proper so
   that
   people can
 just extend instead of copying