Von: Marcel Weiher <marcel@metaobject.com>
Datum: Mit, 13. Feb. 2002 10:36:47 Europe/Berlin
An: "Timothy J. Wood" <tjw@omnigroup.com>
Kopie: Vince DeMarco <demarco@apple.com>, Lars Sonchocky-Helldorf
<lars.sonchocky-helldorf@hamburg.de>, cocoa-dev@lists.apple.com
Betreff: XML-Archiving (Re: nibtool question)
On Tuesday, February 12, 2002, at 11:39 PM, Timothy J. Wood wrote:
For many many years people have requested that IB store nibs in a text
file format. This is really important, but it clearly has wide
ranging impact. First off, the NSArchiver functionality needs to be
extended or replaced (I prefer replaced, really) since it doesn't
allow you to specify the name of the key you are archiving.
Check out the MPWXmlKit! It has an NSCoding compatible archiver that
does exactly this. Well, it actually differs here and there, but
usually with good reason. I haven't yet tried to (un-)archive nibs
with it.
http://www.metaobject.com/Community.html
One approach to this encoding would be to have:
<object id="0" class="MyClass" version="92">
<ivar name="someString">
<string>Some string</string>
<ivar name="someObject">
<object id="1"> ... </object>
<ivar name="anotherObject">
<object id="N"/> <!-- an object reference -->
<ivar name="anInt">
<int value="100"/>
<ivar name="aRect">
<rect x="1.0" y="1.0" width="50.0" height="50.0"/>
</object>
How about this?
<?Class name="MyClass" version="3">
<MyClass id="0">
<someString valuetype="@">Some string</someString>
<someObject valuetype="@">
<?Class name="ClassOfSomeObject" version="1">
<ClassOfSomeObject id="1">
...
</ClassOfSomeObject>
</someObject>
<anInt valuetype="i">100</anInt>
<aRect valuetype='{_NSRect={_NSPoint=ff}{_NSSize=ff}}'>{{0, 0},
{238, 44}}</aRect>
<!-- NOTE: that should definitely change! --!>
<anotherObject valuetype="@" idref="1"/>
</MyClass>
This would be what the MPWXmlKit produces.
The interesting parts:
- Object references ala the XREF spec
Yes, exactly. Always use the closes available mechanism, instead of
implementing 'on top'.
In XML data-modelling is done via the DTD/Schema, in Objective-C it is
done via classes. Therefore, classes should be matched to XML
schemas. Similarily, the element tree is matched to the object-graph
(with idrefs to get from tree to graph), and class and ivar names are
directly mapped to tag-names.
By choosing matching mechanisms wherever possible, you build a 'bridge'
from semantically rich Objective-C object graphs to the syntactic world
of XML schemas, instead of just using XML as some ASCII file format for
dumping your objects, or just using Objective-C to do syntactic-level
XML processing.
IMHO, the difference is profound, and effective ;-) If you have an
object-model, the archved XML-representation will be very close to what
a DTD-designer would have come up with. All just by implementing
NSCoding.
- Extensible DTD via some sort of method on the basic
archiver/unarchiver class that would allow you to register
archive/unarchive components for specific types
Having custom-coders that can bridge the last bits of difference has
been on my list for quite some time. Wouldn't it be great if, for
example, an NSBezierPath inside an XML-archive were coded as SVG?
Conversely, 'parsing' an SVG file would be nothing more than unarching
the appropriate objects.
With XML namespaces and a pluggable coder-architecture, such a mixed
approach should be workable.
- Polymorphic encoding/decoding method on archiver/unarchiver:
[archiver archiveValue: &myRect ofType: SomeHandleToRectEncoder]
Yes, I think.
- Some extra work would need to be done to ensure that if objects were
decoded, modified and reencoded that any objects that survived the
process would retain the same object ids (for nice source control)
Hmm, that's an interesting suggestion. You could do it by keeping the
mapping dict on decode and supplying an external mapping dict on
encode.
This would allow for generic object archiving/unarchiving via XML.
The main immediate benefits would be that palettes and nibtool
wouldn't have any interaction and we could have REAL SOURCE CONTROL OF
NIBS!
Yes, as well as for all the files generated by our applications.
Marcel
--
Marcel Weiher Metaobject Software Technologies
marcel@metaobject.com www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
cocoa-dev mailing list | cocoa-dev@lists.apple.com
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.