In Wagtail, StreamBlock and StructBlock seem to serve the same purpose, which is to nest other child blocks in a parent field.
When to use one versus the other?
Use StructBlock if you have a known, well-defined set of sub-elements to include in a block.
Use StreamBlock when you want an variable number of content items of mixed types.
Related
Inside the agent, I have seen uvm_component creation like
apb_monitor m_monitor;
m_monitor=apb_monitor::type_id::create("monitor_name_aaa", this);
m_monitor.analysis_port.connect(analysis_port);
Here we can see that when referring to the hierarchy, we still need to put m_monitor.* rather than monitor_name_aaa.*.
My questions are
What is exactly the purpose of this name property 'monitor_name_aaa'
for?
I have seen in many places people says best way is to put the name = 'm_monitor', same as the m_monitor. If this is true, then why not the methodology just built in this feature directly?
Another point is that If I do get_type_name(), then I see the it is using the name property, like m_env.m_agent.monitor_name_aaa instead.
Thanks!
In UVM it is useful to be able to refer to components either using their SystemVerilog hierarchical name directly or as the string equivalent. (There's the answer to Q1.) Unlike in VHDL, in SystemVerilog there is no way of finding out what the name of a variable is. So, when you create a component, you have to manually set this up. (There's the answer to Q2).
As you point out, you must always make the name of the component the same as the name of the variable pointing to it ("m_monitor" in this case), otherwise you will not have this useful ability to refer to components either by SystemVerilog hierarchical reference or by the equivalent string.
Cypress and many other posts around testing web applications suggest relying on a data attribute like data-cy or data-test-id for locating elements rather than relying on the id attribute.
My understanding is that for two reasons:
The modern way of re-using the components can lead to having multiple components of the same type and can lead to multiple of those IDs on the same page - But this should also apply to the 'data-cy' or 'data-test-id' attributes.
When IDs are tied to CSS, there's a tendency to change them more often while data-* attributes may be less prone to change.
Can someone please throw more light on the recommendation?
The other thing I am considering is to request my devs to place the data-test* attributes on a div tag that would consume the component - that way the test attribute is actually one level above the component id attribute and may come handy even in cases where multiple instances of the same component are used. But again, I am not sure why the id attribute for that div tag is bad when compared to the data-test* attribute.
From Cypress official docs:
Anti-Pattern: Using highly brittle selectors that are subject to change.
Best Practice: Use data-* attributes to provide context to your selectors and isolate them from CSS or JS changes.
Every test you write will include selectors for elements. To save yourself a lot of headaches, you should write selectors that are resilient to changes.
Oftentimes we see users run into problems targeting their elements because:
Your application may use dynamic classes or ID's that change
Your selectors break from development changes to CSS styles or JS behavior
Luckily, it is possible to avoid both of these problems.
Don't target elements based on CSS attributes such as: id, class, tag
Don't target elements that may change their textContent
Add data-* attributes to make it easier to target elements
The point is that id's and classes can be dynamic (also text-content) so you always want to use a selector that is static like the "data-cy" attribute.
Since id attributes are rarely used in Reactjs components due to the fact that id attributes imply that the component will not be reused, then are className attributes used instead of id's? If this is the case, then what is the Reactjs equivalent of the class attribute in HTML?
className is used for class names for CSS styling, just as elsewhere.
You can give something a unique className for styling purposes the same way you might give otherwise give it an id, sure, but that doesn't really imply anything else for other className usage, which can never really be a direct equivalent to id because className can contain multiple class names, none of which have to be unique. (There are also pretty good reasons not to use id for styling, regardless of React).
A more usual reason not to give something an id with React is that you rarely need to add hooks to go and look up an element from the real DOM, as you can use state or props to control rendering changes which do whatever dynamic stuff you need to do, and if you do need to go grab an element, you can give it a ref name and use getDOMNode() on it.
To add to insin's answer, ids do have practical uses, but styling is not one of them.
The two cases are fragment identifiers, and input/label pairing. In that case, you usually want to generate ids that are guaranteed to be globally unique (but consistent across renders). For that, use a mixin like unique-id-mixin.
First of all, ids are used with React, and they don't necessarily prevent re-use. For instance, if you'd want to use a element then you'd have to give it an ID (so it can be referenced from the "list" attribute of its tag). In that case, I usually auto-generate an ID using a counter variable. Hence, IDs and re-use don't have to rule each other out.
To answer your question, the className attribute is used instead and works just like the class attribute. The "react/addons" module provides a utility for easily creating className values.
ID's are for single use (in React and in general) or one-time instances.
classNames are for multiple usage (in React and in general) or for many-time instances - the same way that classes are used in traditional CSS.
I'm trying to write a common test module for a localized application.
The first issue I'm having is the fact that MenuItems do not support controlname attributes. Currently my menu items are located via text or accessiblename attribute. Is there a way to support controlname attribute?
I've tried to make text and accessiblename attribute point to a variable and then bind the variable to some external dictionary. As I understand the external data sources are treated as rows which contain various data items for a single variable. I don't see a way to use external data sources that treat first column as variable name and second column as variable value. Is there a way to achieve such functionality?
I've thought about a way to extend RanorexXPath to accept functions. Then I could write something like ...menuitem[text=localizationService.Translate("#ADMINISTRATION") and have Ranorex find the menu item based on the result of localizationService.Translate function. Is there a way to do this?
Finally I've somewhat managed to get the result I need by using global variables and module variables. What I did was create a module that uses localizationService to fill module variables with correct data. Next I bind the module variables to global parameters and use the data in subsequent test. This is quite error prone and difficult to implement for large number of variables. Is there a way to access and set global variables directly from code (without the need to use binding)?
If any of the 4. points is possible please let me know.
The recomendation from Ranorex support team:
In general only the whole menu is a control in WinForms. The elements within that control (MenuItems) can only be recognized via MSAA.
The problem is that the "Name" attribute of the MenuItems is not accessible.
As workaround I would suggest to use the attribute "AccessibleDescription" in your application in order to automate the menu. This attribute can also be used for language independent names.
I am looking for a way to access components / field that are either in the same items array as the accessing one or even only in a same parent items array (the last one is just a option).
In ExtJS3 this was easy by simply defining a ref in the owner container but I didn't found anything like that in ExtJS4.
I know that I can use Ext.ComponentQuery() or the shortcuts up() / down() or even Ext.getCmp() but they are all not what I am looking for, cause they just executes a bunch of code while the ref was such an easy Way to do things.
Yes, I am aware of the fact that using a ComponentQuery is much more fail safe than the use of hard coded references. But I just want to know if there are some other ways to do this.
Alternately, for your case of getting the next element in a container, you can use the nextSibling or prevSibling. All components have these methods. It would be a little less walking around the DOM structure. They also allow for a selector argument.
They are described in the docs here.
Here are some tricks I have used:
//lookup by name
formPanel.getForm().findField('state');
//lookup using nextSibling/prevSibling in a fieldset or fieldcontainer
myField.ownerCt.nextSibling('textfield[fieldLabel=Description]')
Here fieldLabel property is used to narrow down field selection but you can use ANY property at all. So if you construct a field with a property ref you can then use it to select your field similar how you would use it in a ComponentQuery .