>> But how should this work for events? Events are just fired. OK. I could
>> scan the code for these calls, that actually fire the event. But where
>> should the doc comment be placed then?
>>
>> Perhaps we could change qx.core.Target, so events have to be declared,
>> before they can be fired. Then the doc comment could be placed before
>> that declaration. But this would mean that when an event is about to be
>> fired, qx.core.Target has to check whether it was declared before, which
>> would cost little a run time for each firing. If this check is missing
>> then it is not ensured that every event is documented.
>
> Why not just scan for all obj.dispatchEvent and obj.createDispatchEvent
> code? We could place the doc comment directly above this call.
Example:
if (this.hasEventListeners("bla")) {
/** Fired when the data was successfully checked. */
this.dispatchEvent(new qx.event.type.Event("bla"));
};
This is problematic.
The first thing is, that it is IMHO not very elegant to have a doc
comment in the middle of a method.
Second, how should the cases be handled where the same event is fired in
multiple places of a class. Should the doc comment be placed at every
place? Is one place sufficient?
Third, how is the name of the event extracted? In most places, constants
are used.
Example:
this.dispatchEvent(
new qx.event.type.Event(qx.constant.Event.INTERVAL));
What happens, when the event is defined somewhere before the call?
Example:
var evt = new qx.event.type.Event(qx.constant.Event.INTERVAL);
this.dispatchEvent(evt);
--
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
