3 ms·

Yeah, I've seen this several times. I don't know how they put the site together, but it doesn't sound like it would be a hard problem to solve. As weird as it

Yeah, I've seen this several times. I don't know how they put the site together, but it doesn't sound like it would be a hard problem to solve. As weird as it is on the web, it's even weirder in their developer tools. I kid you not, there are HTML files in "/Developer/Documentation/DocSets/com.apple.ADC_Reference_Library.CoreReference.docset/Contents/Resources/Documents/documentation/Cocoa/Reference/ApplicationKit/Classes/NSApplication_Class". Whereas, if they'd hired me to do it, I would have probably called it "/Developer/Documentation/Cocoa".

illumen 17y ago
Indeed. They need someone to go through and give nice urls to all of their documents. Also be good for someone at 1 infinite loop to get a list of all the old urls, and map them to the new urls. Probably not a hard task for their web team.
Zev 17y ago
While absurdly long, that path actually does (mostly) make sense. If you were to do it, it would be an organizational mess when looking for something. /Developer is the standard install path. Documentation/ for docs, DocSets for the actual docs (as opposed to sample code), com.apple.ADC_Reference_library to say its an ADC reference library (as opposed to installing your own docsets, which some libraries have), CoreReference.docset to say which docset it is exactly (leopard vs snow leopard, for example), Contents/ is pretty standard for OS X bundles, Resources/ since docs are technically resources, Documents/ (again, there are other files here: sample code, tech notes, etc), documentation/ for the documents themselves, Cocoa/ for which framework you're looking at (It could also be Carbon, Webkit's CSS, Darwin, Java, etc), and, well, thats the end of the chain on my system. But to continue it based on a guess, Reference/, possibly redundant, but its nice for organizational purposes, ApplicationKit/ - you are looking up something in AppKit, but there are other *Kit's that can be used as well, Classes/ instead of headers, maybe, and then NSApplication_Class for the class that you want.
- makecheck 17y ago
  The structure is consistent with other bundles. But the question is, are bundles really the logical way to handle documentation? I don't think so. If you look in places like "/Library/Application Support", everything is basically broken down by product or vendor. It is hard to imagine having so much documentation installed that similar naming wouldn't suffice for DocSets. Apple has also used saner documentation layouts elsewhere (and oddly, in places that are probably not meant to be "public" documentation). For instance, there's a /Library/Documentation, and its layout is very easy to follow.
dkokelley 17y ago
Quick request: Do you think you could put 2 spaces in front of the long url so that it doesn't distort the page layout. That way people will only have to scroll to see the url, and not the rest of the page. Thanks!
- makecheck 17y ago
  I wish I'd done that earlier, but I only thought of it after the editing window (2 hours?) was gone. I can't fix it now...

illumen 17y ago

Indeed. They need someone to go through and give nice urls to all of their documents. Also be good for someone at 1 infinite loop to get a list of all the old urls, and map them to the new urls. Probably not a hard task for their web team.

Zev 17y ago

While absurdly long, that path actually does (mostly) make sense. If you were to do it, it would be an organizational mess when looking for something. /Developer is the standard install path. Documentation/ for docs, DocSets for the actual docs (as opposed to sample code), com.apple.ADC_Reference_library to say its an ADC reference library (as opposed to installing your own docsets, which some libraries have), CoreReference.docset to say which docset it is exactly (leopard vs snow leopard, for example), Contents/ is pretty standard for OS X bundles, Resources/ since docs are technically resources, Documents/ (again, there are other files here: sample code, tech notes, etc), documentation/ for the documents themselves, Cocoa/ for which framework you're looking at (It could also be Carbon, Webkit's CSS, Darwin, Java, etc), and, well, thats the end of the chain on my system. But to continue it based on a guess, Reference/, possibly redundant, but its nice for organizational purposes, ApplicationKit/ - you are looking up something in AppKit, but there are other *Kit's that can be used as well, Classes/ instead of headers, maybe, and then NSApplication_Class for the class that you want.

makecheck 17y ago
The structure is consistent with other bundles. But the question is, are bundles really the logical way to handle documentation? I don't think so. If you look in places like "/Library/Application Support", everything is basically broken down by product or vendor. It is hard to imagine having so much documentation installed that similar naming wouldn't suffice for DocSets. Apple has also used saner documentation layouts elsewhere (and oddly, in places that are probably not meant to be "public" documentation). For instance, there's a /Library/Documentation, and its layout is very easy to follow.

dkokelley 17y ago

Quick request: Do you think you could put 2 spaces in front of the long url so that it doesn't distort the page layout. That way people will only have to scroll to see the url, and not the rest of the page. Thanks!

makecheck 17y ago
I wish I'd done that earlier, but I only thought of it after the editing window (2 hours?) was gone. I can't fix it now...