The project is simple to state: You will provide a ChangeDetector object that can attach to any element in the DOM (quite possibly, to an iframe element or a child of an iframe element) and report changes to attached element.
The ChangeDetector object will have four methods:
Detach stops change detection, performing any necessary cleanup. The add/remove listener methods add/remove a listener, respectively. The listener interface will have six methods:
- nodeInserted(Node parentNode, Node insertedNode)
- nodeDeleted(Node parentNode, Node deletedNode)
- attrModified(Node targetNode, String key, String oldValue, String newValue)
- charDataModified(Node targetNode, String oldValue, String newValue)
where "Node" is GWT 1.5's new W3C DOM node class.
The ChangeDetector will report all changes to the attached element by notifying any and all listeners. All batches of changes will be reported in between calls to the beginBatch/endBatch methods of the listeners.
The rescan() method does a manual rescan, and notifies any listeners.
Now as to the implementation: In general, most browsers provide some notification of changes to the DOM. Firefox in particular provides support for the DOMNodeInserted, DOMNodeRemoved, DOMAttrModified, and DOMCharacterDataModified events, which are sufficient to implement change detection. Safari and Opera support some of these events, but not all, although it appears the rest can be emulated from the events they do support (for example, while Safari does not support DOMAttrModified, it does send DOMSubtreeModified when an attribute changes). IE provides support for none of these events, but has its own properties, several of which may be useful.
Primarily, the implementation of ChangeDetector should rely on events to listen to changes, because it yields high-performance. However, this is not sufficient for robust, production-ready change detection.
To deal with the inadequacies of browsers, a scanning algorithm must be used. Scans might take place at regular intervals, and can be initiated by the rescan() method (possibly, this method may need to support an additional parameter that can limit the scope of the rescan).
The scanning algorithm will look for unreported changes, and report them. Thus, at regular intervals, and whenever rescan() is invoked, there must be NO POSSIBILITY that any change occurs that is not reported through the change detector.
As for how the scanning algorithm would work, here's one way: when a node is reported as added, an attribute is set, '__cd-added', to the index of the node in its parent. Meanwhile, a node maintains another attribute for each reported attribute, e.g. 'class' attribute might become '__cd-class'. Thus, nodes contain embedded in themselves all the information necessary to report comprehensive changes.
In addition to ChangeDetector, you will need to supply a test web page. The web page will feature a WYSIWYG rich-text editor, such as TinyMCE or WYMEditor. The web page will use ChangeDetector to listen to changes to the iframe of the rich-text editor, and construct an identical document elsewhere on the same page (thus, a single listener will be added which will mirror the changes to another part of the web page). This will enable me to thoroughly test that your implementation reports all changes and that content does not diverge over time.
The implementation should be fast, bug free, and written using best coding practices. The test page is MANDATORY and must function exactly as described, with full source code.
I will pay only for a working, complete implementation (no upfront money). Check my reviews on GetAFreelancer