It's great to see so many people pitching in on the debate here! Let me sum
up a few points since a lot has been covered since my last post:
1. As Sasha correctly points out, just generating getters and setters
won't play nice with JPA's lazy loading, since the lazy loading would only
occur if you use the getters and setters. I completely forgot about this
aspect, and I think it's a showstopper for this approach.
2. As slick as a compiler plugin might be for making things look nice,
the more I think about it the more it feels like using a sledgehammer to
crack nuts; I agree with Kris's sentiment that it would be better to make
our solution something that's "pure Scala"
3. Marius, I really appreciate you looking into making Record/Field work
with vars/vals, but removing the objects just leaves us with the issue of
converting a field into a type that JPA knows how to handle. There would be
ways to do this, say, with Hibernate's custom types, but then that becomes
provider-specific which is something I'm really trying to avoid
4. In the same vein, I don't mind making provider-specific impls if
that's what it takes to keep this thing manageable for end users, but I
think we can do it without tying it too close
Actually, what Kris suggested with a provided getter/setter on the field is
the closest to what I came up with last night after thinking about it. What
I was thinking was that we could add an internal layer of indirection on
Field's data:
trait Field ... {
...
type Getter = () => MyType // Can this be by-name in any way?
type Setter = MyType => Unit
private[record] var internalData : MyType = _
protected var getter : Getter = { () => internalData }
protected var setter : Setter = { (newVal : MyType) => internalData = newVal
}
private[record] def data : MyType = getter()
private[record] def data_= (newVal : MyType) = setter(newVal)
...
}
Then we can have a Delegated trait:
trait Delegated [MyType,OwnerType <: Record[OwnerType]] extends
Field[MyType,OwnerType] {
def delegate (get : => MyType, set : Setter) = {
getter = () => get
setter = set
}
}
Then fields on JPA classes would be defined like
class MyEntity {
@Column{val name = "my_name"}
var name : String = _
object nameField extends StringField(this,100) with Delegated
nameField.delegate(name, name = _)
}
It's an extra line over what Kris suggested on each field definition, but it
keeps from having to expand the constructor for every field type to cover
the getters and setters. It's not the ideal solution but I think that it's
the best in terms of tradeoffs for now.
Let me also say that the level of discussion on this topic has been superb;
once again, the Lift community has show just how vibrant, informed and
involved it is :)
Derek
On Sat, Nov 29, 2008 at 2:35 AM, Marius <[EMAIL PROTECTED]> wrote:
>
> Dear all,
>
> I've been playing again for Record/Field code and tried a slightly
> different paradigm. For instance:
>
> object PersonMeta extends Person with MetaRecord[Person] {
> override def mutable_? = false
> }
>
> class Person extends Record[Person] {
>
> def meta = PersonMeta
>
> val firstName = new StringField(this, "Marius") {
> override def validators = notEmpty _ :: Nil
> }
>
> val lastName = new StringField(this, "Danciu")
>
> def notEmpty(s: String) : Can[Node] = if (s.length == 0)
> Full(Text("Field can not be empty"))
> else
> Empty
>
> }
>
> see it uses val-s (or var-s for that matter) instead of object. JPA
> dudes do you think this would help?
>
> David P. (or anyone) do you think this paradigm would be "nicer" then
> the object based one? Are there any caveats that I might miss here?
>
> P.S.
> - Very few code changed In MetarRecord lead to switch from object base
> to val/var one. (No git commits of course)
> - We could get rid of 'new' if we use companion modules or fields as
> case classes
>
> Br's,
> Marius
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Lift" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
