On Tue, 2014-04-29 at 09:50 +0200, Patrick Ohly wrote:
> On Mon, 2014-04-28 at 23:18 +0200, Lukas Zeller wrote:
> > Hi Patrick,
> > 
> > > Unfortunately I am not getting the group-tag field populated. I'm
> > > attaching my field list and profile.
> > 
> > small oversight on my and your part :-)
> > 
> > The attribute to be added to <property> is called "groupfield", not 
> > "grouptag"...
> 
> I fixed that (see attached profile + field list). It fills the GROUP_TAG
> array now, but the LABEL array only has one entry, apparently the last
> one. The array positions also don't match:
> 
> item34.URL:http\://custom.com
> item34.X-ABLabel:Custom-label
> 
> -  3 :     string GROUP_TAG       [   0, n/a,     0] : <array with 19
> elements>
>                                      -- element    0 : "item34"
> -  4 :     string LABEL           [   0,   0,     0] : <array with 1 elements>
>                                      -- element    0 : "Custom-label"
> - 34 :     string WEB             [   0,   0,     0] : <array with 19 
> elements>
>                                      -- element    0 : <unassigned>
> ...
>                                      -- element   18 : "http://custom.com";

I've stepped through TMimeDirProfileHandler::parseProperty() when
parsing a simpler example:

BEGIN:VCARD
VERSION:3.0
N:Doe;John;1;Mr.;Sr.
FN:Mr. John 1 Doe Sr.
UID:6f354d698b7ccd22
item1.URL:http\://company.com
item1.X-ABLabel:Work
item2.URL:http\://custom.com
item2.X-ABLabel:Custom-label
END:VCARD

When parsing item1.X-ABLabel:Work,
TMimeDirProfileHandler::parseProperty() immediately skips over the
parameter parsing because there is none and fieldoffsetfound was set to
true in
    fieldoffsetfound = (aPropP->nameExts==NULL); // no first pass needed at all 
w/o nameExts, just use offs=0

It then has repoffset == 0 when storing the group tag:

  // parameters are all processed by now, decision made to store data (if 
!dostore, routine exits above)
  // - store the group tag value if we have one
  if (aPropP->groupFieldID!=FID_NOT_SUPPORTED) {
    TItemField *g_fldP =  
aItem.getArrayFieldAdjusted(aPropP->groupFieldID+baseoffset,repoffset,false);
    if (g_fldP)
      g_fldP->setAsString(aGroupName,aGroupNameLen); // store the group name 
(aGroupName might be NULL, that's ok)
  }

This happens to be correct (accidentally) for item1.X-ABLabel:Work.

When repeating this for item2.X-ABLabel, the setAsString() above
overwrites "item1" with "item2" at offset 0, leading to:

-  3 :     string GROUP_TAG       [   0, n/a,     0] : <array with 2
elements>
                                     -- element    0 : "item2"
                                     -- element    1 : "item2"

The second element here came from item2.URL.

The group tag matching is buried in the parameter parsing loop. Skipping
it via the (aPropP->nameExts==NULL) is incorrect if the property has a
group name.

I'm not sure what the correct way of executing that code in this
particular case is. The following patch does not work:

diff --git a/src/sysync/mimedirprofile.cpp b/src/sysync/mimedirprofile.cpp
index 5b0ecc7..16a5aac 100644
--- a/src/sysync/mimedirprofile.cpp
+++ b/src/sysync/mimedirprofile.cpp
@@ -3835,7 +3835,7 @@ bool TMimeDirProfileHandler::parseProperty(
   encoding = enc_none; // no encoding by default
   charset = aMimeMode==mimo_standard ? chs_utf8 : fDefaultInCharset; // always 
UTF8 for real MIME-DIR (same as enclosing SyncML doc), for mimo_old depends on 
<inputcharset> remote rule option (normally UTF-8)
   nameextmap = 0; // no name extensions detected so far
-  fieldoffsetfound = (aPropP->nameExts==NULL); // no first pass needed at all 
w/o nameExts, just use offs=0
+  fieldoffsetfound = (aPropP->nameExts==NULL) && !aGroupNameLen; // no first 
pass needed at all w/o nameExts, just use offs=0, except when we have to match 
a group name
   valuelist = aPropP->valuelist; // cache flag
   // prepare storage as unprocessed value
   if (aPropP->unprocessed) {

It loops twice, but still never reaches the group name matching because
that is inside a "while (propnameextP)" loop that never gets entered.

Should that code be copied out for the simpler case of a property with
no aPropP->nameExts?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.




_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to