[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] XML format for kabc
From:       Anders Lund <anders () alweb ! dk>
Date:       2002-05-23 12:13:47
[Download RAW message or body]

On Sunday 19 May 2002 18:59, Tobias Koenig wrote:
> Hi all,
>
> at the moment I'm writing a xml format for kabc. Now my questions
> is, are there already defined tags for pim xml documents or can I
> define my own ones?
>
> Ciao,
> Tobias

About this whole tread, up to now (May 23rd.):

a) Did noone think about a db (berkerly db) backend? That seems to be what is 
comonly used for storing pim data.

b) I would like to suggest again, that we have a kind of type cast on fields. 
It could be used to generate database tables as well, apart from for 
validating, searching, filtering, providing actions etc.

I know from my very short glance at the vcard backend that that defines types. 
Would it be possible to reuse some of that functionality on the level above?

Some examples of functionality is

- filtering/searching: If the type of a field - even a costum one - is known, 
sane search options for the field could be provided. For example with a date 
type cast on the birthday, it would be easy to find contacts older than <age> 
or with birthday in <month> etc.

- actions: I wish at some point to provide a popupmenu with actions for an 
addressee, including sending email, dialling up, sending fax, visit URLs etc. 
As it is now, for example the "buissnes homne page" is a custom field, 
holding just a string, so there is no smart way to put that in a menu. Wit a 
type cast of URL all fields matching could be added to a menu easily.

-validating: up to now, field values are only validated when saved (afaik). 
With a type cast, it would be easy to provide editors with automatic 
validation, that could be checked each time a editing event is finished (or 
in the slotOk() of dialogs. It would allow validation of custom fields other 
than strings as well, which would be nice.

- display: currently, we only know how to display the standard fields. For 
other fields, the display is either hardcoded or only correct for strings.

I suggest that the Field class could have a Type property, or inherit a class 
providing a type. I don't know which would be most efficient.

-anders 
_______________________________________________
kde-pim mailing list
kde-pim@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]