[dojo-contributors] 1.1 overload

Bill Keese bill at dojotoolkit.org
Thu May 1 11:28:33 EDT 2008

Dustin Machi wrote:

> While I'm sure the manual is out of date in some place, I don't think 
> "really out of date" is really a fair statement.  If it is then we have 
> entirely failed to have any sort of 1.0 compat throughout the lib.

Well, I suspect that at least the new methods/parameters aren't 
documented and the deprecated methods/parameters still are.   Dijit has 
had a lot of churn since 0.9 and although we maintained backwards 
compatibility there are a lot of updates and deprecations.

There's also been a ton of stuff added to dojox, like charting and new 
RPC layer (IIRC) that would be good to document.

Plus, all the user comments attached to each page should be processed 

> Aside from the committer list on dojo.jot.com, I think we can just take 
> [dojo.jot.com] down.  We have been through it before (though apparently 
> nobody remembers).  

I could be wrong... I remember some parts being processed but I didn't 
think we transferred everything.  Like for example those 0.4 release 
notes, or http://dojo.jot.com/WikiHome/tr2.    Plus I notice that the 
dojo.jot.com FAQ (http://dojo.jot.com/FAQ) has a lot more entries the 
the FAQ on dojotoolkit.org (http://dojotoolkit.org/support/faq).

>> Having said that, there's a lot of redundancy between the online manual 
>> and other sites, specifically the examples on dojocampus and the 
>> auto-generated API guide, so maybe we should get rid of that info from 
>> the manual,

> Well I don't think redundancy in documentation is bad at all, I would 
> argue that it is good..its not code.  Admittedly it is more work to 
> maintain.

It's just that we've all been so busy making dojo great that I at least 
haven't had time to maintain the manual, and I'm worried that we won't 
have time in the coming months either.

 >>although I'm reluctant to remove the API info from the
 >> manual until we can get the metatdata and infrastructure support so the
 >> auto-generated API guide can differentiate between protected and public
 >> methods, and also between initialization parameters/event
 >> handlers/normal methods/callbacks that the user should override.

>  In regard to the last portion of this statement, I'm guessing 
> some of that is going to be impossible since as a human being there are 
> several places that I cannot tell what I should do.  I imaging having 
> the api tool figure it out will be a little more difficult.  Furthermore 
> we have pretty much destroyed the meaning of _ on functions and 
> filenames or at least diluted it to the point where you can't 
> consistently apply some usage pattern.

Well, we don't have to make the API tool figure out anything, we can 
just mark each parameter/method with keywords.

More information about the dojo-contributors mailing list