<code>Josh.PathHandler</code>'s area of applicability.</p>

<p>The user object comes from:</p>

<p>We never fetch an individual repository, instead opting to fetch all for the current user at user initialization via:</p>

<p>We do the same for branches, fetching all, lazily, once we need to list or autocomplete them:</p>

<p>Finally, we fetch the current directory via</p>

<p>This is done for the root during repo initialization, and for path completion and <code>cd</code> on demand.</p>

<p> The API returns

<h2>Initializing the Console</h2>

<p>In order for us to show the console, we have to have initialized a user, a repository and retrieved it's root directory. This is done after

<pre><code>$(document).ready(function() {

setUser("sdether", "josh.js",

function(msg) {

});</code></pre>

<p>We call

<em>sdether</em> and

<em>josh.js</em>, before setting the authenticated user as the current user and initializing the UI of the shell.

</p>

</p>

<p>All API access goes through a helper function

<em>json</em> call and inspecting the response. For simplicity, all error conditions just result in

<em>callback</em> being called with null instead of a

<em>json</em> payload. Also for simplicity, any initialization failure, just bails out via

<p>Once we have a user, we can call

</p>

<h2>Adding Commands</h2>

<code>setUser</code>, Josh functions do not have a separate error handler. Since Josh interacts with the UI, it has no concept of failure -- it has to execute the callback to continue executing. It is up to the caller to deal with errors and transform them into the appropriate UI response. But it still gives us the flexibility to undertake an asynchronous actions, such as calling a remote API and complete the function execution upon the asynchronous return of the remote call.

</p>

<code>TAB</code> completion, since doing efficient tab completion against the full set of GitHub users is beyond this tutorial. Instead it expects a valid username to call

</p>

<p>If called without a <em>username</em>, we simply render user template with the current user.</p>

<p>The

<code>TAB</code> completion of partial repository names against the repositories of the current user.</p>

<p>Given no argument, we simply render the repository template with the current repository</p>

<em>-l</em>, we render the repository list template with the repositories we fetched on user initialization.</p>

<p>Finally, the argument is used to try and retrieve the repository from the known repositories. If that succeeds, we call

<code>Josh.PathHandler</code> before changing the current repository to the one specified. Upon switching we again render the repository template with the now current repository.

</p>

<code>bestMatch</code> takes care of creating the completion object with the appropriate argument completion and list of possible choices.

</p>

<p>T can either show information about the current repository, change the current repository or list all repositories belonging to the user. It also provides

<code>TAB</code> completion of partial repository names against the repositories of the current user.</p>

<p>Given no argument, the

<em>-l</em> argument renders a list of all known branches for the current repository, while an actualy branchname as argument will cause the console to change its current branch.

</p>

<p>Showing the list of branches uses

</p>

<p>The completion handler for the command simply calls

</p>

<h2>Wiring up Josh.PathHandler</h2>

<p>A file node is an opaque object in which we can track any file state we want but has to have two properties:</p>

<pre><code>{

name: 'localname',