Re: [wildfly-dev] Automatically resolving expressions in the CLI

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