Le 4 oct. 06 à 18:24, Yen-Ju Chen a écrit :
On 10/4/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
By dipping into AddressesKit, I think a possibility could be to move
some classes like ADRecord, ADSearchElement, ADMultiValue,
ADMutableMultiValue, ADGroup in a separate framework (based on
CoreData by default).
AddressesKit and BookmarkKit could then rely on this new framework by
just providing dedicated classes for their custom model/record
objects.
AddressesKit offers the possibility to add new storage source (like a
DB) with the class ADEnvelopeAddressBook, this could be helpful to
have flexible storage sources for this new framework.
Is this roughly similar to your idea?
Yeap, that's exact what I want.
And since the AddressesKit is well rewritten,
we can just borrow a lot from it.
We may not need to use CoreData for now if it is not ready.
As long as we can write the record into something,
say property list or directly into database,
it will be fine for now.
So the relationship will looks like:
Applications -> BookmartKit/AddressesKit ->
a generic kit -> CoreData (optional) -> database / property list
So the AddressesKit will be refactored under this plan.
Great, this a very good plan in my opinion.
My only grip would be about storing group relationship in property
lists, I think it's better to have them expressed in term of database
relations.
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
