Правильный способ документировать или составлять схему пользовательских моделей событий в DOM

Question

Представьте, что в вашем веб-приложении есть несколько компонентов и подкомпонентов. Вы хотите отслеживать, как ведут себя все пользовательские события, которые вы добавили. Существуют ли установленные способы составления схемы или документирования такого поведения?

Вот некоторые вещи, которые должна показать документация:

1. Фактическое вложение соответствующих элементов DOM различных компонентов.
2. Названия событий и места, из которых они стреляют.
3. Любые полезные нагрузки, которые прикреплены к пользовательским событиям (например, содержимое memo в пользовательском событии Prototype.)
4. Места, где наблюдаются события.
5. Указания того, какие события запускаются в ответ на другие события.
6. Где события могут вспыхнуть, и где они остановлены.

Answer 1

Честно говоря, я любил визуальное моделирование, и когда MS выбросил его для Visio, я был несколько разочарован.

Тем не менее, Visio по-прежнему отличный инструмент, и вы можете использовать его для создания объектных моделей компонентов и определения событий, свойств, методов и т. Д. Он имеет некоторые встроенные функциональные возможности для конструкций UML и всего.

Но я должен сказать, в конце концов, я обычно получаю блокнот или MS Word. В зависимости от того, насколько многословным вы хотите быть с вашей документацией, ввод заметок или описание для компонента никогда не вписывается в любой вид DOM-инструмента, но вы можете выделять жирным шрифтом, табулировать, перечислять и выделять курсивом, как сумасшедший, внутри документа Word.

Звучит грустно, но это правда!

Answer 2

Я никогда не слышал об установленном стандарте документации для веб-приложений.

Тем не менее, поскольку вы определили различные аспекты вашего приложения, которые вы хотите отслеживать, вы можете хранить эту информацию в блоке документации для каждого обработчика событий и использовать jsdoc toolkit для генерации некоторых встроенные документы.

ИМХО, я думаю, что, поскольку вы уже знаете, что именно вы хотите задокументировать, вы можете свободно создавать документацию в любом формате, который вам наиболее подходит, даже если он полностью уникален для вашего приложения / организации. 8 часов на стеке потока без ответов должны означать, что стандартного ответа нет;)