snowmantw / fluorine Goto Github PK

This related to those jQuery context functions. To fix this:

1. 'find' must record the previous DOM
2. 'end' will pass the DOM as result.

But this will introduce special states in our own context, so maybe 'end' should not be implemented. In detail:

The 'find' function OK because it use only previous result to execute.
But 'end', in other hand, need previous steps carry on "previous DOMs" as states.

Even after a context function had been defined, we're still able to wrap it in some other scripts like this:

// ... some other necessary code ...
var existing = UI.o.protype.$
IO.o.prototype.get = function()
{
    // should handle and save these calls' arguments
    UI.o.prototype.get.__calls_args.push(arguments)

    // calls is lot enough, but I'm not sure if this condition can be made easily
    if( enough() )    
    {
        handlePreviousArguments()     // may use passed in arguments here
        return existing.apply(this, arguments)    // call the wrapped function
    }
    return UI.o.prototype.$  // return self to accept more calls if not enough
}

This trick is ugly and may be not easy to implement well, but if we handle it well, we can provide users such feature:

IO("/resource/manifest.json")(TAG)
    .get( )(TAG)(BREAK)
    .done()

These functions can come with optional calls to behavior differently.Although I feel it's will be much easier to create new chaining function to "decorate" other functions:

IO("/resource/manifest.json")(TAG)
    .get( ).tag(TAG).break(BREAK)
    .done()

In current stage the later way seems more proper to implement the debug feature.

Happens when: Event bind ( UI ) context, and the context won't execute more than once while the notification be exactly triggered twice.

Bind function need to be fixed. I may refactor it and make it more robust under different circumstances.

Workaround: Discard pureness issues and use '_' lambda function instead.

Every function in contexts optionally has its own name, and it will be printed in debug mode. But if we extend a new context from the existing one, those functions not be extended will use the name given in the basic context when we called them. For example:

IO.get          --> New function come without any problem
IO.initialize() --> Not extended; will call Context.initialize()
IO.run( )       --> Extended; will display its name

If we create a chain like this and execute it:

IO("/resource/manifest.json").get( ).done( )( )

The debug messages will be like:

[DEBUG] Process executing step #0, step name(if any): Context::initialize ( call with ), [] 
[DEBUG] Process executing step #1, step name(if any): IO::run ( call with ), ["/resource/manifest.json"]
// ....

The #0 step, which actually calls the Context::initialize, should be corrected with IO::initialize, which is more useful for debugging.

Happens when: Event context bind another Event context.
Behavior: The inner context won't wait for notification triggering, but execute itself immediately.
Caused by: The base context seems embed the inner context's steps without consider possible problems.

This should be a arguable feature, and won't be fixed before next version.

In easiest way:

break: function( a ){  debugger; return a }

And we should wrap the debugger as fluorine.debugger() to allow users set different debugger.

Add a done() like function to let user can directly turn the chain into wrapped one.

From this:

idGen(  UI('body').$().text("Hello").done()()  )

to this:

UI('body').$().text("Hello").idGen()

Users can get rid of troubles caused by the parenthesis, especially the chain become longer and complex.

It need a context to let 'find' work under that. Need to

1. Find out how jQuery's 'find' works
2. Fit it's requirement.

A growing up list...

• removeAttr
• slideDown
• slideUp

From this:

var foo = function() {/.../}

to this:

var foo = function foo() {/.../}

Because WebRTC concerns too much asynchronous but related steps.

It's now '(POST)' rather than 'POST'

At this moment introducing complete but complex type checking rules isn't proper. We should implement a simple enough but useful type checking mechanism to prevent some obvious but hardly to discover errors, like asking for Context but receiving a function.

The main idea is to avoid to distinguish inherited objects like UI vs. IO, and check only primitive types like Function vs. Object, or "our primitive types" like Context vs. UI (different level).

This feature can be tough work, but it can show how important our "definition" stages are.

If DOM elements come with '[data-fluorine-events="dom-event-id:click,hover"]',
it should be automatically bound to forward events: 'dom-event-id-click' and 'dom-event-id-hover' after call a fluorine function: fluorine.bindEvents

Another similar method should be in the UI context, which own type:

DOM -> UI DOM

and will accept a DOM to do the same thing. It should be named as 'autobind'.

We can achieve the same goal with anonymous function combinator:

IO('/resources/manifest.json')
    ._( function(){ console.log('URL') } )
    .get()
    ._( function(){ console.log('get') } )
    .done()()

This allow user to monitor steps of the chain while execute it. But it's very annoying to repeat the function(){ console.log ... everywhere. We can provide a debug, or more general, a log function to output these messages.

For those polling required method, we should add a polling method like this:

IO().polling('/wait_something', 400, 3, check).done()

It means polling the server with endpoint '/wait_something' every 400ms, and automatically turns failed if it didn't get right answer, which is neither caused by errors (handle by the method implicitly) nor fails to pass the check more than 3 times.

Usually we use idgen() function to avoid redundant anonymous generator:

s1 = UI( ).idge( )

Is equal to:

s2 = function( ) { return UI( ).idgen( ) }

But they're actually different while used in Event context, and will cause the ting failed. In other words, this will work:

g = Event('foo').tie(s2).done( )
g( )
Notifier.trigger('foo')

But this will not:

g = Event('foo').tie(s1).done( )
g( )
Notifier.trigger('foo')

The last one g will report "Tying an undone context or just not a context.", and leave a none executed step in the process stack. Thus next time when the notification get triggered again, the event will execute only one step then (implicitly) refresh the whole process.