I am trying to add some user information to the nodes of the branch-and-cut tree in SCIP and when branching is performed on the node, I want the child nodes to inherit the same information as the parent. I can access the nodes via an event handler but I could not find a way to attach information to nodes. Thank you.
You could create a hashmap in your event-handler and store the data that you want to save there.
Related
I looking for feedback regarding how I am implementing Vue components.
I have a Vue instance that contains a list of orders and a reference to the current order. Let’s call this root instance "orders".
When the current order is set (based on clicking on one of the orders in the list), I create a new component inside "orders" called "current-order". "current-order" has a property that the parent passes it called "order_id", this property is used within "current-order" to recall the data for the order and present an editable form.
Within "current-order", besides the meta-data associated with the order (customer, etc), I have a third component to contain a group of items, let’s call this final instance "item-group".
Here is the general layout of how these instances would look:
orders
current-order
item-group
item-group
item-group
"orders" only saves a list of the orders; it does not save any order data.
"current-order" saves the meta-data associated with the order, as well as the item data.
Discussing this model with a co-worker, he explained to me that this is not the best-practice way to implement this. He felt that the proper way to implement this would be to save all of the data for all of the components on the root instance "orders", versus the way I implemented it - data saved at each level.
The model he explained seems less maintainable to me. "current-order" may be used on other pages of our application, so if I maintained its data in the root instance, I would have to do that in all of the root instances that I attach it to.
With the way I have implemented it, all you have to pass the component is an order_id, and it will fill itself with data.
He continued to explain to me that saving data on the component like I am doing can be reset by re-renders of the instance, which I didn't quite understand.
Both the way I implemented, and the way he described would work, but I'm trying to find out what the best-practice approach would be for maintainability.
Note: This is not a large SPA, and I don’t think Vuex would suite what we are trying to achieve right now.
Any feedback would be appreciated.
It all depends on what your child-components are responsible for. If a child is extending the functionality of your parent component then the state should always be maintained in your parent component. For example in a CRUD based situation instead of creating separate components for create and update you can write only one and maintain its state (updated/created) in your parent component.
If in your current-order you are not updating anything related to the order then no need to maintain its state in your order i.e. if meta-data can be treated as a separate entity of your order no need to maintain it in the parent. But in case both order and its meta is one single entity, you should maintain its state in your parent.
I need to replicate from one read/write Pimcore instance to another Pimcore instance read-only.
Is there a smarter way to achieve that than
- replicating the database (master slave model)
- "rsync"ing the media and class file system folders?
There are APIs to export and import contents and structure, but is this reliable with high volumes ?
Thanks
Possibility 1:
Never tried this, but you could post the object / asset / ... to an controller on the other instance. To do that, you need to extend the save-function of all objects or hook into the save event.
On the "slave" instance, you can then check if an object / asset... with this path and key exists, then update, otherwise create a new.
Possibility 2:
Do it with polling: Instance A tells B about it's objects, ... via a controller. B then iterates and clones it.
First, thanks for any advice. I am new to all of this and apologize for any obvious blunders.
Second, the question:
In an interface for entering clients that often possess a number of roles, it seemed efficient to create a set of inputs which possessed both visual characteristics and associated data binding based simply on the inputs name.
For example, inquirerfirstname would be any caller or emailer who contacted our company.
The name would dictate a label, placeholder, and the location in firebase where the data would be stored.
The single name could be used--I thought--with a relational table (state machine or series of nested ifs) to define the properties of the input and change its outward appearance and inner bindings through property manipulation.
I created a set of nested iffs, and console logged the property changes in the inputs, but their representation in the host element (a collection of inputs that generated messages to clients as well as messages to sales staff) remained unaffected.
I attempted using the ready callback. I forced the state change with a button.
I was unable to use the var name = new MyInput( name). I believe using this method would be most effective but am unsure how to "stamp" the JavaScript into a heavyweight stamped parent element.
An example of a more complicated and dynamic use of a constructor and a factory implementation that can read database (J-son) objects and respond to generate HTML elements would be awesome.
In vanilla a for each would seem to do the trick but definitions and structure as well as binding would not be organic--read it might be easier just to HTML stamp the inputs in polymer by hand.
I would be really greatful for any help. I have looked for a week and failed to find one example that took data binding, physical appearance, attribute swapping, property binding and object reading into account.
I guess it's a lot, but each piece independently (save the use of the constructor) I think I get.
Thanks again.
Jason
Ps: I am aware that the stamping of the element seems to preclude dynamic property attribute and binding assignments. I was hoping a compute attribute mixed with a factoryimpl would be an option (With a nice example).
I have been given this task and would appreciate it if someone helped really. I built a Graphical Model through GMF, which is as follows;
As you see one of the nodes in the model has been selected. The task here is to create an eclipse view with a table, which will be automatically updated upon the selection of a so-called "City Node". As you may guess from the model, the table should contain path costs to all of the cities. I will later expand my solution to include a modified Dijkstra Algorithm but right now i am stuck in the creation of a table view.
I tried to build it using a TableViewer but it seems fairly complex since we need to set the input of the table on ContentProvider, but the twist here is that since we need a SelectionListener to obtain the City Coordinates (as it was ordered to calculate path-costs through the distance between two connected cities divided by the max speed, which was indicated on the connecting streets in the graph) and also the currently selected city, the path-costs need to be automatically calculated and displayed in the table upon the receipt of a click-event. This means that we somehow need to update the input which is gonna be handed to ContentProvider on every selection change.
For further information, I get the current selection through selectionChanged method of ISelectionListener interface and inside this method I put the city information in an arraylist. However although i declared this arraylist outside of the method as public, I cannot seem to access it from the outside of the method and thus can not pass it contentProvider. Eventually the input of the table can not be updated. I tried to write this text as simple as possible and I hope you guys can help me. As I can not foresee now what should be done, I would really appreciate it.
You're on the right track!
In your selection listener's ISelectionListener.selectionChanged method you just have to set the new input for the viewer with TableViewer.setInput. Then, the IStructuredContentProvider.inputChanged method gets invoked on the content provider for the viewer. It's here where you can do your stuff with the new input and refresh the viewer with TableViewer.refresh.
You can also use the JFace databinding framework, but I think you should be fine with what I've mentioned above.
Let me begin with an illustrative example (assume the implementation is in a statically typed language such as Java or C#).
Assume that you are building a content management system (CMS) or something similar. The data is hierarchically organised into Folders. Each folder has a collection of children; a child may be a Page or a Folder. All items are stored within a root folder. No cycles are allowed. We have an acyclic graph.
The system will have a remote API and instances of Folder and Page must be serialized / de-serialized across the network. With a typical implementation of folder, in which a folder's children are a List, serialization of the root node would send the entire graph. This is unacceptable for obvious reasons.
I am interested to hear people have solved this problem in the past.
I have two potential suggestions:
Navigation by query: Change the domain model so that the folder class contains only a list of IDs for each child. To access a child we must query for it. Serialisation is now trivial since the graph ends at a well defined point. The major downside is that we lose type safety - the ID could be for something other than a folder/child.
Stop and re-attach: During serialization stop whenever we detect a reference to a folder or page, send the ID instead. When de-serializing we must then look up the corresponding object for each ID and re-attach it at the relevant position in the nascent object.
I don't know what kind of API you are trying to build, but your suggestion #1 sounds like it is close to what is recommended for REST style services and APIs. Basically, a Folder object would contain a list of URLs to its children.
The Navigation by query solution was used for NFS. By reading through your question, it looks to me, as if you're trying to implements kind of a file system yourself.
If you're looking specifically into sending objects over the network there is always CORBA. Aside from that there is DCOM and the newer WCF. But wait there is more like RMI. Furthermore there are Web Services. I'll stop here now.
Suppose You model the whole tree with every element being a Node, specialisations of Node being Folder and, umm, Leaf. You have a "root" Node. Nodes have a methods
canHaveChildren()
getChildren()
Leaf nodes have the obvious behaviours (never even need to hit the network)
Folders getChildren() get the next set of nodes.
I did devise a system with Restful services along these lines. Seemed to be reasonably easy to program to.
I would not do it by the Navigation by query method. Simply because I would like to stick with the domain model where folders contains folders or pages.
Customizing the serialization might also be tricky, bug prone and difficult to change\understand.
I would suggest that you introduce and object like FolderBowser in your model which takes an id and gives you a list of contents of the folder. That will make your service operations simpler.
Cheers,
Unmesh
The classical solution is probably to use a proxy pattern, where some of the graph is sent over the network and some of the folders are replaced by proxies that will not have their lists of children populated until they are queried. A round trip to the server takes a significant amount of time and it will probably result in too many requests if all folders are proxies (this would yield a new request each time the contents of a folder is inspected), so you want to go for some trade off between the size of each chunk of data and the number of server requests needed in a typical scenario. This is of course application specific, but sending the contents of all child folders in for instance depth 2 might be a useful strategy...
Long story short: What will probably work best is your solution #1 with the exception that you want to send more than one folder at a time because of the overhead of a round trip to the server...