Community
Participate
Working Groups
Following the shell plugin documentation (http://wiki.eclipse.org/Orion/Documentation/Developer_Guide/Plugging_into_the_shell#orion.shell.command) I was unable to define a console command which results in HTML responses. According to the GCLI documentation (https://raw.github.com/mozilla/gcli/master/docs/writing-commands.md), commands may have a resultType set to 'html'. The result of such commands should be passes to the console widget and displayed in pretty form in order to create custom UI responses. There are two possible ways of passing a HTML result in GCLI: 1) raw HTML string 2) HTML DOM objects The first possibility results in an escaped string displayed on the console, so e. g. "<b>Hello World</b>" is displayed as a raw "(<b>Hello World</b>)" string (note the extra brackets). The second possibility results in an error while attempting to postMessage the DOM object: DataCloneError: The object could not be cloned.
IIRC we did this intentionally (see bug 392383), because GCLI's 'html' returnType can be a backdoor for plugins to inject unsafe content into the page.
Thanks Mark for the link. Although security is crucial, I think we shouldn't escape HTML responses from all possible plugin sources. I have a quite good example of a shell plugin (log provider client), which shouldn't be available in all instances by default (thus it's a plugin), however I'd like to have the capabilities of other built-in shell commands, e. g. I'd like to pass direct log file links. I cannot use window.open since my plugin is running within an IFrame. For that reason I'd like to pass clickable hyperlinks, but again, I cannot since we have those security checks. Moreover, I cannot pass any pretty print responses, since they require HTML, which is banned. So, I'm stuck with having only ugly text responses left. Perhaps enabling Orion build-in plugins (shipped in the build) to use HTML is a reasonable request? Since the plugin shares host with the Orion instance we would have assurances it's secure. An ugly hack to my problem would be to open a delegated UI with the required links passed in the URL, but I think it's simply unacceptable and not as pretty as I would require.
Links can be displayed as shown in bug 396657. This is the approach that's being taken for showing non-plaintext results in general, using means like markdown syntax for specific cases like this.
FWIW, we have requested approval to use a Markdown parser, which the shell could then invoke to handle the output. This would give plugins access to full Markdown syntax.
(In reply to comment #4) > FWIW, we have requested approval to use a Markdown parser, which the shell > could then invoke to handle the output. This would give plugins access to > full Markdown syntax. This would be quite useful, however still doesn't have to address all problems, e. g. rendering tables. AFAIK not all markdown implementations allow table rendering, since it's not in the official syntax. How do we want to address this issue? (In reply to comment #3) > Links can be displayed as shown in bug 396657. This is the approach that's > being taken for showing non-plaintext results in general, using means like > markdown syntax for specific cases like this. Thanks for that link! I was actually surprised, because such functionality is not supported by the GCLI AFAIK, and the documentation explicitly claims to follow the GCLI in that.. The documentation should be definitely updated. I've opened bug 414649 for that.
(In reply to comment #5) > This would be quite useful, however still doesn't have to address all > problems, e. g. rendering tables. AFAIK not all markdown implementations > allow table rendering, since it's not in the official syntax. How do we want > to address this issue? The vision for the Shell page has been discussed multiple times, and it's to keep its output simple (plaintext, or similar, such as links). There are a couple of places where this vision is not followed (eg.- the twisties used in some of the plug-in management commands), but in general the desire is for command output to not go far beyond what would be expected if one was sitting at a typical command prompt. It's partly about security and partly philosophy of the Shell user experience. So the only current approach to your tables question would be to return a well-formatted string result. Will keep this case in mind, but don't currently have a fancier solution to suggest.
(In reply to comment #6) > The vision for the Shell page has been discussed multiple times, and it's to > keep its output simple (plaintext, or similar, such as links). I'm in favor for having a simple shell UI, but another concern of mine is to have a consistent UI as well. We could allow only strings in the result type. This would force users to create their own UI implementation over string results, as, e. g. tables. In my opinion it's a valid use case, however to keep it as consistent as possible (and prettier as well) would require some assistance from Orion. I get it's not desired to have fancier capabilities then a standard shell, however as I understand the GCLI mission: 'GCLI wants command lines to be discoverable and beautiful in addition to being fast and powerful.' - pretty UI is something we really want. For that reason am all for having a set of helpers for generating the shell UI. Markup is great, but as I've pointed out - there are some valid use cases, which are still not addressed. (In reply to comment #6) > Will keep this case in mind, but don't currently have a fancier solution to > suggest. I'll use something else instead, but please keep this use case in mind. I think a consistent yet 'webish' UI in the shell would be great to have.
I'd pose if the goal is to be as shell like as possible, that a monospaced font should be used. That way, one could produce readable tabular content output by using tabs, spaces etc. But I get this is the opposite direction of what the OP originally requested.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
