Comments and changes to this ticket

• 

  bahuvrihi April 29th, 2008 @ 11:04 AM

  • Milestone set to “Tap-1.0.0”

  Command Integration

  A main page can be served up that basically echos 'tap help', but with the commands being active links to the command pages.

  If commands have some sort of exit hook on their help, then the server can create a form for running the command. Issues:

  • Guessing form type for configs
  • Figuring the form type and inputs for the command itself (likely this should be done through documentation tricks)

  Run

  The current run input format is amenable to specifying rounds and task order. A graphic can be generated to depict the specified workfow. Basic workflow joins should also be available (a-la ticket #25 )

  On execution, the command line command should be made available for storage/resue. The interface should be able to parse a command into it's parts

• 

  bahuvrihi September 10th, 2008 @ 10:08 AM

  • Milestone changed from “Tap-1.0.0” to “Tap-0.11.0”
  • Tag set to “feature, server, tap”
• 

  bahuvrihi October 13th, 2008 @ 09:11 AM

  • Tag changed from “feature, server, tap” to “feature, server, tap”

  To make a schema:

  
    <input name="1[]" value="one">
    <input name="1[]" value="two">
    <input name="1[]" value="three">
    <input name="1[]" value="--config">
    <input name="1[]" value="value">
  

  Becomes:

  
    {1 => ['one', 'two', 'three', '--config', 'value']}
  

  The hash can be translated into an array by index. The --config input can be hidden, and the input specifying the config value can be any type of input (checkbox, datetime, etc).

• 

  bahuvrihi October 15th, 2008 @ 03:01 PM

  Commands

  • |inputs|action|
  • |task, +|add task if necessary|
  • |task:, :task... +|fork, add if necessary|
  • |task:..., :task, +|merge, 2x for sync_merge, add if necessary|
  • |task, -|remove task (blank input, hide)|
  • |task, up|updates configurations using name|
  • |up|update page -- rebuild condensed workflow|
• 

  bahuvrihi October 21st, 2008 @ 08:11 AM

  • Milestone changed from “Tap-0.11.0” to “Tap-1.0.0”
• 

  bahuvrihi January 14th, 2009 @ 01:05 PM

  Currently the system uses:

  
    nodes[index][0]    # tasc
    nodes[index][1]%w  # args
    nodes[index][2]    # configs
    nodes[index][3]    # options
  

  Args, configs, and options are separated in this way, to ensure that the final results are ordered consistently. Configs and options don't require a specific order, but the tasc specification always needs to be first.

  (Note that the keys are provided as a hash, and so the representational order is scrambled by the time the cgi params reach the parser.)

  Multiple entries to each sub index (0,1,2,3) do preserve representation order; all are concatenated into an argh:

  
  nodes: 
    "0": 
      "0": 
      - tap:dump
      "1": []
  
      "2": 
      - --backup-dir
      - backup
      - --filter
      - ""
      - --audit
      - --date-format
      - "%Y-%m-%d %H:%M:%S"
      - --rollback-on-error
      - --date
      - --name
      - tap/tasks/dump
  

  Which is then parsed by Parser into a schema:

  
  - - name
    - args
    - configs
    - options
  

• 

  bahuvrihi January 21st, 2009 @ 07:58 PM

  Cgi scripts could use a lazy attribute to specify non-default routing. Default route:

  
    [cgi/path/to/file.rb]
  
    # ::route :cgi (path/to/cgi)
    # ::route :cgi/:action (path/to/cgi/action)
  

  Then you can also have a CGIController class to work like your standard controller. Action is a method. Call the method, use the instance variables in a template. Template named like cgi/action.

  This will give compatibility with more established frameworks, and an easy port if desired. Additionally this will allow basic cgis, alternate template engines, testing, etc.

  At this point:

  
    ::manifest declares task
    ::generator declares generator
    ::desc shortand for rap tasks
    ::route for cgi routes
  

  Not too bad.

• 

  bahuvrihi January 24th, 2009 @ 09:46 AM

  Reorganize:

  Tap::Server is a type of task.

  • call is call
  • process takes a url and pretends it was sent to the server (use rack request)
  • setup env default... server should require env (as it isn't required by tasks normally) and take the instance for app.root
  • task can be run by a handler for a true server

  Implement a route/proxy method. Update the parsing scheme:

  
        # /                      # => app
        # /non-existant          # => /app/non-existant
        # /env/key:              # => env/key:app
        # /env/key:non-existant  # => /env/key:app/non-existant
  

  Cache key at earliest moment to the controller. Clear cache if in development mode. If people want something fancier they have to implement it themselves.

  Update template engine so that:

  
    render thing, options
  

  is the syntax. Determine the extension dynamically, and determine rendering engine from there.

• 

  bahuvrihi February 4th, 2009 @ 05:01 PM

  Alternate implementation. Route everything as:

  
    /key/argv?query
  

  Then make Controller a kind of Task. Every call the url is parsed and the resulting task processed.
  

  
    tasc = env.tasks.search(key)
    task, args = tasc.parse(argv)
    task.reconfigure query
    task.process(*args)
  

  On the plus side this is very natural to write and suggests a subtle difference between this and the command line; no schema just a single task. It also has the benefit of being predictable.

  On the down side, --help and other options (not configs) must be in the argv (a break in the consistency). --help itself will cause trouble as it exits by default.

• 

  bahuvrihi March 27th, 2009 @ 07:10 PM

  For Rack 1.0:

  
  <form method="post" action="<%= uri(:index) %>">
    <input type="hidden" name="argv[][id]" value="task" />
    <input type="hidden" name="argv[][config][one]" value="c1" />
    <input type="hidden" name="argv[][config][two]" value="c2" />
    <input type="hidden" name="argv[][config][three]" value="c3" />
    <input type="hidden" name="argv[][argv][]" value="v1" />
    <input type="hidden" name="argv[][argv][]" value="v2" />
    <input type="hidden" name="argv[][argv][]" value="v3" />
    
    <!-- add nonsense break to ensure division between nodes -->
    <input type="hidden" name="argv[]" value="--" />
    
    <input type="hidden" name="argv[][argv][]" value="v1" />
    <input type="hidden" name="argv[][argv][]" value="v2" />
    <input type="hidden" name="argv[][argv][]" value="v3" />
    <input type="hidden" name="argv[][id]" value="task" />
    <input type="hidden" name="argv[][config][one]" value="c1" />
    <input type="hidden" name="argv[][config][two]" value="c2" />
    <input type="hidden" name="argv[][config][three]" value="c3" />
    
    <!-- additional breaks ok anywhere -->
    <input type="hidden" name="argv[]" value="1" />
    <input type="hidden" name="argv[]" value="2" />
    <input type="hidden" name="argv[]" value="3" />
    
    <input type="submit" value="Update" />
  </form>