A lot of work, yes, but if the editing workflow supports plugins such that we could configure additional preview steps, then at least some work becomes external. For example, I've implemented tags a bit differently than Jeremi has, and would love to add my own plugin that includes a "tag this document" step with a list of already-used tags and suggestions based on document content. The "only" core XWiki work needed for this an editing lifecycle API and configuration interface. Conceptually, the plugin API requirements are simple: 1) given this state (content, new or existing doc, user), would you like to interact with the user? 2) if so, what HTML fragment should I show the user? 3) goto 1 Most interesting plugins would require exposing services for form submission or AJAX requests. In the case of form submissions, they'd need a mechanism for forwarding back into the process. Maybe JSR 168 offers an analogue, but I'm not sure how or if to "prevent" plugins from sending their own, unskinned response (terrible for user experience) while still allowing them to services AJAX requests or use pop-up windows. - - - Hans Gerwitz http://phobia.com/ On Dec 29, 2005, at 8:45 AM, Ludovic Dubost wrote:
Yes, it's a good idea.. I'm been thinking about a good way to suggest links or handle spellcheking.
This could indeed be done in the "Preview" step. We could add a filter API for the preview which could add some HTML/JS on the fly to certain part of the text. Then the client UI would allow the user to choose between the proposed suggestions. Finally the preview could be refreshed with the changes.
Drag and dropping of images in the document could also be done at that point.
Now this is quite a lot of work.
Ludovic