ess / belafonte Goto Github PK

Options are flags that take an argument. A good example of this is the -i flag for ssh.

Allow an app to know that it has sub-apps, and allow sub-apps to know that they're not the main application

When one app mounts another, the outer app should show the following for usage on the command line:

SYNOPSIS
  appname [command]

Instead, it shows this:

SYNOPSIS
  appname

The README is a good start, but the DSL, the helpers, and the special methods (handle, setup) need proper documentation.

Additionally, the fact that command-line help (-h/-help) is generated automatically needs to be mentioned, at the least.

Switches are flags that represent a boolean.

For example, the -n flag for the echo builtin is a switch.

As it stands right now, the handle method for OuterApp in the following example never has a chance to execute:

require 'belafonte'

class InnerApp < Belafonte::App
  title "inner"

  def handle
    stdout.puts "This is the inner app"
  end
end

class OuterApp < Belafonte::App
  title "outer"

  mount InnerApp

  def handle
    stdout.puts "This is the outer app"
  end
end

exit OuterApp.new(ARGV).execute!

There are still untested artifacts of the initial experiment lingering in the code. They need to either be removed or tested.

As it stands now, there's not much enforcement for the case of trying to have both an unlimited argument and a mounted app within the same app.

Args are values passed on the command line that are not tied to an option. For example, in the command ssh [email protected], [email protected] is an argument.

The internals of execute! currently process the flags, then the args, then handles them.

The problem with this is that processing the args before handling -h/--help prevents the help action from happening.

Two possible solutions:

• handle help specifically before handling args
• enable help when arg errors are raised

So, with the run pattern that we have, App#execute! _must_ always return an integer (0 for success, >0 for failure). As it stands now, That isn't always guaranteed to be the case, and that breaks the basic contract of the whole damn thing.

Need to figure out a way to ensure that this always happens, Additionally, caveats need to be added to the documentation to explain that if the app uses Kernel.exit, we're not responsible for the app's exit status.