Comments on Selective Export UI Proposal
Navigation
$xwiki.getDocument('Help.SupportPanel.Content').translatedDocument.title
Failed to execute the [include] macro. Cause: [Current user [incubator:XWiki.evalica] doesn't have view rights on document [xwiki:Help.SupportPanel.Content]]. Click on this message for details.
org.xwiki.rendering.macro.MacroExecutionException: Current user [incubator:XWiki.evalica] doesn't have view rights on document [xwiki:Help.SupportPanel.Content]
at org.xwiki.rendering.internal.macro.include.IncludeMacro.execute(IncludeMacro.java:119)
at org.xwiki.rendering.internal.macro.include.IncludeMacro.execute(IncludeMacro.java:59)
at org.xwiki.rendering.internal.transformation.macro.MacroTransformation.transform(MacroTransformation.java:311)
at org.xwiki.rendering.internal.transformation.DefaultRenderingContext.transformInContext(DefaultRenderingContext.java:183)
at org.xwiki.rendering.internal.transformation.DefaultTransformationManager.performTransformations(DefaultTransformationManager.java:88)
at org.xwiki.rendering.async.internal.block.AbstractBlockAsyncRenderer.transform(AbstractBlockAsyncRenderer.java:74)
at org.xwiki.rendering.async.internal.block.DefaultBlockAsyncRenderer.tranform(DefaultBlockAsyncRenderer.java:154)
at org.xwiki.rendering.async.internal.block.DefaultBlockAsyncRenderer.execute(DefaultBlockAsyncRenderer.java:137)
at org.xwiki.rendering.async.internal.block.AbstractBlockAsyncRenderer.render(AbstractBlockAsyncRenderer.java:157)
at org.xwiki.panels.internal.PanelWikiUIExtension.render(PanelWikiUIExtension.java:132)
at org.xwiki.rendering.async.internal.block.DefaultBlockAsyncRendererExecutor$DecoratorWrapper.render(DefaultBlockAsyncRendererExecutor.java:67)
at org.xwiki.rendering.async.internal.block.DefaultBlockAsyncRendererExecutor$DecoratorWrapper.render(DefaultBlockAsyncRendererExecutor.java:49)
at org.xwiki.rendering.async.internal.AsyncRendererJob.runInternal(AsyncRendererJob.java:101)
at org.xwiki.job.AbstractJob.runInContext(AbstractJob.java:246)
at org.xwiki.job.AbstractJob.run(AbstractJob.java:223)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
This looks great
It would be nice to have some options for the HTML Export too, not just because the HTML tab looks lonely, but also because some customization is useful and people have been asking for it. For example, allow to export with/without the menus, panels, annotations, comments, allow to export only the comments, etc. Unfortunately, there's no support for such things yet...
My main disappointment if you gonna use the "classic" checkboxes is that then we will need some link from "Select"/"Remove" actions and the whole thing of making the selection/removal simpler and obvious is gone.
Also the "classic checkbox" as a remove action (without a remove link action) is not gonna be very intuitive (cause check is positive metaphor)
Here's a "live" document tree prototype: SpaceTree (also works without javascript! )
This works great and beautiful.
About the style modifications, I like the ones from the proposal better, because:
- Indentation: the icon is enough IMO to state that the folder is the parent. When they are on the same grid, the scanability is better and also consistent with the Import UI.
- Bold for Space names increased separation of the hierarchical relation, and eased again the readability;
- You have bold + highlightColor for the location of the query result. I think one is sufficient (and that is highlight color). If you thing the highlight color is not readable enough, then that is a ColorTheme problem.
Sure, I'll make them look like the proposal, I don't have a strong opinion about these aspects. Basically:
When searching in the tree, how should matching space names be handled? (I ask because there is no illustrative example for this in the proposal.) In the current implementation I don't check the space name, but I intend to display the matching spaces collapsed by default in the results. Is this OK? I don't see the reason to expand them initially, since it will only make the response time much longer and it will crowd the resulted tree with information that is not really useful.
yes - they need to be collapsed. The user is looking for the space's name, not it's content.
The advantage of this tree is that after you find what you need you can further explore and expand.