What is the principle of ractivejs's two way binding? - ractivejs

I'm using ractivejs,I know angularjs's two way binding based "dirty check",but I don't know the principle of ractivejs,who knows?I want a detailed answer.

Ractive doesn't diff or check anything, it uses the declarative template to know exactly what needs to be updated.
Ractive constructs a virtualDOM based on the template. The templated portions of the virtual dom (things with {{...}} in them) register with the viewmodel using the keypaths they contain.
When a ractive.set(...) or one of the other data manipulation methods occurs, dependents are notified of the change (computations and expressions, upstream and downstream keypaths, as well as observers are also notified).
Ractive uses a runloop that batches the actual DOM changes for any set operation to occur at the end of the cycle.
In addition to API calls, Ractive offers twoway binding by default. This maps needed DOM events from form input controls to the API calls to set the data to which it is bound (via the specified keypath).
Ractive does offer the .update(keypath) and .updateModel(keypath) methods which can be used to flush changes from model to view, or view to model when it is not possible for Ractive to know about them, for example using a third-party widget library.

Related

In Meteor.js, what's the difference between method-based database API design and the subclass approach?

Namely, what are the advantages and disadvantages of the following approaches to building a server-side database API in Meteor?
Method-based
import Db from 'Db';
Meteor.method({"insert": (data) => {Db.insert(data)});
Subclass-based
import {Mongo} from "meteor/mongo";
class MyCollcetion extends Mongo.Collection {
insert: (data) => {super.insert(data);}
}
This problem has been solved below; there is a similar question for further reading: Meteor method vs. deny/allow rules
This is mainly a matter of ease vs control. Subclassing may be easier for simple things, and methods are more powerful.
This can also be affected by your state of mind (or affect it): CRUD vs. action-based mutation.
insert/update/remove go well with a CRUD state-of-mind, while you can associate methods with action-centric RPC mutators.
Eventually, this is a matter of personal preference, so I will try to give a short factual description and let the readers to decide based on their taste.
Subclassing
By default, Meteor automatically generates mutation methods (insert, update, remove) when a collection is instantiated.
Those methods are called behind the scenes when calling MyCollection.insert(mutator, cb) on the client side (outside client-side method code). When arriving to the server, the data are first passed through allow/deny rules and then executed.
When subclassing, you override those methods and get a 'hook' into the process.
Using methods
When defining a Meteor method you get full control of the process.
You set the parameters and the name of the method and you can perform the validation and authorization as you wish.
You can also create a method stub for client-side use, which generates optimistic UI until the results of the method server execution are received.
You can use something like a validatedMethod to get some extra validation logic and modularity to your method.
You can also prevent the creation of the default mutation methods by setting a false value for the defineMutationMethods option when instantiating the collection. You can also forbid direct mutation from the client by supplying the appropriate deny rules.
While subclassing allows you to use MyCollection.insert(...), etc. on the client, you need to call the method name with the arguments that you defined in order to mutate data.

Easy way to tell if data is dirty

I am currently using databinding on a group of spark form elements and want to know if the data class I am bound to is dirty.
It might be nice if spark "Form" elements would trigger a change event that bubbled up to and was caught by a spark "Form". Then I could just add an event listener to the form. But I don't see something like that.
So besides comparing a copy of the original data class to the bound data class OR adding a change event to each form element and capturing that event, what's an easy way of knowing a class object has changed?
Make an extension of TextInput or whatever other input elements you'll have in your form then in your components creation complete register a listener for the change event, in the handler dispatch a bubbling event, then in your document that contains the form use your custom elements and add a listener via AS3 to the Form for the event you dispatched and stop it's propagation at that point.
Otherwise I think your second solution of change handler on each wouldn't be too bad. If you have a lot of elements in the form or it's dynamic you could write a function that steps through the form items of the form and checks their children then you just have to write a switch that deals with each class type (you can use http://www.actionscriptdeveloper.co.uk/getting-the-class-of-an-object-in-as3/on each of the child elements to determine what type it is, then if it's a TextInput or whatever register the appropriate event to call your commonly used function, just be sure it has a generic Event as it's parameter since all other Events will be sub-classes thereof).
So far as I know there is no easy way to listen for changes to the underlying data from the ArrayCollection or other wrapper ListCollectionView data structures. Part of the problem is the elements added a collection aren't required to implement any sort of interface to allow for listeners to be registered. That is, the data elements aren't necessarily event dispatchers, the only other way for this information to be communicated to the List would be if the data elements had a handle on all lists that contain that element and they mark something on the lists to indicate "dirty" when any property is set. These are all achievable within the constraints of the language but aren't provided out of the box as the usage for them is probably limited and could potentially unnecessarily bloat the cpu usage of the ListCollectionView in other cases.

How Do I See All Events Fired by an Object?

I am having trouble wiring up an event listener to a fl.transitions.Transition.
Is it possible to somehow view all the events an object fires? That way I could check I am using the correct event (and possible view better ones to use).
The easiest is to override the dispatchEvent method in classes where you want to intercept events.
You can find the classes in %CS_ROOT%\Common\First Run\Classes\mx\transitions\easing\.
You can also create a subclass of EventDispatcher with a custom dispatchEvent-implementation and use that as a subclass for all classes where you'll be wanting to intercept events.
greetz
back2dos
The problem is, you have to have an event type to listen for. The only way to do this is to add listeners for all the possible events.
Now, you can add a handler with an indeterminate event type, such as:
private function myUniversalHandler(event:*) : void {
trace(event.type);
trace(event.constructor.toString());
}
And this will report any event passed to it. Nevertheless, it simply won't be called unless it is listening for an event of a particular type. And adding all those listeners is a lot of work to go through. Better to study the events available to you from whatever class you are dispatching the vent from.
I would look at TransitionManager, and the events allTransitionsOutDone and allTransitionsInDone which it dispatches. I haven't used these, but my understanding of their function matches what you seem to be looking for.
checkout the online reference, you should see there all events (and inherited events) of a Class.
On a side note if you are using flex you might be using mx.states.Transition
There is no way, at runtime, to find out all the events that fire from a component. You'll have to explore the component source code to get a complete list.
Reviewing the ASDocs, as others have suggested, is a good way to get a handle on the documented events of a component; and in most cases you'll be able to find one to suit your needs.
You cannot programmatically get a list of all events fired by any given object. You can however get a list of all events fired by a standard library object (that are part of it's public interface) from its documentation (cilck on the show inherited events link) and decide whether you're using the appropriate one.
I have scratched my head quite a bit on this issue as well.
The answer is this
you can get a list of all event listeners that an object is listening to only if attached though MXML
if not attached through MXML you cannot see the events an object is listening to (attached by AS)
if you want to see all the events an object is listening to you can check for hasEventListener although this is a long coding way
another efficient way (if you can use it, I couldn't) is to monkey patch the framework and create a dictionary of listeners for every object.
you can accomplish that by patching FlexSprite and overriding the addEventListener function.
you should keep in mind, this will not work when you are loading the framework through RSL.

Equivalent of describeType for Flex Component EVENTS

Using "introspection" In Flex I can say:
var classInfo:XML=describeType(SomeObject);
Which will list for me the Accessors, Methods And Variables.
(http://livedocs.adobe.com/flex/3/html/help.html?content=usingas_8.html)
But what is the equivalent to programmatically inspect all of an object's possible EVENTS?
(NOT JUST the events for which event listeners have been set, but to somehow step through a list of all VALID EVENTS for which event listeners may POTENTIALLY be set -- I realize that such lists are readily available online, and that's great for cases when I know the object's type at design type, but I require some way to inspect any given displayobject programmatically at runtime, and determine what events, if any, are or may be associated with it.)
There isn't a way.
The Event information defined using the event metadata tag is done only for the purposes of code hinting and documentation via ASDocs. It has no relevance to events that the component may or may not be firing.
At any point in time, a portion of code can call "dispatchEvent" and dispatch that event. This is used very commonly for "somePropertyChanged" events which are used for bindings. These events rarely, if ever, get documented using the event metadata. But, the component still fires them.
Bubbling confuses the issue; because if a component's child fires an event where the bubble property is true; then it is almost the same as that component firing the event. How, programmatically, would you figure that out without some sort of code analyzer?
That said, there is a compiler argument to retain metadata ( keep-as3-metadata at http://livedocs.adobe.com/flex/3/html/help.html?content=compilers_14.html and http://jacwright.com/blog/72/using-your-own-custom-metadata-in-as3/ ).
I believe if you do that, then there is a way to get the event metadata from the component; I thought using describeType. But, remember that metadata is not the whole story in terms of events.

What is the best way to tie a Flex Tree control to a tree stored in a database?

I have a local SQLite database that contains a tree (as Nested Sets). In an AIR application, I want to display that tree in a tree control and provide means to change the nodes' names and copy, move, add or delete nodes.
Now, I'm hiccupping a little on where to put which code. Obviously, I have a class which will perform operations like load / update / insert / delete against the database. This would load the whole tree into some storage variable and save changes made by the user back to the db.
Should this class be the dataProvider, the dataDescriptor or an extension of the Tree control itself? And when the user requests an operation like adding a node, should that update the dataProvider and let the database handler react on an event, or should it call the database handler's method and then update the dataProvider? I'd say that the latter is better, because it's easier to not update the Tree's data if something goes wrong with the db query.
There's methods to add and remove nodes in the DefaultDataDescriptor and in the Tree class (protected methods in the latter), should I use / extend those or ignore them?
The reason I'm confused about this is that, according to the docs, a Tree control uses the object stored in its 'dataDescriptor' property to parse and manipulate the actual data which is stored inside its 'dataProvider' property.
This seems to make sense, until you realize that unless you subclass it, it's never the Tree control that manipulates data (with the exception of drag&drop, if that's enabled), and it's not the dataDescriptor, either. Rather, in all examples, manipulating data happens directly via the dataProvider object and that triggers event handlers in the Tree control.
What is it I don't get here?
Take a look at mx.controls.treeClasses.HierarchicalCollectionView. It is not part of the public API, but its full source is available as part of Flex. The Tree controller uses this class internally to handle various data sources.

Resources