[wildfly-dev] Automatically resolving expressions in the CLI

[Brian Stansberry]

On 6/27/14, 8:27 AM, Alexey Loubyansky wrote:
> 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.
>

Good point. Joe, we'd need a clear understanding of all the commands 
that would be affected.

> 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.

Ok, good.

> I am more concerned about how intuitive that will look like for the user
> in various contexts.
>

Yes, I think the UX aspects are the more significant ones.

> 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
>>>
>>
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat