TB/AB lastModifiedDate Item -- how is it used?
gNeandr
trying to sync different addressbooks I thought the lastModifiedDate
item could be a help. But I noticed that value is always set to be "0Z".
How is that value used by TB? I noticed it's somehow altered with
PalmSync and LDAP ... but how about "normal" usage ... say a specific
contact has been change, that value will be set to the current date&time.
Any help for that?
David Bienvenu
through Edit Card.
- David
gNeandr
Yes, basically you are right, the edited changes the "internal"
lastModifiedDate, it sets that value.
But here are the situation where I'm straggling:
-- LDIF import/export LDIF ==> gives always that "0Z"
-- also the GetCardValue does the same:
var card = this.vcards[index].
QueryInterface(Components.interfaces.nsIAbCard);
var fieldValue = card.getCardValue('LastModifiedDate');
Using the following code returns the stored "lastModifiedDate" value :
this.abRdf = Components.classes["@mozilla.org/rdf/rdf-service;1"].
getService(Components.interfaces.nsIRDFService);
this.abDir = this.abRdf.GetResource(this.selectedAddressbookURI).
QueryInterface(Components.interfaces.nsIAbDirectory);
this.directory = this.abDir;
this.vcard = this.getAllAbCards(this.abDir);
var fieldValue = this.vcard[index].lastModifiedDate
Here is the point:
==> working with that "lastModifiedDate"-item has some behaviors I don't
understand.
==> what is your suggestion especially with import/export AB-data **to
include** that correct "lastModifiedDate"-value??
Guenter
Am 18.10.2006 01:20 schrieb »David Bienvenu«
Mark Banner
> @David
> Yes, basically you are right, the edited changes the "internal"
> lastModifiedDate, it sets that value.
>
> But here are the situation where I'm straggling:
> -- LDIF import/export LDIF ==> gives always that "0Z"
> -- also the GetCardValue does the same:
It looks like this bit of code may be the culprit for both these cases:
Not sure what problem it would cause with ldap as I expect that the
value could be obtained from the server, but that'd have to be checked
of course.
> Here is the point:
> ==> working with that "lastModifiedDate"-item has some behaviors I don't
> understand.
Without more information as to the problems, its hard to comment here...
> ==> what is your suggestion especially with import/export AB-data **to
> include** that correct "lastModifiedDate"-value??
I wouldn't have said its a good idea to import that value - its the
lastModifiedDate of the card in the database - ldap servers, for
example, would throw an error on that.
For export, I'd have said fixing the bit highlighted above may be enough
to do it, though it'd have to be checked for LDAP and other servers.
Standard8
gNeandr
let me give some more background why I'm looking at LDIF import/export:
mainly I'm trying to look for a solution to sync between TB/AB and
PDA-contacts (MS Mobil Window ... or what ever the name is ;)
For that I would like to compare two sets of contacts -- the TB/AB and
the PDA-contacts. For easy syncing a item like the "lastModifiedDate"
for each contact is the easiest way to **automatically** do a sync --
just skip the older one ... that's it.
For that -- doing it in TB -- it requires (at least) to import all
possible items into TB/AB. Outlook/OL Mobile is supplying a item like
that: "LastModificationTime".
... continue below ...
Am 20.10.2006 15:56 schrieb »Mark Banner«
> gNeandr wrote:
>> @David
>> Yes, basically you are right, the edited changes the "internal"
>> lastModifiedDate, it sets that value.
>>
>> But here are the situation where I'm straggling:
>> -- LDIF import/export LDIF ==> gives always that "0Z"
... with import-setting of lastModifiedDate to be always "0Z" this sync
process is not possible!
The consequence: TB has **NO** contact-import-facility to support my
requirement ? Or is there anythings else ... beside writing my own
import code?
> I wouldn't have said its a good idea to import that value - its the
> lastModifiedDate of the card in the database - ldap servers, for
> example, would throw an error on that.
... what is the direction you defining "import" ... for me it's fe.
reading a LDIF-file into TB/AB. So if that lastModifiedDate-item is
present, it should be readable by the TB-LDIF-import function!
> For export, I'd have said fixing the bit highlighted above may be enough
> to do it, though it'd have to be checked for LDAP and other servers.
For TB-LDIF-export ... with my approach ... it would be helpful to have
that --by a TB-edit/update process-- newly assigned "lastModifiedDate"
exported also, at least only to a LDIF-File.
gNeandr
Hello, let me have another try!
You pointed to
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/addrbook/src/nsAbCardProperty.cpp&rev=1.74&mark=362-366#357
.. and also for me that's the puppy that scars me.
Also with AB-internal functions the "lastModifiedDate" is set handled to
be "0Z" .. also it's internal value is a actual Date&Time one.
One example: the "Edit a card" sets it .. but fe. loading that card in
the rightHand Pane of Dir-View shows "0Z". (I have added a column
"LastDate" using the XUL-file).
Question: is there a way to have that internal "overwrite with 0Z"
disabled with the TB/ab installation? Do you have any recommendation?
Guenter
Thomas
> Hello, let me have another try!
>
> You pointed to
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/addrbook/src/nsAbCardProperty.cpp&rev=1.74&mark=362-366#357
>
> .. and also for me that's the puppy that scars me.
>
> Also with AB-internal functions the "lastModifiedDate" is set handled to
> be "0Z" .. also it's internal value is a actual Date&Time one.
> One example: the "Edit a card" sets it .. but fe. loading that card in
> the rightHand Pane of Dir-View shows "0Z". (I have added a column
> "LastDate" using the XUL-file).
>
> Question: is there a way to have that internal "overwrite with 0Z"
> disabled with the TB/ab installation? Do you have any recommendation?
>
> Guenter
Hi Guenter,
I have to say, that I'm very new to TB and it's code, so I don't have
the whole picture yet, but:
As long as the LastModifiedDate gets saved with '0', you oviously can't
get it out another value while reading. See
where (just for instance, there might be other occasions also) the '0Z'
really comes from. (But I haven't also seen, that this value would be
set in the js)
I'm UNFORTUNATELY not ready to fix such things yet (i've read something
about problems with the LDAP layer somewhere?), even IMHO the
'persistence-layer' (finally saving into *.mab, LDAP, etc.) or the
'LDAP-object' should handle such problems for itself.
BTW, to the comment in the above code ('// fix me? LDAP code gets here')
: I don't know why code of a specific 'peristence-' or
'datasource-layer' like LDAP should go into a common 'client-structure
object', but as I've said, I didn't get the whole picture yet:
Shouldn't there be just one AB - internal structure (card-object) where
the next layer - GUI as is js & XUL can fully rely on, and other objects
(implementors, sub-classes), like LDAP, VCard, etc. just translate
from/to their format (more/less fields & other field
names/formats/parent-child-relations), based on the AB - internal
structure for saving/loading/transmitting/etc.?
Thomas
gNeandr
> Hi Guenter,
>
> I have to say, that I'm very new to TB and it's code, so I don't have
> the whole picture yet, but:
>
> As long as the LastModifiedDate gets saved with '0', you oviously can't
> get it out another value while reading. See
>
> http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/mailnews/addrbook/src/nsAbCardProperty.cpp&rev=1.74&mark=624-626#619
>
>
> where (just for instance, there might be other occasions also) the '0Z'
> really comes from. (But I haven't also seen, that this value would be
> set in the js)
>
> I'm UNFORTUNATELY not ready to fix such things yet (i've read something
> about problems with the LDAP layer somewhere?), even IMHO the
> 'persistence-layer' (finally saving into *.mab, LDAP, etc.) or the
> 'LDAP-object' should handle such problems for itself.
>
> BTW, to the comment in the above code ('// fix me? LDAP code gets here')
> : I don't know why code of a specific 'peristence-' or
> 'datasource-layer' like LDAP should go into a common 'client-structure
> object', but as I've said, I didn't get the whole picture yet:
>
> Shouldn't there be just one AB - internal structure (card-object) where
> the next layer - GUI as is js & XUL can fully rely on, and other objects
> (implementors, sub-classes), like LDAP, VCard, etc. just translate
> from/to their format (more/less fields & other field
> names/formats/parent-child-relations), based on the AB - internal
> structure for saving/loading/transmitting/etc.?
>
> Thomas
Hello & special thanks to Thomas
and also a sorry from my side, because it seems I havn't looked very
deep into the code .. yet.
As I said before the AB-item "lastModifiedDate" **IS** stored internally
with it's really date&time. Reading Thomas last part I look once more
into the code and (finally) I saw the access-method to get the
card-item-values are what mixes it up:
alert ("card1.getCardValue('LastModifiedDate') :" +
card1.getCardValue('LastModifiedDate') + "\n" +
"card1.lastModifiedDate :" +
card1.lastModifiedDate );
the first gives "0Z" ...
the second "1161347385" (date&time in seconds)
That "GetCardValue" is defined here:
http://lxr.mozilla.org/mailnews/source/mailnews/addrbook/src/nsAbCardProperty.cpp#213
212
213 NS_IMETHODIMP nsAbCardProperty::GetCardValue(const char *attrname,
PRUnichar **value)
214 {
362 // XXX todo
363 // fix me? LDAP code gets here
364 PRUint32 lastModifiedDate;
365 rv = GetLastModifiedDate(&lastModifiedDate);
366 *value = ToNewUnicode(NS_LITERAL_STRING("0Z"));
367 }
see also
http://lxr.mozilla.org/mozilla1.8.0/source/mailnews/addrbook/src/nsAbCardProperty.cpp#509
A LXR cross check with "GetCardValue" gives:
http://lxr.mozilla.org/mailnews/ident?i=GetCardValue
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GetCardValue
Defined as a function in:
* mailnews/addrbook/src/nsAbCardProperty.cpp, line 213,
as member of class nsAbCardProperty
* mailnews/addrbook/src/nsAddrDatabase.cpp, line 2017,
as member of class nsAddrDatabase
* mailnews/addrbook/src/nsAbView.cpp, line 457,
as member of class nsAbView
But I can only see the "213 NS_IMETHODIMP
nsAbCardProperty::GetCardValue" set that "0Z"!
Based on that Thomas last sentence
>
>> Shouldn't there be just one AB - internal structure (card-object) where
>> the next layer - GUI as is js & XUL can fully rely on, and other objects
>> (implementors, sub-classes), like LDAP, VCard, etc. just translate
>> from/to their format (more/less fields & other field
>> names/formats/parent-child-relations), based on the AB - internal
>> structure for saving/loading/transmitting/etc.?
>>
... back to my previous question: Is there a way to get this fixed?
The request for the "lastModifiedDate"-item is:
- get the ability to display it also on any standard-GUI (Dir--listing,
card etc)
- get it im-/exportable with standard GUI-functions
- have the function "GetCardValue" to give the vaild date&time
Guenter
Thomas
Hi there,
just to explain this(!) case further:
If you create a NEW card, lastModifiedDate is set to '0', and stored as
such!
(See e.g. nsAbCardProperty::SetCardValue), BUT
if you EDIT a card, the real time value will be stored in lastModifiedDate.
See: nsAddrDatabase::EditCard, and nsAddrDatabase::InitCardFromRow.
Since at least abook.mab has no 'CreationDate' (doesn't differentiate
between creation and modification), the creation should also be seen as
a modification. IMHO, this is BUG.
To make the last sentence from my last reply more clear: This is a
really weird design! If nsAbCardProperty is the place of general card
properties, than setters as well getters have to work as expected.
Just in case of problems in e.g. LDAP:
Setting lastModifiedDate to 0 in nsAbCardProperty::SetCardValue doesn't
make any sense as long as the setter is still working!
And simply returning 0 from nsAbCardProperty::GetLastModifiedDate is not
just a very bad design, it makes the code just less read- &
maintainable! People will "code around it", just for one special case!
So please: let the properties' work as expected (what they say 'set' &
'get' value), and handle individual issues where they belong (e.g. *LDAP*).
Guenter:
When the above design-issue is clarified, (because I also wouldn't like
such constructs like your 'card1.lastModifiedDate' {"coding around",
till somebody also writes that way} ), open up a bug report, I'll help
you fixing this.
Thomas
gNeandr
will open the bug report!
Da du eine GMX Adresse hast vermute ich du bist in D?
Meine Location: Mettmann / Neandertal
gNeandr / Günter