|
|
|
I should point out that this does not require Leopard; this works for Tiger too.
Dan Wood |
Homepage |
02.27.08 - 12:41 pm | #
|
|
thanks a lot for sharing this.
ian |
02.27.08 - 2:39 pm | #
|
|
How about an "AdditionalAttributes" entity with two attributes "key" and "value"? The main entity would have a to-many relationship to this entity.
Pierre
Pierre Bernard |
Homepage |
02.27.08 - 6:39 pm | #
|
|
I've actually been working on something very similiar, as I find the inability to have "additional properties" really annoying. This is great stuff, though, and it's likely to replace my own code.
Thanks for sharing!
August Trometer |
Homepage |
02.28.08 - 9:31 am | #
|
|
It sounds very cool and very wrong at the same time. The Apple folks should really address this. But I have to admit that I like Pierre's solution better --- if it works. It would, for example, also need a third attribute for the entity name, or for a foreign key to point back. OK, both solutions are cool and wrong at the same time. Apple!!!??
Rudy |
02.29.08 - 9:05 am | #
|
|
Yes, I am using a foreign key to link back. Thus I need one such extended attributes entity for each main entity.
Pierre Bernard |
Homepage |
02.29.08 - 11:15 am | #
|
|
@Pierre
Your suggestion is actually pretty close to what we had in Sandvox before. Ultimately either approach should work but I felt that having to maintain separate entities and objects was more hassle than it's worth. In particular, it makes undo management trickier I'd have thought. On the other hand, it should be possible to still use a fetch request with your suggestion. I'd love to see the code if you ever feel like making it public.
Mike Abdullah |
Homepage |
03.01.08 - 12:09 pm | #
|
|
@Mike
Well, my code is not actually written yet. There only exist 2 very related concepts:
1. In both HoudahGeo and HoudahSpot I have a single "MetaAttributes" entity where I stash preferences related to the document. E.g. in HoudahSpot I use this to store whether or not to auto-start a search upon opening the document. I could have used a "Document" entity, but I expect the number of such settings to grow over time. This I kept it as key/value pairs.
2. In HoudahSpot I store former values of a criterion. Say it is a "name" "contains" "string" criterion. Then you switch it to a date criterion and back to the "name" criterion, I get the old string value back. For this I have an "AttributeValues"
With HoudahGeo, I have actually hit the wall. I want to add street-level reverse geocoding but have no place to store the street name on my Image entity.
Thus I planned for an "Attributes" entity on my next project. Now I am actually considering using your method. Undo management is still a dark art to me. I'd rather not go break it for it works well in CoreData applications
Pierre
Pierre Bernard |
Homepage |
03.01.08 - 8:59 pm | #
|
|
Hi Mike,
This is great stuff!
We have already integrated KSExtensibleManagedObject into our latest project. Under what license is KSExtensibleManagedObject released? How should we credit you?
Thanks,
Peter Schols
Orbicule
Peter Schols |
Homepage |
03.27.08 - 11:39 am | #
|
|
Commenting by HaloScan
|