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

On 06/27/2014 04:45 PM, Brian Stansberry wrote: > 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. At this point, it's ls, read-attribute and commands handled by GenericTypeOperationHandler (which means [xa-]data-source, jms-topic, -queue, -connection-factory, etc). The generic handler includes action read-resource (e.g. w/o other optional arguments 'data-source read-resource --name=ExampleDS'), which is basically a formatted result of :read-resource. In general, it could be applied to any command displaying an attribute value to the user. Alexey > >> 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 >> > > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev