[jboss-as7-dev] add operation in CLI GUI

[Kabir Khan]

On 13 Jan 2012, at 02:44, ssilvert at redhat.com wrote:

> On 1/12/2012 7:15 PM, Kabir Khan wrote:
>> On 12 Jan 2012, at 19:39, ssilvert at redhat.com wrote:
>> 
>>> On 1/12/2012 1:09 PM, Kabir Khan wrote:
>>>>> On 1/12/2012 11:39 AM, Alexey Loubyansky wrote:
>>>>>> I could suggest two ways to workaround this:
>>>>>> 
>>>>>> - node type as a 'folder', currently the unit is node-type=node-name, 
>>>>>> instead node-type could be a folder that contained node-names and you 
>>>>>> could click on the node-type to add new nodes.
>>>>> Early on I was going to do it this way, but it became clear that it
>>>>> would be overly complicated and would break with the directory notion in
>>>>> the CLI where a directory is /subsystem=jca/, not /subsystem/jca/.  Once
>>>>> you replace = with / you lose sight of the underlying address scheme.
>>>> Could the structure perhaps be 
>>>> subsystem/
>>>> subsystem=jca
>>>> subsystem=jmx
>>>> Or is that too weird?
>>> I just tried that and it did indeed get weird.  You end up with nodes
>>> that don't have any correspondence to the address path.  So you have to
>>> code around it all over the place.  It also made any sort of refresh
>>> impossible to implement without significant hacks.  I do need to improve
>>> refresh at some point and I don't want to make that any harder than it
>>> already is.
>>> 
>>> Try my three latest commits found here and let me know what you think:
>>> https://github.com/ssilvert/jboss-as/commits/cli-gui-fixadd
>>> 
>>> Alexey, once you see it, let me know if you still think that "?" makes
>>> more sense than "*".  That's an easy change.
>> It looks better, perhaps instead of * or ? some descriptive string (that will not crash with any names used, so something like ***Root***) could work. Just an idea, not sure if it is a good or bad one...
> I'm thinking of using a different icon to set it apart.
Cool
>> I think the adds on the actual real nodes, e.g. extension=org.jboss.as.pojo, subsystem=someproperty etc. are a bit confusing now that we have the one mentioned above. 
> If we remove "add" from the real nodes should we also remove
> read-operation-description, read-resource-description, and
> read-operation-names?  All those are generic to the resource type and
> not to a specific resource.
Only add should be removed
>> Likewise the adds on the subsystem nodes should not be there, they are wrong, since each subsystem has a different add handler, most of them taking parameters specific to that subsystem.
> Sounds like a problem with the metadata.
Can you please explain? If it helps, I can add get-described-children-names and get-described-children types operations, if that is ok with Brian.

> 
>> I thought I had sent the below to the list but I see I just sent it to Alexey not. Basically, it is impossible to add anything to something that has an add handler on a non-wildcard node, such as the subsystems:
>> <mail>
>> On 12 Jan 2012, at 18:57, Alexey Loubyansky wrote:
>>> But these don't appear to be a part of the management model. According 
>>> to the model :) Let's fix the model, I'd say. Unless I'm missing 
>>> something...
>> I think that is against how the controller works, e.g.:
>> [domain at localhost:9999 /] /subsystem=jmx:read-resource(recursive=true)
>> {
>>   "outcome" => "success",
>>   "result" => {
>>       "connector" => undefined,
>>       "show-model" => true
>>   }
>> }
>> 
>> If we add the jmx child we'll have something defined for connector=>jmx, but then if it is removed that node is removed from the model so we end up with ^ again. 
>> 
>> Or in  the case of subsystems, I don't think we want loads of subsystem=>mysubsystem => undefined entries, when they have not been initialized.
>> </mail>
>> Perhaps a similar node as the one you have added for the non-wildcard case could work, which when opening the context menu looks for child add operations from read-resource-description? So you right-click on subsystem=***Root*** (or whatever we want to call it) and then you get add-jmx, add-ee etc.
>> 
> 
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev