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 <[EMAIL PROTECTED]>: >>> 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
