Re: Embedding XSD and XSLT in App, Protocol Question
Re: Embedding XSD and XSLT in App, Protocol Question
- Subject: Re: Embedding XSD and XSLT in App, Protocol Question
- From: Sherm Pendley <email@hidden>
- Date: Fri, 7 Apr 2006 11:48:08 -0400
On Apr 6, 2006, at 11:10 PM, Rick Langschultz wrote:
I was wondering if there was an xslt engine that I could embed in
the resources folder of my app to use to process and display xml
documents located within a Document File Wrapper.
If you're targeting 10.4, it ships with libxml and libxslt already
installed. Have a look at <http://xmlsoft.org/XSLT/> for library API
docs, or you could simply use NSTask to call /usr/bin/xsltproc.
Panther ships with libxml only, and it's an older version than the
latest libxslt needs. So, if you need to support Panther, you'd have
to either find a version of libxslt that works with the built-in
libxml, or compile the latest versions of both.
Also is there a way that I can develop some sort of application
protocol much like what Mozilla uses namely chrome:// and aim uses
aim://. This would really help to uniquely identify data on the
intranet.
That proper name for that is a "URL scheme" - that's important to
know when searching the docs. :-)
The protocol is separate. For instance, the "chrome://" URL scheme is
used to associate a URL with Mozilla's "fetch chrome" function, but
it uses standard HTTP protocol. For another example, the "mailto://";
scheme is used to indicate an address that should be handled by the
default email app - but it indicates nothing about what protocol
should be used to send the email.
So anyway...
You can define the URL schemes (both custom and standard) your app
understands by adding a CFBundleURLTypes array of dictionaries to
info.plist. Details:
http://developer.apple.com/documentation/MacOSX/Conceptual/
BPRuntimeConfig/Articles/PListKeys.html
If you decide to distribute your app to the public, you should
register your URL scheme with the IETF to avoid overlapping with
other apps. The procedure for doing so is found in RFC 2718:
<http://www.ietf.org/rfc/rfc2718.txt>
Of course, you'll need to handle requests to open a URL, for instance
implementing readFromURL:ofType:error: in your NSDocument subclass.
You could let super handle "file://" URLs, and handle your custom
scheme by fetching data from the URL, then calling either
readFromFileWrapper:ofType:error: or readFromData:ofType:error:.
Your readFromFileWrapper... or readFromData... method wouldn't
necessarily even need to know whether your data came from a disk file
or over the network, although you could obviously use -setFileURL:
and -fileURL: to save and retrieve that information if you wanted to.
sherm--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden