Tobias 'tri' Richter wrote:
Hi,
if the rev306 patch doesn`t fit into the concept i'm sorry, i got it wrong. my thought was to have all vcard 2.1 fields in the contact table. i'm no longer sure about that but i thought that only these fields which i created in the contact database table are allowed in the vcard 2.1 standard. So there is no need to have more then these fields in the database or otherwise you break the vcard 2.1 standard. There is also a newer vcard 3.0 standard but this standard isn't very common and there are only a few fields which are new.
2006/8/10, Eric Stadtherr estadtherr@gmail.com:
Should rev306 be backed out then? It goes against this concept.
no problem about that - my patch was only a idea to improve the addressbook, if there are other ideas or concepts it will be great.
to make the addressbook look better even with all vcard fields in the database, it can be a option to show only these fields which are filled. And then if you edit the contact there can be a new button somewhere to view all fields. If you then fill a field which wasn't shown before (because it wasn't filled), it is shown after you saved your changes for the processed contact.
Mac or GMail users might already know what I'm talking out, others please see the attached image. I imagine a dynamic address edit form that lets the user create new input fields and address sections as he/she needs them.
My first intension was to save all data "serialized" as a vCard or Lfid string in one single database field and unpack it when needed. But I also like the suggestion of Eric having a table holding all the vCard fields and values and meanwhile I'd prefer that solution.
Once again, I hope you all understand my ideas about the design of the "new" address book. It's a bit more complex than just having one table and 50 fields to edit and that's also the reason why I haven't implemented it yet. It should be more RoundCube-like :-)
Regards, Thomas
