29 Dec
2005
29 Dec
'05
4:11 p.m.
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