Nested vs. Stacked controllers #170

Closed
derks opened this Issue Aug 29, 2012 · 8 comments

Comments

Projects
None yet
2 participants
@derks
Member

derks commented Aug 29, 2012

Currently the options for controllers are:

  • Be nested under the base controller (non-stacked)
  • Stacked on either the base controller, or another controller

There is currently no way to nest a controller under a non-base controller like this:

$ myapp [controller2] [controller3] [controller3_cmd]

I can only do this:

# stacked
$ myapp [controller3_cmd]

# non stacked
$ myapp [controller3] [controller3_cmd]

@ghost ghost assigned derks Aug 29, 2012

@derks

This comment has been minimized.

Show comment
Hide comment
@derks

derks Aug 29, 2012

Member

Might be able to do this with a Meta.stacked_type (one of 'embedded' or 'nested')... embedded being current behavior, and 'nested' just being that the controller shows up under it in --help... but no commands or arguments merge with the parser.

Member

derks commented Aug 29, 2012

Might be able to do this with a Meta.stacked_type (one of 'embedded' or 'nested')... embedded being current behavior, and 'nested' just being that the controller shows up under it in --help... but no commands or arguments merge with the parser.

derks pushed a commit that referenced this issue Sep 11, 2012

derks pushed a commit that referenced this issue Sep 11, 2012

@derks derks closed this Sep 11, 2012

@derks

This comment has been minimized.

Show comment
Hide comment
@derks

derks Oct 9, 2012

Member

This is slightly incomplete in that it does not error out if no command is detected. Meaning, the default command isn't called if no other commands are found.

With the following controller arguments, the default command is not called and nothing happens:

arguments = [
            (['modifier1'], 
             dict(help='command modifier positional argument', nargs='?')),
        ]
Member

derks commented Oct 9, 2012

This is slightly incomplete in that it does not error out if no command is detected. Meaning, the default command isn't called if no other commands are found.

With the following controller arguments, the default command is not called and nothing happens:

arguments = [
            (['modifier1'], 
             dict(help='command modifier positional argument', nargs='?')),
        ]

@derks derks reopened this Oct 9, 2012

derks pushed a commit that referenced this issue Oct 9, 2012

@derks derks closed this Oct 9, 2012

@Kentzo

This comment has been minimized.

Show comment
Hide comment
@Kentzo

Kentzo Oct 13, 2013

@derks With current implementation it is not possible to register multiple controllers with the same name but stacked on top of different controllers.

Kentzo commented Oct 13, 2013

@derks With current implementation it is not possible to register multiple controllers with the same name but stacked on top of different controllers.

@derks

This comment has been minimized.

Show comment
Hide comment
@derks

derks Oct 13, 2013

Member

In it's current form, it is not possible to have two controllers (or two handlers of the same interface) that have the same label. I would have to look into this to really know how difficult it would be to implement something that would work.

Can you give me some more context around the use case? Just want to wrap my head around a situation where you'd want the same label for two different controllers.

Thanks!

Member

derks commented Oct 13, 2013

In it's current form, it is not possible to have two controllers (or two handlers of the same interface) that have the same label. I would have to look into this to really know how difficult it would be to implement something that would work.

Can you give me some more context around the use case? Just want to wrap my head around a situation where you'd want the same label for two different controllers.

Thanks!

@Kentzo

This comment has been minimized.

Show comment
Hide comment
@Kentzo

Kentzo Oct 13, 2013

I'm building a tool which has very hierarchal interface, like you may find in lldb.

I have collections and I have various actions I can do on collections: listing, adding, updating deleting etc…
Some actions may receive arguments and be configured via options. Arguments and options are be different for different collections.

E.g. I have 2 collections: servers and drives. I have list method for each collection. It can receive only the '--json' argument. As far as I understand, the only option to have custom arguments for command is to implement controller for that command, so I've added 2 controllers: ServersListController and DrivesListController. Unfortunately I cannot add them due to restriction above.

Kentzo commented Oct 13, 2013

I'm building a tool which has very hierarchal interface, like you may find in lldb.

I have collections and I have various actions I can do on collections: listing, adding, updating deleting etc…
Some actions may receive arguments and be configured via options. Arguments and options are be different for different collections.

E.g. I have 2 collections: servers and drives. I have list method for each collection. It can receive only the '--json' argument. As far as I understand, the only option to have custom arguments for command is to implement controller for that command, so I've added 2 controllers: ServersListController and DrivesListController. Unfortunately I cannot add them due to restriction above.

@Kentzo

This comment has been minimized.

Show comment
Hide comment
@Kentzo

Kentzo Oct 13, 2013

@derks Is it possible to somehow change label of the controller that is displayed in usage description? If so, I could pass unique identifier for each controller, but same label for displaying.

Kentzo commented Oct 13, 2013

@derks Is it possible to somehow change label of the controller that is displayed in usage description? If so, I could pass unique identifier for each controller, but same label for displaying.

@derks

This comment has been minimized.

Show comment
Hide comment
@derks

derks Oct 13, 2013

Member

That is a thought I had, however the way that commands/controllers are dispatched, there has to be a mapping to link the label you type at command line with the actual controller. This is effectively what CementBaseController.Meta.aliases does... however aliases have the same restriction as the controller label (it has to be unique).

We should certainly support controllers with the same label if they are stacked... but it isn't something we can just throw in there with out a decent amount of thought and testing.

Will track this in Issue #207. Please follow up in that issue, as this one is actually closed.

Member

derks commented Oct 13, 2013

That is a thought I had, however the way that commands/controllers are dispatched, there has to be a mapping to link the label you type at command line with the actual controller. This is effectively what CementBaseController.Meta.aliases does... however aliases have the same restriction as the controller label (it has to be unique).

We should certainly support controllers with the same label if they are stacked... but it isn't something we can just throw in there with out a decent amount of thought and testing.

Will track this in Issue #207. Please follow up in that issue, as this one is actually closed.

@derks

This comment has been minimized.

Show comment
Hide comment
@derks

derks Oct 29, 2013

Member

@Kentzo FWIW, I added support for controllers with the same label (in latest git).

http://cement.readthedocs.org/en/latest/examples/controllers_with_same_label/

Member

derks commented Oct 29, 2013

@Kentzo FWIW, I added support for controllers with the same label (in latest git).

http://cement.readthedocs.org/en/latest/examples/controllers_with_same_label/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment