If you add (non-overriden) fields to a val, they'll always be invoked via
reflection, which takes a performance hit. Objects, on the other hand,
define their own class so reflection isn't necessary.
I don't expect this to be an issue in 99% of situations, but it's another
"gotcha" to be aware of.
--j
On Tue, Dec 2, 2008 at 12:07 PM, Marius <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I just committed some changes so that Record's fields are expressed as
> vals.
>
> For instance
>
> class MyRecord extends Record[MyRecord] {
>
> def meta = MyRecordMeta
>
> object firstName extends StringField(this, "John")
>
> }
>
> becomes
>
> class MyRecord extends Record[MyRecord] {
>
> def meta = MyRecordMeta
>
> val firstName = new StringField(this, "John")
>
> }
>
> ... a more "classical" approach.
>
> If there are compelling reasons to use object instead of val please
> share them with us.
>
> P.S.
>
> If you want lifecycle callbacks you can say:
>
> class MyRecord extends Record[MyRecord] with LifecycleCallbacks {
>
> def meta = MyRecordMeta
>
> val firstName = new StringField(this, "John")
>
> override def beforeValidation {
> println("Before validation")
> }
>
>
> }
>
>
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
