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

List:       kde-pim
Subject:    Re: [Kde-pim] XML format for kabc
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-05-23 19:38:29
[Download RAW message or body]

On Thursday 23 May 2002 14:13, Anders Lund wrote:
> 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.

We discussed this a while ago, but nobody did implement it. One problem 
I see is that it gives an additional dependency and db seems to be a 
quit nasty dependency because there are several incompatible versions 
out there.

> 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.

Your examples make sense but how would this be implemented in a clean 
way? Having some type attribute and then casting to the correct type in 
big switch statements doesn't seem right. This would for example mean 
much work, when a type is added, because you have to change the code 
everywhere where the type is used.

How would you implement that code-wise?

-- 
Cornelius Schumacher <schumacher@kde.org>
_______________________________________________
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]