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

List:       kde-pim
Subject:    Re: [Kde-pim] Addressee::List and AddresseeList
From:       Cornelius Schumacher <schumacher () kde ! org>
Date:       2002-12-19 14:49:06
[Download RAW message or body]

On Thursday 19 December 2002 15:17, Mirko Boehm wrote:
> <quote who="Tobias Koenig">
>
> >
> > Not yet. We have the problem that we can't create a field from a special
> > type, so we couldn't write code that explicitely sort a list by
> > formattedName or birthday.

Why would you do that? The user selects the field, not the application. 
KAddressBook doesn't have to create Field objects, it just passes the objects 
it gets from libkabc to the UI and lets the user select.

If KAddressBook explicitly works on specific fields it should use the API 
functions of Addressee to set and get the formattedName or other fields.

> > As I already suggested and Cornelius always objected, we need really an
> > identifier for each field. So we can use the identifier as argument for
> > the sortByField() method instead of a field pointer.

What's wrong with a Field pointer? Sorting by field is a generic function 
which should work on all fields. I don't see why there should be special 
exceptions for some of the fields.

> We need an identifier per field and, additionally, a data type of the
> field. Why is that? Because in future, we will need to be able to
> interchange with LDAP data, where fields are created in the way of a
> "Name" - "Data Type" - "Value" triple. The definition will be like
>    "FirstName"-"String"-"Mirko"
>    "Anniversary"-"Date"-"31.12.2000"
> An implementation using a special field class comes to mind.

Interaction with LDAP should be done in the LDAP Resource. From outside of 
libkabc there it's much better to have real C++ types, so that the compiler 
can check the code.

> So when introducing field names, we should do it right and add the data
> types - maybe with an default to string - too. And when creating that, we
> should have a look at the LDAP/LDIF specifications to make sure we will be
> compatible with this in future.

This is very true for the implementation of the LDAP Resource, but I still 
don't think it's a good idea to pass field names or types as enums or even 
strings through the public libkabc API when we can have real C++ types as it 
is done now.

> It has a number of implications, though, in the overall code, and will
> require some other changes in the long run. I think of list displays,
> printing, HTML export, etc, which all lack easy field selection and
> handling now.

What's wrong with the field selection widget/dialog we have?

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