7:08 a.m.
On 01/30/2013 01:08 PM, ssilvert(a)redhat.com wrote:
On 1/29/2013 11:38 PM, Jesse Sightler wrote:
> On 01/28/2013 09:48 PM, Brian Stansberry wrote:
>>> - Do we have a preexisting class to convert from the ModelNode
operation to a CLI command? If not, nothing immediately jumps out at me that would make
this extremely hard, but I don't want to duplicate existing work.
>>>
>> Not that I'm aware of and I'd be surprised if such a thing exists in any
>> reasonably complete form. The standard use case goes the other direction.
> Understood... that matches what I was seeing as well. At a glance, it
> doesn't seem like the code to go in the other direction would be nearly
> as complex, though.
Yes, building CLI commands automatically is pretty straightforward. The
only thing to watch out for is to make sure you escape special
characters. Here is code from CLI GUI that does that. Please let me
know if you find this list is incomplete:
public static String escapeAddressElement(String element) {
element = element.replace(":", "\\:");
element = element.replace("/", "\\/");
element = element.replace("=", "\\=");
element = element.replace(" ", "\\ ");
return element;
}
One thing that will be difficult in converting console commands is that
the console sometimes executes a command and then decides what to do for
the next command based on the output. I think that will be next to
impossible to replicate in CLI because you will have to understand the
logic and then try to build CLI script conditions based off of it.
The CLI does support if-else and try-catch-finally, though.
Alexey
>
>>> 2. I don't necessarily agree with the proposed approach in the JIRA. I
think it may be easier to append this information to the status result after an operation
has completed. For example, after the user saves a property, a "Save successful"
message appears. I believe this is clickable to show details, and we could display the CLI
commands to rerun the action within that dialog.
>>>
>>> Is that an acceptable way to accomplish this task? Or is there some other
preferred approach to implementing this in the UI?
>>>
>> I'll defer to Heiko Braun on UI details. :) My only comment is this
>> needs to be unobtrusive since it's extraneous to the core task users are
>> trying to accomplish. What you describe sound unobtrusive.
> I agree that it should be unobtrusive. At the moment, I'm trying to get
> together a simple proof-of-concept for one or two panels in the console.
> Once that's done, I'm hoping Heiko can provide some guidance on how it
> should be done. :)
>> One thing to keep in mind with this is raw DMR operations can be
>> converted readily enough into CLI low-level command syntax. But CLI low
>> level commands may not be the recommended approach for achieving many
>> tasks. The CLI now has quite a number of high level commands (e.g.
>> "deploy") that are more user friendly. I wouldn't support any
attempt to
>> map console-generated operations to those high level commands, as that
>> would be a likely bug nest and a maintenance nightmare.
> Good, and I agree that translation to high-level operations would be
> extremely difficult to get perfect.
>
> Right now it looks like the biggest challenge may be that the CLI seems
> to be more strict than DMR. For example, the operation to add a
> system-property in standalone mode rejects "add" operations that contain
> the "boot-time" parameter. But this is only the case from the CLI, as
> the management console sends them as DMR with no issues.
>
> I haven't yet figured out an approach for dealing with that yet, but it
> may be that each operation has to be aware of these discrepancies in the
> management console.
>> The one exception to this is the DMR "composite" operation[1] should
be
>> converted to the CLI "batch" and "run-batch" high level
commands, with
>> each step in the composite being a low-level command after "batch" and
>> before "run-batch".
> Good point, and this looks relatively straightforward to implement.
>
> Thanks,
> Jess
>
> _______________________________________________
> jboss--dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev