On Fri, Jul 9, 2010 at 7:42 AM, Matthew Woodward <[email protected]> wrote: > Given this, it seems completely natural to me that the other engines (Railo > would fall into this camp as well) would document differences and > enhancements as opposed to writing ground-up documentation.
I agree. Most Railo users even tell us that they'd continue to use cfQuickDocs or even the Adobe online docs even if we had everything fully documented... I think part of that mentality is an expectation of compatibility and therefore Adobe's docs are de facto the baseline. > That being said, as we've moved forward on OpenBD it makes more and more > sense for us to generate our own documentation for numerous reasons, and the > addition of documenting straight from the engine is a huge step forward on > ensuring that the docs are always up to date. That's also the approach Railo has been taking (for the same reason). In our web administrator, we have tag/function documentation that comes straight out of the code base. We are continuing to look at ways to use it to seed the wiki as well (so users can comment on and enhance the baseline generated docs). But, as Alan and Matt observed, the primary focus for us - OpenBD and Railo - really has to be on the engine itself, rather than working to replicate all the work the Adobe documentation team does :) -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood -- Open BlueDragon Public Mailing List http://www.openbluedragon.org/ http://twitter.com/OpenBlueDragon online manual: http://www.openbluedragon.org/manual/ mailing list - http://groups.google.com/group/openbd?hl=en
