jameswfoster / hotdrink Goto Github PK

I'd like a parser for the Eve-like language documented in docs/view.ebnf that 
produces the view AST processed by hotdrink.controller.Factory.

Supporting expressions beyond simple variables may be best implemented by 
augmenting the model with new logic variables representing those expressions. 
It is unclear to me right now how to best implement that augmentation.

Add implementation for HotDrink to this performance comparison of dataflow 
libraries:

http://jsfiddle.net/samdelagarza/ntMdB/167/

According to the jsdoc reference, variables of CGraphAst object have "cellType" 
and "usedBy" fields. But the current code is generating and using "cell_type" 
and "used_by" fields.

CGraphAst ::=
  {
    variables : {
      /variable-name/ : {
        cellType : /cell-type/,
        usedBy : /method-name-list/
      ...
    },

This should be fixed across several codes including parser, solver and 
evaluator.

After recent refactoring to support Eve layout specification,
every examples show weird behavior which is putting the focus back to the first 
widget whenever clicks some widgets with mouse. So it makes harder to enter 
values while using mouse.

This happens in Firefox 4.0 (3.x was not checked), Chrome and Safari. Jaakko is 
also having this problem.

Walkaround for now is using tab key to move focus between widgets.

It no longer needs to worry about v.usedBy or m.inputs, and it should switch to 
using the model construction API anyways.

Not too urgent anyways as I don't expect it to be used much outside our group.

There are cases where the most recently edited value should not be immune to 
change. A slider with user-defined min and max bounds is an example. Currently, 
if a derived value in the solution graph is the most recently edited value, it 
will not be overwritten during evaluation. This protection should be removed.

I would like to see builder functions for HTML - the kind for plugging into 
hotdrink.controller.Factory - so that we can use buildAndBind.

Adam is great for a declarative approach, but we need a programmatic way to 
build models.

At the least, we need a way to add variables, methods, and constraints. Model 
checking should probably be called separately instead of occurring after every 
change.

This way, we can keep track of which questions we have answered, i.e. which 
design decisions we have made, and the discussion surrounding them.

Use Adam in tests instead of (possibly hand-written) cgraphs and method strings.

No one should be hand-writing compiled Adam any more. There are too many 
internal constraints to trust to humans.

I would like to see new entry functions, e.g. openDialog, that support layout 
ASTs and - after the view parser is available - Eve specifications.

Document in a wiki page the process for adding support for new widgets. Use a 
phone number widget as an example.

I would like to see blocks allowed in the expression language. We should be 
able to introduce variables, either through compound-statements like 
JavaScript, or let-clauses like Haskell.

Need a good way to bind commands.

We should be able to appropriately disable command widgets. This requires a 
couple things:
- The ability to set preconditions on commands. We have global invariants right 
now; I'd like to move to command-specific preconditions.
- The ability to intercept the use of command arguments without calling the 
command. This probably means we will have to wraps calls to commands. 

Add an INCDIRS option.

Prototype is a very invasive library that doesn't play well with others. We 
should not depend on it.

Should we replace it with another library that provides facilities for 
inheritance and enumeration, or should we write a bunch of ugly, error-prone 
JavaScript?

Wonseok put a lot of work into a set of example files for testing HotDrink. 
Integrate them into the official source code and verify their behavior, whether 
it is success, expected failure, or unexpected failure (i.e. uncovering a bug).

Upload some portion of the source tree for viewing. What portion should that be?

The CGraphAst reference documentation under hotdrink.graph.CGraph has some 
optional fields which are not actually generated by Adam parser.

These are 'reaches' in variables and 'constraint' in methods.

CGraphAst ::=
  {
    variables : {
      /variable-name/ : {
      ...
        [, reaches : /variable-name-list/]
      },
      ...
    },
    methods : {
      /method-name/ : {
        ...
        [, constraint : /constraint-name/]
      },
      ...
    },

Enablement/Disablement algorithm doesn't work now for multi-checkbox and radio 
button.

Here is the test case:

[Sheet]
sheet test {
  interface: {
    x : true;
    a : false; // single checkbox
    b : []; // multiple checkbox
    c : "yes"; // radio
  }
  output:{
    result <== (x == false) ? "nothing" : {a:a, b:b, c:c};
  }
}

[Layout]
<style type="text/css">
#form { border: 1px solid black; padding: 1em; margin: 1em; }
#form label { display: block; }
</style>

<form id="form">
<label>X : <input type="checkbox" id="x"> Enable/Disable all below</input>
<label>A : <input type="checkbox" id="a"></input>
<label>B-1 : <input type="checkbox" id="b" name="b" value="1" /></label>
<label>B-2 : <input type="checkbox" name="b" value="2" /></label>
<label>B-3 : <input type="checkbox" name="b" value="3" /></label>
<label>C : <input type="radio" name="c" value="yes" />Yes <input type="radio" 
name="c" value="no" />No</label>

<button type="button" id="result">OK</button>
</form>

When the checkbox x is off, a, b, c widgets should be disabled automatically 
but only the single checkbox is disabled well.

From the log I can see that the algorithm detects all of them can be disabled 
but disablement behavior didn't trigger for b and c.

log: model.js:187: Starting analysis for enablement behavior...
log: behavior/enablement.js:137: result is relevant.
log: behavior/enablement.js:137: x is relevant.
log: behavior/enablement.js:277: interface variable x can not be disabled
log: behavior/enablement.js:277: interface variable a can be disabled
log: behavior/enablement.js:277: interface variable b can be disabled
log: behavior/enablement.js:277: interface variable c can be disabled
log: behavior/enablement.js:273: output variable result can not be disabled
log: model.js:189: Finished analysis for enablement behavior.
log: controller/model.js:66: Refreshing view...
log: controller/behavior/value.js:75: writing #x
log: controller/behavior/value.js:75: writing #result
log: controller/behavior/enablement.js:64: disabling #a
log: controller/model.js:75: Refreshed.

Constant functions might never be executed since they never have any changed, 
relevant inputs.

Needs example.

The CGraphAst is documented under hotdrink.graph.CGraph. It should stay there, 
but it needs updated documentation to reflect that it has a new "initializers" 
field.

Also, the hotdrink.parser.ModelParser should be updated to reflect that it 
returns a CGraphAst. This means adding at least a @see for 
hotdrink.graph.CGraph.

The setter for radio element groups, which came from the Prototype form 
extensions ( http://ericnguyen.com/Prototype-Form-Extensions/ ), does not work 
as expected.

The setter is called with the appropriate value, but ends up selecting the 
first option, even if it's not the desired value.

This can be tested in the multi-element widgets example.

In the example, Enforced min-max, infinite recursion is encountered.

How to reproduce? Just keep moving your focus by pressing tabs to the max field.

Firefox may be frozen, but Chrome shows error "Uncaught RangeError: Maximum 
call stack size exceeded" in the console.

This might be caused by the recursion of marking can-be-relevant, since the log 
stops after the following line:

lib/behavior/enablement.js:215: Marking can be relevant...

We need ViewAsts ("trees") for all of the examples. They should be based on the 
existing HTML descriptions.

Need a short tutorial introducing HotDrink usage.

In the example, Multi-element widgets, variable 'd' is bound to the following 
widget:

  radioGroup (
    label : "D",
    items : [
      { name : "True", value : true },
      { name : "False", value : false }
    ],
    value : d
  );

However, the variable 'd' is assigned either "value" or "on", not true or false.
If the type of value is not boolean, it works fine.

Once we remove the dependency on Prototype, we will need new conventions for 
documenting classes, methods, and properties. The task is to devise such 
conventions and then migrate to them, updating the content of the documentation 
(to reflect changes in the system) in the process.

I am going to add extended registration form and tax form examples.

If we want to be useful, we need to support repeated visual elements.

To do this, I believe we will need some internal treatment for collections. 
What is the best way to specify repeated elements (declaratively and 
imperatively)? How are they treated in the model? Can we have repeated 
constraints?

Take a look at competitors. What do they do well, and what can be improved?

Prototype 1.7 has been released, containing bug fixes and a new element 
listener mechanism, Event#on ( http://api.prototypejs.org/dom/Event/on/ ). The 
changes are described at 
http://prototypejs.org/2010/4/5/prototype-1-7-rc1-sizzle-layout-dimensions-api-e
vent-delegation-and-more

Input dictionaries for each entry-point API function should contain arbitrary 
expressions that may reference other model variables. They should be parsed 
just like any other expression in the model specification, thus being treated 
as a run-time extension to the model specification.

Initializers should be executed in order of dependency. The algorithm could be 
similar to the following:
  1. Assign strengths to stay constraints from 2 on.
  2. Assign strenghth 1 to all user-defined constraints.
  3. Create a method for each initializer
  4. Place each initializer method into a singleton constraint and set its strength to 0.
  5. Solve using QuickPlan.
The resulting solution should have all of the initializers in dependency order 
while allowing the user-defined constraints to fill in the holes.

The new initialization algorithm will probably be best encapsulated within the 
Solver, since that is where strengths are assigned before solving.