Iām unclear- why canāt you just use the jQuery plugin?
One of the delightful things about Ember over other frameworks is that you donāt get punished for using jQuery or forced to re-write every feature as native. Initialize it in the the didInsertElement function of a view and you should be good to go. Is there another issue Iām missing?
I can initialise my jQuery plugin in didInsertElement of a View/Component. In my case I have listened to all the jQuery plugins events like ( treeClick, treeDND, treeCreate, treeRename ) in my javascript using jQuery. It is in a separate file like folderTree.js.
Can I call a method initTree(); in folderTree.js from didInsertElement which handles all the initialisation code and event listening.
DOUBT: If I am moving all my logic and event listening to a separate file, is I am doing something wrong against MVC patterns.
How can I have all Ember features like dynamic update, Observers.
For example when I create a folder, jQuery widget triggers an event treeCreate, I will be listening to the event in my JS file and send a request to update the DB. On response I will be getting the newly create folder object.
Here how I can update the model of my Route with the newly created folder object so that it autoupdates itself.
@ramchiranjeevi nice find! i was looking for something like this.
imho it would be the best approach to write a wrapping component which deals with the events from the plugin and updates the underlying tree object, which, i presume, is an nested ember data record array!?
@jens If you have some examples or blogs related to jQuery jsTree can you share it here it will be useful for the wider audience who are working with Ember and jsTree.
oh. maybe i was unclear too; i did not know of jsTree.
do you want to avoid using jsTree at all in your re-write or do you seek to integrate it with ember in you new app?
@jens Is there is an Ember Widget like alternative for rendering tree and having all the features what I have mentioned in my initial post. Then I can go with Ember rendered tree.
Since I am re-writing in Ember I want to support all the features what I have supported in my previous UI.
If it is not possible to use ember to achieve all the features I can go with jsTree as a separate Component and handle all the events in the Component.
For that I need some examples of using jQuery widgets (jsTree, jQuery Dialog, jQuery Autocomplete ā¦) as a Ember Component.
i would go about it as @kylecoberly mentioned earlier:
as i am not sure, how much ember yu have done so far, i just made a super quick example for jQuery-UIās sortable: Ember Starter Kit
to react to events from the widget, you still need to set proper callbacks as defined in the widgets api. one approach is, to simply make these bound functions to your component: e.g. update: function(e, ui){ ... }.bind(this). this way you have access to your component through this. but there are other viable approaches too.
note: it uses the myProperty: function(){ ... }.on(<hook.name>) syntax to not interfere with hooks from the super class.
if you could also provide a jsbin with your approaches so far, that would help to understand your exact question/problem.
ember does not support all the functionality jsTree offers out of the box. one would have to re-implement or port jsTree to make it ember-native. but i recommend against it.
@jens Thank you very much for your quick demonstration on usage of jQuery widget with Ember Components. I got your point.
When a change is done in the Component (sorting the fields) is the state change update in the underlying model.
According to ember you need to update your model so that due to two way data-binding the changes are reflected in the DOM.
Here we are just changing the DOM using jQuery Sortable Widget, but it is not persisted in our underlying MODEL.
Is this ethical or we are doing something against what EMBER persists us to do as just update the model and the DOM is updated automatically by two way data-bindings.
third-party widgets (like jQueryUI) and Ember are two separate worlds. As i pointed out, one must handle the events and control the underlying data in an Ember Way. So, yes, nothing changes about Ember, but Ember cannot automatically know about the widget you are using and therefor not about its DOM manipulation(s).
Are you looking for some automation process on this?
This applies to sortable but will most likely be different from āwidgetā to āwidgetā! The benefit of using a component would be, that you use it in other projects too, as well as share it with the community.
This is also the point, where one must be careful, _when_to update the model as change in the model layer triggers re-rendering! E.g. when you proxy the changes of the sortable on the sort event you will get into trouble as this triggers the mentioned re-rendering and you will loose the currently sorted element. Also you want to always take a look on how your data looks rendered as DOM structure. This might influence the workings of your widget.
As you can see, there is not really a straight forward answer to all widget (letās just take this for jQuery UI); so a jsbin with your approach on using jsTree would help to help.
In my demo, the model ( json object ) is supplied directly to jsTree initialisation inside the component.
Now when I do an action on the tree. the jsTree will directly change the DOM and triggers an event respective to the action.
But in Ember Convention, we do not modify the DOM directly instead we need to update the underlying MODEL and by two way data binding the DOM is updated automatically.
Here its against the convention. I need to follow the Ember Conventions in this jsTree Component also.