Hi David, Le 13 nov. 07 à 22:03, David Chisnall a écrit :
> 1) It will break Cocoa code in strange and exciting ways. > 2) It is incredibly fragile. AddressBook on OS X is expected to be > used to store various different types of data without the expectation > that it will all be displayable in the Address Book app, or > understandable by all AddressBook-using applications. The only kind > of data that can be added to the Addresses database without breaking > things are values with well-defined types stored in the framework. > > Unfortunately, I can't see a good way of fixing this without a > significant rewrite. Someone mentioned that this was going to happen > anyway, to make the system based upon CollectionKit. CollectionKit was Yen-Ju's first attempt to implement a common data model (inspired by AddressBook) which can be reused by many Object Managers. However it never supported hierachical collection (exactly like AddressBook), that's why OrganizeKit was developed. OrganizeKit also includes various improvements like NSPredicate-based search, smart groups, uuid identifiers etc. It can be considered as a tag-based FS as I discussed it in this post: <https://mail.gna.org/public/etoile-dev/2007-08/msg00088.html > So CollectionKit is going to be deprecated relatively soon. BookmarkKit based on CollectionKit should be either ditched or rewritten on top of OrganizeKit and this also holds for Addresses. OrganizeKit has been imported as CoreObject in Étoilé frameworks. Some work is needed to add transaction support as suggested by Yen-Ju: <<https://mail.gna.org/public/etoile-dev/2007-08/msg00095.html> A metamodel in the same vein than Magritte should also be added to it: <http://www.lukas-renggli.ch/smalltalk/magritte> and especially <http://www.iam.unibe.ch/~scg/Archive/Papers/Reng07aMagritte.pdf > By the way I'm going to need such metamodel to easily implement various features in EtoileUI. The most immediate use would be object editing with validation at runtime. With such metamodel, a CoreObject modeler application could be automatically with EtoileUI. Magritte does precisely that sort stuff with both Seaside and Morphix in Squeak as UI backends. Take a look at it, it's incredibly cool! I think OrganizeKit enables us to make something even better than the rough adaptive model of Magritte. If someone is interested to work on that, I have some preliminary code. Implementing Magritte in ObjC should be be quicker than in Smalltalk because EtoileUI provides some building blocks like tree transformations and Foundation offers classes like NSPredicate that avoids to reimplement many classes. The API needs some work to really blend with ObjC/GNUstep API style. Part of CoreData model descriptions may be reused or not, this has to be evaluated. > If this is still > going to happen then I won't bother. If it isn't, then I will try to > think of the best way of doing it. Better to forget about it I think. Doing a quick rewrite of AddressBook on top of CoreObject/OrganizeKit could be faster even if CoreObject API evolves a bit afterwards. If cleanly implemented, AddressView and AddressManager won't need a rewrite. Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
