I have a graph of molecular interactions that takes nodes and edges from a query to my database. I also have two buttons as node labels: "Remove" and "Add" (where "remove" should remove the selected node, while "add" should expand to first neighbors).
I would like to add a function that removes the selected node (on click) without reloading the web page, but just reloading the graph (I want the selected node to disappear from the graph). So, the problem is not the function cy.remove but rather the graph reloading.
I am new to cytoscape.js (let's say to javascript), so I have no idea on how to reload a graph and where to put the remove and reload functions. To date I am only able to pass the ID of the node I want to remove and/or expand via GET method using php. This actually works, but it reloads the web page making a new query to my database, and it becomes tricky when one wants to add and remove a lot of nodes.
Could anyone provide me some simple example code that explains how to reload a graph after a button click, keeping all nodes except the removed one?
Sorry if it is a stupid question
Thanks
$('#button_deleteNode').click(function(){
cy.remove(nodeID);
});
I am trying to write a component based on the foundation Image component that will write the image to the DAM instead of the "local" jcr node on file upload. I also want it to activate the "DAM Update Asset" workflow so that it will create the different size renditions. Can you use a listener to write it to the DAM or is there another or better way to accomplish this?
I don't see a way to just do it within the component itself. But an EventListener could be triggered if someone uploads an image. In this EventListener you can move the image to a defined folder in DAM and start the workflows you want programmatically. Then you update the component so it references the new DAM asset instead of a directly attached nt:file.
Depending on which configuration of the image component you use and which browser is used, the upload is a bit different. The file usually first gets stored in /tmp and then moved. I am not sure it this only happens if the dialog is closed. So the safest way would be to await this event, eg. a add/change event on the jcr:lastModified property.
Is there a way by which I can duplicate or clone dijit widgets?
Basically, idea is to improve page rendering performance by minimizing widget creation time.
We have a single page web application and we do not reload the entire page whenever the user performs any action.
The flow of events is as follows,
The main page is loaded by the browser. It contains a dijit ContentPane which acts as a master container and displays the entire page using various other dijit widgets like textboxes, tabs, datefield, Enhanced grid etc.
The user performs an action (e.g. click on a dijit button)
The application sends an ajax call to server which processes the button click event and generates UI of the next page.
Browser receives successful response from ajax call and calls refresh method of dijit ContentPane. Which triggers destruction of existing widgets and new set of widgets are created and placed at appropriate position. (instead of refreshing the entire page)
The user again performs some action and again the refresh method is called which triggers destruction of existing widgets and new set of widgets are created and placed at appropriate position.
Because of such architecture the browser has to destroy existing widgets and recreate them again and again. Which results in slow performance.
The idea is to have a set of widgets always readily available on the browser clone them and place at appropriate position and update them instead of recreating each time.
Yes this is possible with something called _AttachMixin.
Basically there is no getting around the fact that your widgets would need to attach event listeners to the HTML Document. What can be cut out though is the time in the Dijit Widget's lifecycle to generate the DOM. As we well know, simple Dijit widgets like a dijit/form/Button has a div inside a div inside a div etc.
This is explained in detail here http://dojotoolkit.org/reference-guide/1.9/dijit/_AttachMixin.html
Here is an example using Node.JS as a backend. http://jamesthom.as/blog/2013/01/15/server-side-dijit
This is a tough problem and this concept isn't explained very thoroughly. If you have a backend that is not Node.JS you have to manually make the widget string and pass it as a response to your AJAX and an follow the example from the 1st link (Ref Doc)
We have had lots of widgets of our app render nicely within the client side. A far less complicated approach would be to simply show / hide (instead of render and destroy) widgets as and when they are needed. I assume that you app's access policy would focus on data and not which person has access to which widget.
I have read a lot about the patterns of sharing data between views .
I know how to use delegates,and segues to pass data(iOS), but i want to share a more deep question.
Lets say i have some tasks app, and each new task the user create, is an instance of a class called Task, that holds all the data on that task(date,text,etc) .
Now when in viewA, that shows the tasks list in a table, a user push a button to create a new task, hence has to create an object of Task class.
Than i take the user to viewB to edit the task, and maybe later to viewC .
A few options are possible, but for each i find some inconvenience.
viewA's controller is creating the Task new object,and pass it to b, than b to c, etc.
viewB's controller is creating the Task new object,than post a delegate to A,with task
It seems that the right option is 1 , but it has some problems such as that after view controller B edit the task, viewA's controller needs to reload the table with that new task- anyway, than, option 2, posting a delegate from b, seems more simple,so b is creating a Task object, than post delegate to the table in A to save it and also to reload the table with it .
Here the data is less capsulated .
Maybe i am completely wrong ,but i really try to understand how things should be done right .
Any thought will be helpful to me.
Or you could create a data model.
Consider having a TaskManager class that manages the list of tasks, creates them, and knows which one is currently selected (or most newly created). Either your TaskManager can be a singleton or can be accessed via your app delegate. Anything that needs to be done with a Task, the TaskManager handles.
That way, you make your view controllers more independent because they don't talk to each other but read and update the current state of the data model from the object that's responsible for it.
I have encountered a problem with the MVC pattern in ExtJS 4. At least, I think I have. Having approached multiple people with this question, and having posted numerous times in the Sencha forums, I am now turning to a broader audience in hopes of getting either a light bulb or a confirmation.
Problem
Your application has the ability to open many different views, some of which themselves are mini-applications. Additionally, a user may wish to have multiple concurrent copies of a view open.
This application is a single-page client-side Javascript application.
The ExtJS 4 MVC model expects you to define all of your controllers in your Application class. These controllers are then initialized when the Application loads. Controllers keep track of views, models and stores.
When you initialize controller A multiple times, say to create more than one copy of a view, you end up with two views that reference the same data stores, and functionally send duplicate events to the Application event bus.
I have refactored my application by adding new prototype methods to Component and Controller to allow for both a) sub controllers (some of my controllers were getting pretty huge) and b) defining stores specifically for the view they work with. The models can still be defined on the controller, just for ease of use by handlers if you need to do something like grab a record from the server.
Question
My understanding of MVC would lead me to believe that models more directly relate to the View than then Controller. I asssssume that ExtJS 4 decides to attach stores (which I think can be seen as wrappers to a more classic model) to Controllers for purposes of encouraging re-use of loaded data, and to optimize away from having many copies of the same class instantiated. It seems to me, however, that one cannot do this if one intends to have many instances of a view available to the user. To my thinking, having many instances is an important option in an OO framework, hence why I have bucked the trend and implemented prototypes on some of the Ext base classes. (Thank you Ext.implement!).
Is there any way to have multiple concurrent instances of a view with different data loaded into them using the out of the box MVC classes and making uses of the provided setters, getters, etc?
I was faced with a similar problem:
Consider a tabpanel for a CRM type application which opens new instances of a view for each client. And say that tab view contains 3 or 4 row-editing gridpanels for interacting with different collections of data relating to that client.
The solution I came up with was based on this from the Sencha forums. In a nut shell, almost all events that are dispatched from a view contain a reference to the view itself. The handlers in my controller's control function all use these to get a reference to the correct view instance.
For dealing with the multiple instances of the same store needed for this, I took this to heart from that post:
For the Store instance on the view or a global one... depends on the
needs. If you are going to use globally then make it global. If you
only are going to need it on the view then put it on the view. MVC is
not a law, you can change it to fit your needs. Technically the
Controller part of MVC is suppose to be the middle man between the
View and Model parts but sometimes that's just not needed. I create
the Store in the view 95% of the time. I'll give you an example...
If you have a Store for products, you probably only need to reference
that Store in your Grid. That usually isn't needed for other parts of
the application. However, if you have a Store to load countries, I
often need it globally so I only have to load it once and can then
set/use that Store in several views.
So I just created the needed store's that relate to a view instance specifically, inside the view's initComponent method. The application did have a few global stores that I created as store classes following the MVC recommendations. It worked out nicely to encapsulate the view instance stores inside the view. Then I only needed one instance of the controller.
To answer your question specifically, currently, there is no ExtJS official recommendation or config for dealing with multiple instances of the same view that use the same store constructor. I have spent some time looking for something like that and the best I have found was this recommendation from one of their forum moderators.
I don't think you ever need more than 1 instance of a controller, regardless of how many views/models you have. See functional example here:
http://whatisextjs.com/extjs-4-extension/fieldset-w-dynamic-controls-7
This can be done, reasonably easily. You need to follow a few rules:
load your controllers at app startup. Don't unload them. Don't worry about the memory or time, it's pretty small even for hundreds of controllers, as long as you minimize and concatenate your js.
Never use the refs or views properties of a controller. You are going to use one instance of a controller, but multiple instances of views, so you never want a reference to a view.
only use event listeners in controllers. You are only going to listen to events on your views. You can always get a (temporary) reference to a view in the event handler via the "cmp" parameter in the handler.
To "launch" a view, create it and add it to another view. To destroy it, destroy it. You don't use a controller to launch a view. You can use the afterrender and beforedestroy events in the controller to add logic.
In ExtJS' MVC the controller is a Singleton for you view. I like how DeftJS thinks about MVC. Each instance of a view has an own instance of a controller. In this way you can put all "controlling rules" in a controller for a particular part of your view, and this will be instantiated only when the view opens.
I did not have any experience how I could use multiple Defts JS apps in the same project.
Of course. What led you to believe otherwise?
Here is an example of creating a custom View which extends from a Window component. You can run this method many times from the same controller and each time you will get a new instance of a View.
"this" refers to a controller that code runs in:
this.getRequestModel().load(requestID,{ //load from server (async)
success: function(record, operation) {
var view = Ext.widget('requestEdit',{
title: 'MyRequest '+requestID
});
var form = view.down('form');
form.loadRecord(record);
}
});
How do you create your views? I see no reason why you cannot pass a different store or config data to every object. Some code samples would help for what exactly you are doing. For example, we have a similar sounding application, and everything is done with extensions. So, if we need a grid, we run
Ext.define('MyApp.grids.something',{
extends:'Ext.grid.panel'
//...
These classes are predefined. Then, when a controller or view is loading this grid, they are using
var grid=Ext.create('MyApp.grids.something',{id:'unique',store:mystore});
As you can see, we can pass in different config options to the same grid each time it is created. We can treat this exactly as you would treat
Ext.create('Ext.grid.Panel');
Except of course that we make some options predefined, and some non-override-able, and so on.
Hope this helped.
Check out this post. The idea there is to take some configuration (like store and itemId) from view config and put it into the viewport config:
// .../app/view/Viewport.js
Ext.define('MyApp.view.Viewport', {
// ...
items: [
// ...
{ xtype: 'testview', store: 'Store1', itemId: 'instance1' },
{ xtype: 'testview', store: 'Store2', itemId: 'instance2' }
]
});
The problem with store will be solved, obviously. Different itemIds will enable you to handle events properly.