[wildfly-dev] Automatically resolving expressions in the CLI

[Alexey Loubyansky]

On 06/26/2014 05:31 PM, Brian Stansberry wrote:
> Thanks, Joe, for looking into this.
>
> I'm curious what you've done so far with your 'ls --resolve-expressions'
> work. Did you use the existing ':resolve-expression(expression=___)' low
> level operation to process any expressions found in the :read-resource
> response?
>
> There are a few aspects of this I'd like to explore.
>
> One is the UX one. Is allowing 'resolve-expressions' in some contexts
> and not others a good UX? Will users understand that? I'm ambivalent
> about that, and am interested in others' opinions.
>
> If it can work for a server and for anything under /host=*, then I'm
> ambivalent. Any restriction at all is unintuitive, but once the user
> learns that there is a restriction, that's a pretty understandable one.
> If it only works for a patchwork of stuff under /host=* then I'm real
> negative about it. An area of concern is /host=*/server-config=*, where
> an expression might be irrelevant to the host, only resolving correctly
> on the server that is created using that server-config. That will need
> careful examination.
>
> A second one is how this data would be displayed with 'ls'. A separate
> additional column? Or replacing the current data? The answer to this
> might impact how it would be implemented server side.

Keep in mind that ls is an example. There are other commands that will 
have to support this feature once it's implemented in one place. Another 
example is read-attribute command. The ability to resolve expressions 
elsewhere will be a natural expectation then.
So, it has to be thought of as a general features that can be applied to 
various cli commands.

IMO, the values returned should just be replaced with the resolved ones 
for display. Some commands support --verbose argument, in which case 
additional info is displayed in columns, there we could include the 
original value.
The output of the cli commands in some cases is parsed by scripts or 
other code, so keeping it simple will help there too.

> The third aspect is the technical issue of how to make any
> 'resolve-expressions' param or CLI argument available in certain
> contexts and not in others. That's very likely solvable on the server
> side; not sure how difficult it would be in the CLI high-level command.

Current tab-completion supports dependencies of command arguments and 
their values on the current context (connection to the controller, 
standalone/domain mode, the presence of other arguments on the line and 
the values specified for them, etc). Technically, there shouldn't be an 
issue.
I am more concerned about how intuitive that will look like for the user 
in various contexts.

Alexey

> FYI, for others reading this, offline Joe pointed out there's a related
> JIRA for this: https://issues.jboss.org/browse/WFLY-1069.
>
> On 6/26/14, 5:41 AM, Edward Wertz wrote:
>> I'm looking into whether it's possible to automatically resolve expressions when executing operations and commands in the CLI.
>>
>> >From my understanding, there are two variations of the problem.
>>
>>    * Operations are server-side processes that are accessed via ':' in the CLI and, currently, the CLI presents the results returned as-is to the users. ex: ':read-resource'
>>
>>    * Commands are processes that get manipulated by the CLI before getting presented to users. ex: 'ls'
>>
>> I've been experimenting with adding arguments to the CLI commands, like 'ls --resolve-expressions', and gotten it working for the standalone and domain side of things. However, I can't control the scope of the argument, so it's available in situations that cannot accurately resolve expressions like the 'profile=full' section of the domain tree. The results wouldn't be reliable.
>>
>> The same problem would apply to adding parameters to the server-side operations. The scope of the operations themselves can be controlled, but not their parameters. An execution like ':read-resource(recursive=true resolve-expressions=true)' can't resolve expressions unless it's used against an actual server or host, but the operation is available almost everywhere. Again, the results wouldn't be reliable.
>>
>> I'm wondering if anyone can suggest a way to attack this problem? There is already a ':resolve-expression(expression=___)' operation, so users can somewhat laboriously get the runtime values they want, but I can't figure out a way to integrate the values into the existing framework successfully. Other than creating entirely new operations and commands, like 'ls-resolve' and ':read-resource-resolve', which seems like an unsustainable way to solve the problem.
>>
>> Thanks,
>>
>> Joe Wertz
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>