On 10/4/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
Le 4 oct. 06 à 00:08, Yen-Ju Chen a écrit :
[snip]
> In this case, we can have a single framework to handle > storage and organization of the records. > Frankly, every application using 3-panel can use this frameworks. > The group display on the left, the record on the right top, > and the content of record on the right bottom. > > And because a record is actually a object. > We can have CoreData for storage, > which uses sqlite3 database as backend. > > Otherwise, if we start writing the BookmarkKit, > I bet it wiill be very similar to AddressesKit in the end. Did you take a look at the current BookmarkKit skeleton? It's really similar to AddressBook yet a lot simpler. I agree with your concept. But I don't really understand how you plan to introduce it without refactoring AddressesKit in a more generic framework. CoreData is itself a such abstraction layer from the implementation perspective. Using CoreData would not unify API though. 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. Yen-Ju
Cheers, Quentin. -- Quentin Mathé [EMAIL PROTECTED] _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
_______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
