lrdesign / ninjascript Goto Github PK

An input with an attribute of placeholder="whatever" will Do The Right Thing™ in modern browsers worth a damn. NinjaScript should respect that and let the browser do its thing when it can.

For older browsers that don't support the placeholder attribute, NinjaScript should do its jam like Watermark currently does.

With regards to detecting placeholder browser support, Mark Pilgrim supplies this code on the Dive Into HTML5 site. http://diveintohtml5.org/detect.html

function supports_input_placeholder() {
var i = document.createElement('input');
return 'placeholder' in i;
}

Also, placeholder/watermark should not be used in place of a label. Nor should it stomp on the label. Maybe if there is no placeholder attribute, but there is a label, then watermark/placeholder could use the label's text as the ghosted text in the input.

WOuld be really nice to have a configuration that turned logging on and off.

A) WTF? Why is this here?

B) If it has a legit motivation, it needs to live in Behavior.base, I think, not EventScribe.

stopDefault should return "false" (force not default) if it's set, but not "true" when it's false - if "andDoDefault", then examine the event record after return and see if it's "isDefaultPrevented"

"actions" isn't very clear as to purpose.

Right now, ADVANCED_OPTIMIZATION fails - looks like Sizzle is doing something that leads to a skew of property names (it looks like something about the Expr object). It'd be great to get AO to work because:

It's a lot more aggressive - much smaller result.

More important: the exported methods and objects would have to be explicitly listed, which makes the documentation process more straightforward.

Feature request for useful debugging tool: ask NinjaScript to output all symbols for which there are registered handlers.

For example, if I have:

    Ninja.respondToJson({ alert: function(msg) { ..stuff ..},  notice: function(msg) { .. stuff .. }}) 

defined in one file, and

    Ninja.respondToJson({  recommendation: function(recco) {.. stuff ..} })

in a second file, it would be nice to have NS be able to say:

Registered JSON Handlers: 'alert', 'notice', 'recommendation'.

Needed to replace rails.js. C.f. ECL.

At least for the engine, it might be worthwhile to use GCL for most of the browser interaction we're looking for. Still torn about behaviors, but it probably wouldn't hurt to use that too.

Worst case, could use GCL base for modules etc instead of require.js

Akin to behavior packaging: it'd be handy to be able to package a new Ninja.tool and have it used anywhere. Then all the existing tools get packaged, and anything not a behavior or a tool is made so that it doesn't depend on anything outside of NS. Result: much easier to use NS with frameworks other than jQuery.

It'd be nice to be able to have fields in a form be related: automatically update (or clear) results when they change. For instance:

[1] + [1] = [2] - changing the '1' might delete or update [2].

triggerOn needs to be decomposed into:

submitParentOnSelect
hasPlaceholder for select nodes
removeRelated (to remove the submit button)
and submitAsAjax (exists)

jQuery allows clients to call a .trigger method on $() objects with ('event.type', {more: data}) - in which case, the event handler is expected to accept extra arguments.

NS should probably have some facility to handle this kind of binding? Or completely abandon jQuery.

Let client code change app-wide defaults as well as configure behaviors on a case-by-case.

At least: element transformed (with start and end attrs, for when an element is completely replaced), event handled, json handled.

with Ninja.orders do we need to defer behavior defs?

If we do, ninja.does needs to do something about not being called as a constructor - fail, fix it, something.

Really irritating bug: "default" isn't and does "andDoDefault" (although that was the intention).

A console log about "I don't recognize 'default'" would have been helpful.

"Transforming element - "
Selector <> matched ...
Applying behavior transform, priority X

Names/selectors embedded in behaviors for logging?

Needs a backend to do the autocompletion, plus needs fallback behaviors.

Hangs on string 25:

return list.forEach(callback, thisArg)

and all I can do is close the page.

http://goessner.net/articles/JsonPath/

(Might also consider XPath & XML responses...)

Upshot would be much more decoupled event handlers and responses - an easy to maintain a "retain enclosure" rule would handle it.