[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-24 0:11:43
[Download RAW message or body]

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

Yes, I know. But it is a fast and efficient backend...

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

well, that is why i haven't attempted it so far.

I guess I would have a virtual base class Type with methods for validation and 
providing an editor, and then reimplement it for each type. The fields could 
own an instance of the relevant type class. Does that sound resonable?

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