I dont think that saving the all the field data in one vcard string is a good idea.
How about searching my contacts that live on some city, some info that is in this vcard string? It isnt good to add a field to each contact info that is available... I think that can be created 2 tables, one with the contact info type and one that has an 1-n relationship between the contacts table and tis contact info type table, where u can put the info. Then u can search freely withouth performance issues and store and extends all the contact info without having too many empty fields. Michel Moreira 2006/8/10, Eric Stadtherr <[EMAIL PROTECTED]>:
Should rev306 be backed out then? It goes against this concept. On Thu, 10 Aug 2006 10:03:06 +0200, "Thomas Bruederli" wrote: 2006/8/9, Tobias 'tri' Richter : > Hi guys, > > I found roundcubemail a few weeks ago and found it really great. I was a long > time Horde-Imp User but roundecubemail is much faster, nicer and easier. But > the first thing i miss was a "better" adressbook. > I talked about this to thomas and he pointed me to the Ticket #1332930. > > Then i have included a lot fields into the database table and made this fields > available under the adressbook. The fields i added now are all fields with are > needed for vcard 2.1 support (export and import can then be done easier). But > the problem now is, that the "right side" for each contact is a long list and > maybe not everybody needs the field "tel work 2" for example. My idea was to create a javascript driven input form that lets the user create and remove the fields he/she needs for the current address (like the Apple Address Book or Gmail does). All field data is then put together into once vCard string and saved in ONE database field. I don't like the idea of having 200 fields in the contacts table and adding one more field each week after somebody called for it. > > i will put my updates tomorrow to svn - but then i have to think about a nice > and fast solution for users that they can change what fields they what to see > for here contacts and which fields should be faded out. maybe this can be done > like the folder settings under settings or maybe there is a better solution... We should create a new branch for this and commit the changes there until we have a final solution. It seems to be a bigger task and I tend to have the trunk only for quick fixes and use branches for new feature implementations. > > i hope you can follow me - my english is not the best ;) - you can see it in > svn tomorrow. > Regards, Thomas
