Is there a dojo/dijit method to which i can pass a widget and get the inheritance hierarchy of that widget.
getInheritanceHierarchy(dijitWidgetInstance)
which will return the inheritance hierarchy in some format (json or array).
I checked the doc. Say for example, i want to find the inheritance hierarchy for dojox.grid.TreeGrid.
The doc says "Object » DataGrid » dojox.grid.TreeGrid", but when i click on the Datagrid link there, it goes to error page.
This prints the inheritance chain in reverse order:
dojo.forEach(MyClass._meta.bases,function(b) {
console.log(b.prototype.declaredClass);
});
Replace MyClass with instance.constructor when using instances.
NOTE: This is likely to change or break and should not be used in production code! Useful only for debugging.
Related
I have been going through the testing tutorial on the angular website. I am curious if there is a listing of all of the items that are available for test through the debugElement. For example
let nav = fixture.debugElement.query(By.css('h1')).nativeElement;
expect(nav.innerText).toBe(fixture.componentInstance.homeHeader);
What other elements are there like the innerText value that I am testing.
Thank you for any help.
The list is too long. These are native JS DOM elements It depends on what type element it is to get a complete list of properties. You should learn to navigate the MDN site. Here is a link to HTMLHeadingElement (this is what an h1 is). If you look at the sidebar, you will see
Properties (missing from HTMLHeadingElement, see below). This is a list of all direct properties of this element (see parent for inherited properties)
Inheritance. This is inheritance the hierarchy for HTMLHeadingElement
EventTarget
|
Node
|
Element
|
HTMLElement
|
HTMLHeadingElement
You can click any one of those links, and you will see the inherited properties. For instance, if you click on Node, you will see that that's where the HTMLHeadingElement gets the innerText property from. If you go back to HTMLHeadingElement, you will see that it has no direct properties. That means that all of its properties are inherited from its parents
Methods (missing for HTMLHeadingElement, see parent for inherited methods)
Events. These are all the events that can be triggered for the element
Related pages for HTML DOM. This is a list that is common to all the pages. You can see a list of all the different kinds of DOM elements. You can click through them. For the most part though, most of the properties you will use from any of the DOM elements will be inherited properties from the parent. So you probably want to just look at the parent properties list. Though some do have their own properties.
Those are three concepts on Yii that I really don't get what should we use, on what scenarios?
Can anyone be kind enough to clarify those Yii elements, and on what situation should we use them?
In documentation of CForm one can read the following:
...we can divide a form
in two parts: those that specify each individual form inputs, and
those that decorate the form inputs. A CForm object represents the former part...
...and CActiveForm represents the latter.
In other words, CForm specifies elements of the form but CActiveForm (being a widget) renders it.
Looking at the source code we state that CForm can also render() itself and its rendering relies on and is wrapped by CActiveForm widget by introducing its configuration property activeForm, though rendering input elements and buttons is implemented by its own methods renderElements() and renderButtons() relatively. By default their implementations rely on classes using CHtml's static methods what is exactly the same (or almost exactly the same) what CActiveForm's rendering methods do. Of course, default behavior can be overriden by extending the class.
That's why it's the question of a taste which technique to use: CActiveForm widget alone combining form fields' and buttons' declaration with their representation in a view file by calling convenient (required) methods of CActiveForm instance or CForm class declaring form's input specifications in a separate configuration file and customizing its rendering by pointing at appropriate active form widget and/or by overriding default rendering methods. The latter technique allows to reuse a form in several actions easily and is no more than using form builder.
Check here for live examples of ActiveForm, CForm, et cetera. You can also see the live Model, View & Controller files.
I have parent class Parent with method getToken(). And I have its child class - ChildA and ChildB, which don't override method getToken().
How I can search usages of method getToken() which used by instance of class ChildA?
Sorry for my English. Thanks!
As I spent half an hour to find the exact solution through all complicated and outdated documentations and examples, I just put the full answer using SSR here (Intellij 15.0.5):
Open SSR dialog (Edit > Find > Search Structurally...) and input template in screenshot, then click on "Edit variables..." to see the second dialog and edit the "Expression type (regexp)" as shown:
and if you want to include subclasses of ChildA too, just check the box "Apply constraint within type hierarchy" bellow the expression type:
You can add getToken() to ChildA, perform the search only for this method, then delete it. Another way is to use Structural Search and Replace.
Intellij asks about this if you use Ctrl+Alt+Shift+F7 for the search. First you have to explicitly override the method in the subclass/subinterface though, as CrazyCoder suggested.
I was experimenting with Dojo and Dijit in the past days and I find it quite interesting. I was however trying to find a reference or an API doc that helps me understand all the properties I can assign to widgets and containers.
For example a Tab with a Save Icon will be like this:
<div data-dojo-type="dijit.layout.ContentPane" title="Group Two" data-dojo-props="iconClass: 'dijitEditorIcon dijitEditorIconSave'">
Now, where can I find what to put in the "data-dojo-props" property? Where can I find for example all the list of icons?
My main question would be for example on how to create a vertical menubar, but beyond odd examples scattered here and there, the api reference is not much helpful...
Any help? Am I missing something here?
For this kind of situation, the trick is learning how to convert between the programmatic Javascript style and the declarative HTML style (and sometimes also between the old declarative style, without data).
For the new declarative style, basically the only "real" argument now is data-dojo-props and it consists of an object that will be passed to the widget constructor.
//programatic style
new dijit.myWidget({foo:'a', bar:'b'});
//declarative style
<div data-dojo-type="dijit.myWidget" data-dojo-props="foo:'a', bar:'b'"></div>
You can find what properties an widget accepts by checking the corresponding widget documentation and looking for either declarative or programmatic examples (now that we know how to convert between them). If that is not enough, you can also check the source code - it is usually very well commented and is where api.dojotoolkit.org gets its data from anyway.
I need to know if I am going about something the right way.
For a given page, I am instantiating an object for the page itself. Let's call that object myPage. Within the page I have containers (usually div tags). When I go to an admin component to work with a specific div, I instantiate an object for that as well. Let's call that myDiv.
Now, one of the things I want to work with for a given div is the styling of that div. So normally I would think that I'd just put in some style-related methods, such as myDiv.getPadding() or myDiv.getBackgroundColor(), etc.
But it occurs to me that I may eventually have other objects for which I may also need to do style-related stuff.
Given this, should I then create a separate style.cfc? Would that then be extended by the div object? Or would the style object extend the div object? My understanding is that the more specific object extends the less specific one, but I am not sure which is more specific in this case: is it the div object, which references a specific div, or the style object, which provides a specific set of data?
Thanks in advance!
First, unless you need to write styles on-the-fly, I would create one or more stylesheets and link them dynamically, instead of creating them dynamically.
Assuming, however, that you do need to create them on-the-fly...
I would not have either the control (div) extend the style or vice-versa. A style is not a more specific definition of a div, nor is the reverse true. What I would do is create a style object that only contains the display meta-data for a given element or element set. This can be contained within your control/div object (not an extension), or can be part of the page object. The style is definitely related to the control, but I would not combine them, as that makes it harder to separate content and presentation.
By no means am I saying this is the best approach, but if you really wanted to use CFCs to style your pages, you could have a DivTag.cfc extend an HtmlTag.cfc, which would act as your base class for all HTML tags. You could then compose a StyleAttribute.cfc into your HtmlTag.cfc to work with any style properties, such as background colors and padding. So then you would end up calling functions like myDiv.getStyle().getPadding().
In general, you should really try to favor composition ("has a") over inheritance ("is a") and not get too crazy with your component hierarchies. In this case, I'd recommend using CSS files to style your pages.