It is definitely the new. I thought that it was always this way because I
observed it (I thought) before I made those changes. I just reproduced your
exact case:
val rec1 = MyMetaRecord.createRecord
val res1 = rec1.foo("zippy").fields.map(_.name)
val rec2 = new MyRecord()
val res2 = rec2.foo("zippy").fields.map(_.name)
<div>{ String.valueOf(res1) }</div> ++ <div>{ String.valueOf(res2) }</div>
Result is:
List(foo)
List(null)
So createRecord is doing the introspection. I'll start by reverting out my
change to record and see if that makes the problem go away, to narrow it down.
Do you have IM? We could cycle faster.
-Ross
On Feb 17, 2010, at 1:02 PM, Timothy Perrett wrote:
> The field in question is a subtype of:
>
> sealed abstract class TextADORField[OwnerType <: Record[OwnerType]]
> (rec: OwnerType)
> extends ADORField[OwnerType, String](rec){
> def setFromString(s: String): Box[String] = {
> dirty_?(true)
> Full(set(s))
> }
>
> def setFromAny(in: Any): Box[String] = {
> dirty_?(true)
> in match {
> case seq: Seq[_] if !seq.isEmpty => seq.map(setFromAny)(0)
> case (s: String) :: _ => Full(set(s))
> case null => Full(set(null))
> case s: String => Full(set(s))
> case Some(s: String) => Full(set(s))
> case Full(s: String) => Full(set(s))
> case None | Empty | Failure(_, _, _) => Full(set(null))
> case o => Full(this.set(o.toString))
> }
> }
>
> def defaultValue = ""
> }
>
> As you say, they should both go to setBox... Although, look at this:
>
> scala> Visitor.createRecord.fields.map(_.name)
> res25: List[String] = List(email, last_name, first_name)
>
> scala> new Visitor().fields.map(_.name)
> res27: List[String] = List(null, null, null)
>
> That never used to be the case, you used to be able to call new and
> still get the introspection.... any ideas?
>
> Cheers, Tim
>
>
> On Feb 17, 5:52 pm, Ross Mellgren <[email protected]> wrote:
>> 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
>>> 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.
