Name should be set by introspect during the record initialization, so I'm not sure why it would matter. Also, setFromString and set should both degenerate to setBox, which should do the actual work. Can you show your setFromString implementation? Are you overriding anything other than setFromAny and setFromString in the set department?
-Ross On Feb 17, 2010, at 12:51 PM, Timothy Perrett wrote: > Not a generic one - to reproduce it you would need my custom record > implementation and access to internal work servers (neither of which I > can give out). > > I have just realised however that the "name" field is present and > correct when the field value is set: > > field.setFromString > > So it appears that its just a problem with set(<param>) ? > > Cheers, Tim > > On Feb 17, 5:46 pm, Ross Mellgren <[email protected]> wrote: >> I'm starting to look at this. Do you have a repro case? >> >> -Ross >> >> On Feb 17, 2010, at 12:41 PM, Timothy Perrett wrote: >> >> >> >>> Guys, >> >>> Something strange is happening in Lift Record now - I have production >>> work that for some reason is now not behaving the way it should. The >>> custom record implementation that I have relies on knowing the field >>> name, and for some reason, it appears to not be being set: >> >>> (where Visitor is an example implementation of my Record): >> >>> scala> new Visitor().email("dfsfdsf").fields.map(_.name) >>> TRACE - Set the value of 'null' with 'dfsfdsf' and marked as dirty. >>> (true) >> >>> I added some tracing and I see that the "def name" is always null >>> now... this is a major problem for me. My field apply method looks >>> like: >> >>> override def apply(in: FieldValueType): OwnerType = if >>> (owner.meta.mutable_?){ >>> set(in) >>> dirty_?(true) >>> Log.trace("Set the value of '"+name+"' with '"+in.toString+"' and >>> marked as dirty. ("+dirty_?.toString+")") >>> owner >>> } else { >>> owner.meta.createWithMutableField(owner, this, Box.!!(in)) >>> } >> >>> Im really not sure what has broken this, but i've not changed my code >>> other than adding the legacy check to accommodate ross' latest >>> changes. >> >>> I URGENTLY need a fix for this - we have production code relying on >>> this. >> >>> Cheers, Tim >> >>> -- >>> 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 >>> athttp://groups.google.com/group/liftweb?hl=en. > > -- > 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. > -- 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.
