As Aaron said in the other thread. This is being discussed and there are various documentation formats being considered. Most of the good options out there seem to be inline documentation which I personally don't like. But I'm sure the issue can be resolved. I use a lot of Visual Studio during my day so I'd love to see some automatic portability. The guys maintaining support for Coda and TextMate has expressed interest as well. The issue definitely seem to be on the table.
Do you guys have any suggestions on existing formats that might be easily portable? On Jun 2, 11:44 pm, fakedarren <[email protected]> wrote: > And I hope that on the basis of Aaron's excellent and impartial > review, and the fact they can now choose inline docs for either > framework, your company has made the right choice! > > On Jun 2, 10:30 pm, brian bobek <[email protected]> wrote: > > > > > Regarding "the fact that jQuery had support for Intellisense at the > > company I worked for, their jaw dropped, and it's a big selling point..." > > > This is definitely the case at the agency I work for as well. That > > said, I can combat some of it with the wonderful framework vs toolkit > > argument on Aaron's comparison site, but since our Chicago office is > > HEAVY on the .net, it truly is a big selling point. > > > On 6/2/09, fakedarren <[email protected]> wrote: > > > > Hi all > > > > I have recently made some Intellisense documentation for MooTools, but > > > I doubt that Visual Studio documentation is the best way to spend my > > > time - there is undoubtedly more popular editors used by MooTools > > > developers - there must be a lot of Aptana, Dreamweaver, and Coda > > > users, to name just a few of the IDEs we all use. I would rather spend > > > it on a parser to provide docs for all IDEs. > > > > One of the main points of feedback I've received from making the > > > Intellisense is that it would be awesome if we could get a consistent > > > 'documentation API' so we can really easily access documentation, and > > > rather than rolling our own static docs, spend the time (which can be > > > a lot of time just rewriting a flavour of MooTools) writing a parsing > > > engine (mmm, regular expressions) that parses a unified doc file. > > > > To the core developers, do you still use Natural Docs? I remember a > > > while back (maybe 1.1?) it said 'powered by Natural Docs' somewhere on > > > the page. We use that where I work because when I make an addition to > > > our company library, I just document the JS file and we're done. Which > > > is great! > > > > If so, I can write a regexp parser that will represent that as an XML > > > document, or JSON format - the only problem with that is that we'd > > > also need an indication of inheritance too. If you make a custom build > > > of Core, or more likely, More, it needs to pick this up and present a > > > representative doc file. Maybe an accompanying XML file, hosted > > > somewhere on mootools.net? > > > > Am well up for an open discussion for this. I know that when I > > > mentioned the fact that jQuery had support for Intellisense at the > > > company I worked for, their jaw dropped, and it's a big selling point, > > > hence why I wrote a Moo equivalent, because I love the moo...now > > > there's no excuse :) It would be awesome if we could provide MooTools > > > support for all the major IDEs - it would be even more awesome if we > > > can come up with a good way to support cross-IDE documentation for ALL > > > javascript frameworks!
