I would like to hide some tree nodes in the match results of EMF Compare, since they are just containers with no meaning to our users.
I have tried two approaches, but both result in some unwanted side-effects.
Using a more narrow scope
Details: https://www.eclipse.org/forums/index.php/t/781759/This
results in the separate diffs being available, but without the
enclosing tree structure of the model.
Using a post processor to remove some container objects from the tree of matches.
Details: https://www.eclipse.org/forums/index.php/t/781794/
This is more of a success in that the resulting tree structure is exactly what I'm after. This however breaks navigation in the bottom pane.
I'd be really happy if someone could have a look and see what my attempts are missing.
Thanks,
Mattias
I got a reply in the Eclipse forum. An EMF Compare core dev let me know that this is not possible without breaking behaviour as I described.
So for the rest of you trying: no dice.
I've been working with ExtJS for a good few months now, but still don't have a perfectly clear map of what's going on behind the scenes there. I'm just talking about the building blocks of the framework and their most basic functionality.
Ext.Component
Ext.Element
DOM.Element
DOM.Node (?)
CompositeElement (?)
Whatever else (?)
For each of the abovementioned I would like to know:
How to select: by ID, by class, via parent, find (OR children OR query OR select? WTF), siblings, ComponentQuery, DOM-query, CSS-query, etc..
How to manipulate in the tree: create, append, prepend, insert after this sibling, move to that parent, remove, destroy, etc..
How to manipulate on the screen: show, hide, fade, slide, move up, down, change size, etc..
How to identify related to each other: find DOM.Element knowing its Ext.Component, find Ext.Component knowing its DOM.Element, etc..
What is the dependency between them: what happens to the DOM.Element if its Ext.Component is hidden / destroyed / changed / moved, what happens to the Ext.Component if its Ext.Element is hidden / destroyed / changed / moved, etc.
I'm looking for a methodical and logically clear layout of how each is supposed to be used and is expected to behave. I am also hoping that the described functionality can be grouped in corresponding categories, e.g. would be nice to see complement traversing methods .up() and .down() next to each other, rather than alphabetically pages apart. Of course links and examples (which the official documentation lacks so badly) are also welcome!
You can find out a whole lot about the building blocks of ExtJS (known as Ext Core) from the manual for this: http://docs.sencha.com/core/manual/. I will try to add some knowledge and highlight some key points, but you should definitely read through that for a very informative overview.
Ext.Component
The building block for the OOP paradigm within ExtJS. Essentially, this is an Object that contains inherited functionality to serve as the basis for a specialized component that will be transformed by the framework into DOM elements that are shown as HTML.
The Sencha documentation is excellent for this. Here are a couple good places to start:
http://docs.sencha.com/extjs/4.2.1/#!/guide/layouts_and_containers
http://docs.sencha.com/extjs/4.2.1/#!/guide/components
Ext.Element vs DOM Element
As an JavaScript develop knows, a DOM element is just a JS object that represents a tag in the document's HTML. Essentially, Ext.Element is a wrapper object for a DOM element that allows for ExtJS to manipulate the object. Any DOM element on the page can be wrapped as an Ext.Element to allow for this additional functionality.
For example, take this HTML tag:
<div id="myDiv">My content</div>
You can access this using
var el = document.getElementById('myDiv')
and use the basic, built-in JavaScript DOM functionality on el. You could also access this using
var el = Ext.get('myDiv')
and have a whole additional set of functionality available to apply to that element using the ExtJS library
The Sencha docs are also excellent for this. See all the available functionality for Ext.Element here: http://docs.sencha.com/extjs/4.2.1/#!/api/Ext.dom.Element
Misc
You can get an Ext.Element from a component using the getEl() method:
var myComponent = Ext.create('Ext.Component', { html: 'my component' });
var el = myComponent.getEl();
You would rarely need to go the other way, to determine a component from a DOM element. There isn't much of a use case there unless you are really hacking something. A major reason for using a framework like ExtJS is to prevent needing to do something like this; if should develop entirely within the JavaScript, you should be able to avoid having a reference to a DOM element where you need to get its containing ExtJS component.
Niklas answered pretty well about how to select components and elements. The only things I would really add is that you can use up() and down() to select relative to a component. In this way, you should use itemId on components rather than the global identifier id (using id can cause difficult-to-debug errors if you are reusing components with the same ID).
Also, to add to Niklas's answer about showing/hiding components, the framework does indeed add some CSS to the component's element, depending on what the hideMode for the component is. Learn more about that property here: http://docs.sencha.com/extjs/4.2.1/#!/api/Ext.AbstractComponent-cfg-hideMode
An excellent way to learn more is to look through all of the examples that come packaged with the framework. Open the examples in your browser, then look through the code to find out how things are done. You will find it way easier to learn this way, rather than reading it on paper or a website. Nothing beats experience when it comes to learning something new.
How to select: by ID, by class, via parent, find (OR children OR query OR select? WTF), siblings, ComponentQuery, DOM-query, CSS-query, etc..
Ext.ComponentQuery.query("*") // get all
Ext.ComponentQuery.query("button") // all buttons
Ext.ComponentQuery.query("#myid") // all controls / components myid
Ext.ComponentQuery.query("#myid", rootelement) // all controls / components myid with rootelement
Ext.ComponentQuery.query("#myid,button") // all buttons or controls / components myid
How to manipulate in the tree: create, append, prepend, insert after this sibling, move to that parent, remove, destroy, etc..
Adding button to a View:
Ext.ComponentQuery.query("#viewId")[0].add(new Ext.Button({ text: 'test'}));
There is also insert, remove and so on depending on the control you are querying.
How to manipulate on the screen: show, hide, fade, slide, move up, down, change size, etc..
Ext.ComponentQuery.query("button").forEach(function(button){ button.hide(); }) // hide all buttons
There is also show, disable, enable and so on depending on the control you are querying.
How to identify related to each other: find DOM.Element knowing its Ext.Component, find Ext.Component knowing its DOM.Element, etc..
Finding Ext.Component knowing its Dom.Element is pretty easy, you just take the ID from the DOM element and use Ext.ComponentQuery.query("#id").
There is also Ext.select('#id') for getting the object from an ID.
With the element property you can get the DOM:
var dom = Ext.ComponentQuery.query("button")[0].element.dom // Getting the DOM from the first button
var dom2 = component.element.dom // does also work as long as component is a valid sencha touch component
What is the dependency between them: what happens to the DOM.Element if its Ext.Component is hidden / destroyed / changed / moved, what happens to the Ext.Component if its Ext.Element is hidden / destroyed / changed / moved, etc.
I think, I'm not sure, that if you call .hide for instance there will be some CSS applied to the DOM for example: display: none. Internally they can use some framework like jQuery for that or the old school version document.getElementById('id').css and so one. If you call .show, it may change to display: block or whatever type it was before(this could be saved in the Sencha Touch class).
I don't know what happens if the DOM element gets destroyed. Probably the element too and then the garbage collector has some work to do.
If there are any more questions / something was unclear or not enough, don't hesitate to ask.
An attempt to answer the question myself.
Since there is no TABLE markup support on this website, I put my answer in this shared Spreadsheet. Note the comments on mouse rollover.
It's just a pattern for now. It needs work to get more legible and complete. Feel free to comment, or ask me if you would like to edit it.
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.
I'm interested in approaches that avoids code in the code behind.
In my opinion, there are some cases where code must be placed in the code behind.
For example: I have a grid with an undefined count of columns. Columns can't be binded. So the easiest way would be to generate the columns in the code behind.
For this case, I can create a new class which inherits from the grid. This new class has a new binding property and code for the column binding. The code is separated in a custom class which can be used in the XAML. And then, I can easy bind the columns to my newly created property. And the view has no code behind.
Is it a good idea? How would you solve such (or similar) problems?
Are there other ways to extract the code from the code behind?
Thanks.
Having a code behind free xaml.cs and moving to code to a new class does not mean its pure MVVM. The idea is you will have all the logic in ViewModel hence a code behind free View, helping in Unit Testing. View specific logic like colors and animation cannot be unittested hence doesnt matter where it resides, in an custom control or a inherited control or directly in xaml.cs. As long as you are testing most of the user interactions and view logic via UnitTesting, you should be happy that you have done a good job.
I have a list of widgets which needs to be sorted. I want to create a container for these list of widgets to re-sort them each time new widget is added. How can I do it?
I can see the following ways:
a straightforward way is place them into arraylist and sort via Comparator, but after a new element is added we have to remove all list from container and add them again, in a new order.
use some sorting container. i have found only CellTable for this. But actually I dont need its rich functionality - I have only one column, dont need to sort on user events, only when new element added or removed, - so is there something else I can utilize in my use case?
GWT 2.4
PS
Actually, I am looking for something, that can be expressed like "widget container backed by widget collection", i.e. I change collection - container changes its contents, how can I implement this, or where can I find it?
PPS
The widgets can be different, thats why I dont think I can use CellTable easily.
There is no straightforward way of re-sorting the elements in the DOM after you add a new widget.
When the widgets are attached you cannot just move them (change their position in the document structure) without detaching and re-attaching.
Well, with absolute positioning you can just change the left-top coordinates to move the items, if it is what you need.
I had a similar problem to solve when I had to sort TreeItem elements (no built-in sort method available). As a workaround, I read all the children into the list and remove them from the parent widget at the same time, then sort these items using Comparator and add them back to parent from the sorted list. Everything is in a single sort() method, which encapsulates all required functionality and kind of simplifies understanding of this code.
"widget container backed by widget collection"
I would like to learn about one like that that also can do sorting and re-attaching on the fly. But it still will be backed by the same detaching-attaching I assume. I would recommend you to write one yourself, that will fit your particular needs. Either you need a Tree or a FlowPanel or anything else - you can extend that and add sort() logic according to context. And override add() method accordingly. So, your first option looks like a possible solution to me.