25 Nov
2008
25 Nov
'08
6:09 p.m.
On Nov 25, 2008, at 5:45 PM, Anca Paula Luca wrote:
Jean-Vincent Drean wrote:
So to follow your strategy, if I want to add a page in the XWiki
space, I'll have either to scroll by thousands of documents or enter
some characters in the filter so that I know it won't return lots of
matches so that I can then see the add page link...
hmm... doesn't sound right to me.
What am I missing (I'm asking since everyone seems to agree with A).
Thanks
-Vincent
In a previous thread we've discussed about
how to add a link in the
WYSIWYG editor, and more generally, how to browse the wiki from a
WYSIWYG dialog box (See http://markmail.org/message/tyxrcr24w3n6m2pn
for more details).
After some thinking and a discussion with Laurent Lunati, I'd like to
suggest a 3rd way of browsing the wiki from the WYSIWYG: an enhanced
tree menu.
I've put the mockups and Pros/Cons on this wiki page :
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorWikiExplorer
This wiki explorer widget would be used in the link dialogs, image
dialogs, file (attachment) dialogs.
Here's my +1 for 3) A).
+1 for 3) with filter option.
+1 for 3A), despite the fact that user needs to scroll through all
the pages to
add his new one.There are 2 usecases for adding a new page:
* the user hasn't found the page he's looking for -- in which case
he'd need to
see the whole list anyway (maybe with a search filter)
* the user knows that the page does not exist and wants to put a
link to it --
in which case I think he knows what he's doing and he'd use the
"advanced input"
anyway.
I find the add option _at the end_ (A) more natural than _at the
beginning_ (B,
C), because you're supposed to add new things when you've explored
all other
possibilities and none suited your needs. Happy coding,
Anca Luca
>
> From the implementation POV 3) is probably the most difficult
> proposal
> and 1) the simplest one. Widget 3) would need to be a reusable (and
> highly configurable) GWT component so that we could use it as our
> main
> navigation/reorganization tool in the future. This tree would replace
> our current treeview (Main.AllDocs) which is AFAIR the only page
> using
> the YUI library in XE.
>
> Thanks,
> JV.