Le 4 oct. 06 à 00:08, Yen-Ju Chen a écrit :
On 10/3/06, Quentin Mathé <[EMAIL PROTECTED]> wrote:
I'm not really sure to understand, neither I make myself very clear.
By reading your last proposal, I have the feeling you mention
BookmarkKit when in fact you think to some new framework unrelated to
bookmarks management or not restricted to?
If I understand your proposal correctly, I would say it's probably a
little bit complicated if you only consider BookmarkKit in this plan.
Having a single database by user for BookmarkKit is perfectly fine I
think.
And why not model group vs bookmarks (and other organisation aspects)
in term of relationship(s) rather than relying on an external
propertylist?… when you take in account CoreData or sqllite both have
relational support.
Do you have any particular reasons to split bookmarks storage in
several databases (one per application)?
Sorry that I didn't make it clear.
If you compare the AddressesKit and BookmarkKit,
they are doing very similar things.
Both of them has a basic record, either a contact or a bookmark.
Both the record can be store in database.
All the record can be organized in a group,
and a group can contain another group.
True.
A record can be owned by several groups too.
This organization can be display in NSOutlineView.
The only difference is the record itself, which is a object.
ok
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?
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-discuss mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-discuss
