I have a Command bound to my MainWindow via CommandBinding to the Delete key.
I want that, depending on the context (which element is active), the same command would be translated to different delete commands that semantically delete things.
In few words, I want that pressing the Delete key will delete things depending on where the focus is at that moment.
I have heard about CompositeCommands (PRISM), but I don't know whether that is useful an easily applicable here.
Thanks a lot!
CompositeCommand in Prism helps you register several commands in one, so that all can be called at the same time.
Since you use MVVM, you should have a ViewModel for each kind of object at least. If you have something like a ViewModelBase or an IViewModel, you could simply add a command to it, and initialize it differently in each ViewModel.
Related
I am building simple crud for an entity. Initial state is read on particular entity(key) using view>form.bindElement('/entity(key)').
when I click on new button I clear the form and when the cancel button is clicked during the new/create process(without performing the save), how to go back to the previous entity. Is there some place ui5 stores, the previous entity or should I have some variable and assign it to the controller.previousEntity = oldsPath?
what are the different members in the oModel,it start with
a(aBindings)
b(bUseBatch)
m(mContexts)
o(oHeaders)
p(pCallAsync)
s(sPathUrl).
Is there a naming convention in these?
From what I can see, there are following things you need to notice and work upon.
Its generally not a good idea if you use the same form to display and to create/update also. A simpler approach would be to
use a new popover to show the form for create and in that case, the view binding would not be changed when you cancel the operation.
However, if you still want to use the same form, yes you would have to bind the view/form again on cancel operation. You can have a variable declared in the Component.js to store the path for you. In UI5, the model captures the current state to ensure the back the binding concept by default.
You can check all properties and their definitions here: oData Model
Yes, there is a naming convention followed here.
a - Array, s-String, b- Boolean etc.
Read more about Hungarian notations for naming conventions
The previous entity is still there in the cache (ODataModel.oData), but you'll need to re-bind it. For that purpose, as you have written, you'll need to store the path to the entity yourself. Once you bind the control, I don't think the previous binding context is stored somewhere (why should it).
With intellij idea, how do I find out what makes a variable be visible?
An example of when it is hard:
Suppose you look at class A, and you see a variable something. If you jump to source you see that it's defined in trait X. But you don't extend trait X directly. What do you extend, then, that makes this variable visible? If you have a deeply nested hierarchy, tracking can be hard.
Any recommendations or solutions?
EDIT: Please vote for the feature if you're interested: http://youtrack.jetbrains.com/issue/IDEA-124369
I don't think that IntelliJ IDEA has any shortcut for "finding what makes a variable visible".
However you can determine it using the "Find Usages" option (Alt + F7). For example:
import java.nio._
object TempObj extends App {
def func = 2
val p = file.Paths.get("some-path")
func
}
So Find Usages on "file", tells you that its from the Package "file" (in heading of the new Tab it also shows the complete package name, ex: Find Usages of java.nio.file in Project Files).
Whereas Find Usages on func will tell you that its a Method (And the Tab heading now says: Find Usages of func() in Project and Libraries)
So now in way you can determine, what exactly makes the variable visible. This also works for imports since it shows the package from which it is imported and you can then look for import of that packages.
I know of two almost-solutions to this problem.
Go-to-declaration, as you mentioned, solves this problem in the case of local variables.
More generally, the "find usages" feature gives you a neat little breakdown by type and file of different uses of the variable. From this you can see if it's involved in a static import.
It's not perfect, but with a moment's thought these two are generally sufficient to figure out what you want.
Use ctrl+b or F4 to jump to source code. Alternatively you can use ctrl+shift+a to get option/action. You can find shortcuts at http://gaerfield.github.io/ide-shortcuts/ as well. Hope it will help.
From what I understood you want to see the code that creates an Object you use, for instance Mystery someMystery;.
That gives you two options to populate someMystery:
someMystery = ... where ... is your code to populate
someMystery and if that is the case you should follow
that code (with ctrl+B as far as you need to) to the point where it
actually creates the Mystery object.
Use CDI to populate that object instance for you, in which case you should look into the CDI mechanism in order to see in what way the object instance is populated.
In either way IMO there is no way to know for sure if the someMystery instance is of some more concrete class than Mystery, because it is decided in runtime, not in compile time, so your next bet would be to run the program in debug and see what object goes into someMystery, although you are not guaranteed to get the same type of object every time.
PS. My answer is based entirely on my java understanding of the topic, can't say if it is valid for scala also.
This might not be exactly the answer you were hoping to get.
However, quoting yourself,
If you have a deeply nested hierarchy, tracking can be hard.
Have you considered using composition over inheritance? Perhaps this would remove the need for the feature you are looking for.
Deeply nested hierarchy doesn't sound good. I understand your pain about that.
When you override vals or defs there is a little circle next to the line number that shows where it is from even when it is from nested hierarchy. Hovering over vals with the command key down also shows you a little tooltip where it is from.
Does this help?
https://youtu.be/r3D9axSlBo8
if you want class, field or method to be visible, you need to implement them as public. If it was your question.
In my app, I have a presenter (Presenter1) which I use to kick off an Editor (EditorView1) which edits a Foo object. This MVP setup is akin to what is described in this answer, https://stackoverflow.com/a/10699346/565863
Now, let's say that I need to create another view (EditorView2 which is kicked off by Presenter2) which also edits a Foo object, but needs to make use of EditorView1.
EditorView1 would be supplied to EditorView2 by Presenter1.
This approach seems sloppy and error prone. Is there another way to do this?
As I was writing this question, I realized a much more clean approach.
The problem with what is described above is that I was intent on re-using the first Presenter, Presenter1.
It would be much cleaner to abstract out the Editor portion of the EditorView1 code into a re-usable Editor widget (Editor1) which could be used by both EditorView1 and EditorView2. Now, I have one presenter, one view, and one EditorDriver. There is no need to juggle nested presenters or multiple EditorDrivers.
When using the objectContribution-element (which is part of the org.eclipse.ui.popupMenus-extension point), I often (practically always) want to delegate to some command instead of implementing some action myself (since usually, I have the command and a handler already implemented). I'm doing this by using ICommandService and IHandlerService, but it feels there should be a way to achieve this programmatically. I could use viewerContribution instead of objectContribution, but then I would lose the easy way of showing the menu entry only when certain object types are selected. Ideally, I would like to use the enablement-checks that already exist for my handlers to apply to the menu entry defined by the objectContribution.
Ok, here's what I was missing: instead of using the org.eclipse.ui.popupMenus-extension point, I had to use the org.eclipse.ui.menus-extension point with a menuContribution that has its locationURI-attribute pointing to popup:org.eclipse.ui.popup.any?after=additions. This menuContribution can include a command-element (achieving the goal of binding directly to an existing command), and this command-element´s visibleWhen-element can be bound to the activation status of the bound command's handler via the checkEnabled-attribute (achieving the goal of having the popup-menu entry visible only when the enablement for the command handler is satisfied).
What's bad is that the documentation of the org.eclipse.ui.menus-extension point states that the org.eclipse.ui.popupMenus-extension point is to be considered deprecated, but the documentation of org.eclipse.ui.popupMenus does not mention this fact.
I have a custom node type for which I want to have a field that uses a special combobox based on list_text. When one chooses the type list_text it is normally possible to enter a static list of selectable texts, however, I want this list to be dynamic, i.e. based on the results of a db_query. What is the best way to do this using Drupal 7?
A simple example for clarification: A node of this custom type X contains a field that points to another node, so whenever a node of type X is created I want a combobox that contains all other nodes.
(Best solution would be to only display the combobox during node creation, and no longer during edit. But I could also live with it if the combobox was shown during the edit as well.)
I have tried to customize options_select by defining my own data type and implementing hook_options_list accordingly. The combobox was displayed during creation with the correct values, however, I could not save it.. I have no idea what went wrong there, but on the first submit it would change to a different theme, and when I tried again I got an internal server error. Am I on the right track at all with defining a completely new data type for the field? there surely must be a simpler way?
You're right in that you don't need a new datatype. Here's a good tutorial on how to do this. It's not specifically for D7 but I didn't see much that wasn't still applicable. There may be a better way to do it in D7 specifically but I would love to know it too if so :)
The tutorial linked by allegroconmolto sent me on the right way. Thanks for that.
Here's the simpler way of doing it: tutorial
Basically, it is, as I assumed, a common problem and hence a simple solution for it was included in the webform module by now. It provides a hook_webform_select_options_info which can be used to register a callback method. The callback method is then called each time a corresponding option select of a webform is shown, so that you can easily fill it with the results of a dbquery or anything else. Works like a charm and takes next to no time to implement.