Ticket #1332930 (Feature Requests)
roundcube at gmail.com
Fri Aug 11 13:12:13 CEST 2006
Tobias 'tri' Richter wrote:
> 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 at 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 :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4948 bytes
Desc: not available
More information about the Dev