Error: The component cannot contain children. If you want to render content on top of the image, consider using aboslute positioning.
<Image> with nested content is no longer supported. Looking into <ImageBackground> instead if this is something you did in our app.
<ImageBackground
style={styles}
source={source}
resizeMode={resizeMode}
>
Related
Different source trees from the same codebase are being created and thus Appium can't reach elements in iOS that are seemingly way too deep.
How can I deal with this issue?
Android:
iOS:
I tried updating the snapshotMaxDepth setting to 60 and higher (even though the limit is 60), but sadly that did not fix the issue.
Edit
Appium version 1.21.0
Technology stack used to build the app is React Native
React Native behaves differently for iOS as it does for Android. React Native has elements that are accessible. By default, all touchable elements are accessible. This indicates that the view is an accessibility element. When an element is an accessibility element, it groups its children into a single selectable component, see also https://reactnative.dev/docs/accessibility.
It can also depend on the navigation that you/your developers are using, see appium/appium#14825
How to overcome:
You can try to adjust the customSnapshotTimeout and or snapshotMaxDepth, see https://github.com/appium/appium-xcuitest-driver. Sometimes it takes to long to build up the tree and by adjusting these values you might give Appium more time to translate the tree. You mentioned you already tried it, so it might be related to the accessible elements, see next point.
You can check with the devs if there are accessible elements in your app and ask them to disable the property on those elements so React Native will return all children to Appium. This is normally only done for test builds and not for production
For those who will read this in the future and have stumbled across the same issues:
I have found that the issue itself was not because appium can not see deep enough into DOM/source tree (the issue with depth can still occur, but this was not the case for me yet). There are actually two different scenarios when stuff like this can happen and they both are to do with app code itself:
1 - Elements are nested inside a text component
Because of this appium will combine them into one text view and you won't be able to access the deeper elements. Solution is to move element out of the text component.
From this:
<Row>
<Body>
{text}
<Your touchable element>
</Body>
</Row>
To this (obviously the styling will break, but appium will see the element):
<Row>
<Body>
{text}
</Body>
<Your touchable element>
</Row>
2 - Container, row or any other parent div has pressable atributes
If any of the parent divs is considered as pressable - appium will think that that is a button and will return one combined view - by doing so not letting you to access all elements/button that are inside that container.
For example you have:
<Container>
<HeaderContainer>
<Your touchable element>
</HeaderContainer>
</Container>
const Container = styled(Pressable)`
flex: 1;
`;
In this example case appium will return a one view component - that is all mushed together. What you need to do is change accessibility to false.
This would look like this:
<Container accessible={false}>
<HeaderContainer>
<Your touchable element>
</HeaderContainer>
</Container>
const Container = styled(Pressable)`
flex: 1;
`;
By adding accessible={false} appium will now understand that this Container is not a accessible element and will now let you see whats deeper inside it.
Hope this helps for the future people who stumble across the same issues :)
I am trying to convert some inline polymer templates for grid columns, and the rendered value in the browser ends up as “NaN” for some reason.
So I simplified the template to reproduce the issue as the following:
grid.addColumn(LitRenderer.<SamplePerson>of("<span style='${item.stylename-0}'> test </span>")
.withProperty("stylename-0", dto -> "background-color: red"));
and the rendered value still says style="NaN". Is there something that I’m missing?
Steps to reproduce the issue:
Go to https://start.vaadin.com and add a Master-Detail view from the existing templates to the views.
Download the application and open it in your favorite editor.
in the com.example.application.views.masterdetail.MasterDetailView's constructor, add the column with a LitRenderer (you can copy the above snippet code as well).
Run the application, go to http://localhost:8080 and observe that the values for the manually added column hasn't been styled with a red background. Obviously, by inspecting the elements you could see the style="NaN" is rendered on the client.
Tested with V23.2.3 and V23.2.4 and the issue exists.
Nicely spotted by #leif-Åstrand, this was an issue regarding the -0 ending, which was being parsed as a mathematical subtraction in JS, and clearly resulting in "NaN".
The correct way of doing this kind of dynamic class or style values ("stylename-0", "stylename-1", ...) is to treat them as strings, so:
style='${item.stylename-0}'
should be written as
style='${item['stylename-0']}'
I have a problem using the filelist / upload element of TYPO3 at the current new version 7.6.2. I want to use the title or description part instead of the filename while rendering the list.
I found lots of information on that and in TYPO3 version 6.x it worked with:
tt_content.uploads.20.renderObj = COA
tt_content.uploads.20.renderObj.20.1.data = file:current:title
tt_content.uploads.20.renderObj.30 >
When I insert this lines into the TS of the page where I want to use the filelist it does not work with the new css_styled_content for 7.x.
When I include "CSS Styled Content TYPO3 v6.2 (css_styled_content)" to the setup of the template, the filelist works (but other parts of page not).
Therefore the question: Do you know if there are some changes in rendering the filelist at 7.x?
Thanks for your help
Markus
The reason why you can't change the name => title anymore is that you included Fluid Styled Content ext which is required i.e. for rendering the Text & Media CEtype. It massively overrides the CSS styled content and replaces (almost) whole TS declarations with Fluid templates/layouts/partials from typo3/sysext/fluid_styled_content/Resources/Private folder. I.e.: in typo3/sysext/fluid_styled_content/Resources/Private/Templates/Uploads.html:29 there is {file.name} used which should be more advanced condition...
To change it:
Copy all folders from typo3/sysext/fluid_styled_content/Resources/Private to your custom destination i.e.: fileadmin/fluid_styled_content/Private (this is for avoiding loosing of your changes after system upgrade.
It can be any other path, for an instance you can create your custom ext and put it into typo3conf/ext/yourext/Resources/Private/...
Go to your TypoScript template > Constant Editor > Category: Content and set new paths in these fields:
Path of Fluid Templates... - fileadmin/fluid_styled_content/Private/Templates
Path of Fluid Partials... - fileadmin/fluid_styled_content/Private/Partials
Path of Fluid Layouts... - fileadmin/fluid_styled_content/Private/Layouts
After that go to fileadmin/fluid_styled_content/Private/Templates/Uploads.html:29 and replace the code:
{file.name}
with:
<f:if condition="{file.title}"><f:then>{file.title}</f:then><f:else>{file.name}</f:else></f:if>
As you can see this way you can also change other CEtypes and their typical settings (i.e. add the responsive classes if working with RWD).
On the other hand take a look there are some drawbacks of this solution, i.e. default layouts repeats the <div id="c123">... which is invalid :/
P.S.:
Also just realized that Fluid Styled Content doesn't handle other things, i.e. different layouts for Uploads (that the first thing I saw, didn't check other CEtypes) so you need to consider yourself if it is OK for your project at the moment. I prefer to stay with old way (no need for Text & Media CE) and disable FSC now (I'm pretty sure, that soon it will be nice alternative for CSC, but not now imho :/) To revert typical state you can use these lines mentioned in the GitHub here within your PageTS.
At the following link there is a cheatsheet for Adobe Experience Manager (AEM formerly CQ).
http://activecq.com/system/assets/46/original/quick-reference.html
There is a section on the page called "Component Organization"
At the bottom of the list are two sections: views and partials.
My first question is, what would the x and y represent and is there some built in mechanism that already exploits this convention?
If a page included content where this component was the resourceType and the appropriate selectors were in play then those x and y JSPs would also be in play. For instance,
/content/mysite/mypage.views.x.html
But that seems strange. A more likely scenario is that the component is targeted through a sling include that adds or replaces selectors.
<sling:include resourceType="/apps/myapp/components/sample"
replaceSelectors="views.x" />
So what is the intended usage of this feature?
I could be wrong, but I believe the partials folder is referring to this: https://github.com/Adobe-Consulting-Services/acs-aem-commons/issues/10
The idea seems to be to break up the component into inheritable sections for ease of use and development of siblings of the parent.
I want to include a spark view in another spark view.
I've tried to use the include tag.
But it doesn't seem to support variables as part of the href attribute.
Eg.
<include href="_group_${groupData.Type}.spark" />
Does anyone know of any workaround to do this?
The <include> tag is part of the Spark language that gets parsed on the first pass and cannot include variables of its own because the view class file has not yet been generated for the variables to be evaluated. Using <include> is a means of including a static resource of some kind.
I think the thing you may be looking for is the <use import="myFile.spark"/> tag for including other Spark files, or you could just use Spark Partials built in. The problem however is that you're trying to have the included spark files dynamically determined at runtime which I don't think will be possible.
Is there any way you can pre-generate the views for each groupData.Type value using the pre-compilation ability in Spark?
The other option potentially (if you really do need these dynamic at runtime) is to create and maintain an InMemoryViewFolder instance and you can add "virtual" files to it as you pull them out of the database but you still won't get away with using variables inside any Spark language elements because variables "don't exist" at that point in the parsing/rendering pipeline.
Hope that helps,
Rob