I must access the slot of an ionic page to insert the 'background: inherit' on it. I tried everything and still I cant access it via CSS.I must access this slot tag
You can not access (select via CSS rules) elements that are part of shadow DOM - that is by design. You can read more here: https://www.joshmorony.com/shadow-dom-usage-in-ionic-web-components/
You have options:
Either the element you need to change exposes CSS variable that you can access and modify
You might re-write component / make your own
You can try and "hack" it using a directive that adds another "style" element to the shadow dom: https://forum.ionicframework.com/t/ionic-v4-shadow-dom/137350/3
Related
Is there any way to add custom javascript?
I want to add custom javascript to some of the pages but it seems i am not able to.
Each default Backpack operation has its own CSS and JS file, in:
public/vendor/backpack/crud/css
public/vendor/backpack/crud/js
If you don't find one there, you can create one, and Backpack will pick it up in that operation's view (e.g. create.css or list.js).
Read more: https://backpackforlaravel.com/docs/3.5/crud-how-to#customize-css-and-js-for-default-crud-operations
I used this line to define a canvas element in my view.xml:
<core:HTML content="<div class="wrapper col-6"><canvas id="
myChart"width="800"height="400"></canvas></div>">
</core:HTML>
Now I want to get the element in the controller but the typical this.getView().byId("myChart") doesn't seem to work even though the site successfully loads a canvas with the ID.
Is there a way to get those types of elements defined inside a core:HTML tag for the controller?
If not, is there a different way to create a canvas or other HTML elements so that I can refer to them with an ID / use them in the controller?
The element created in this way is not 'registered' in UI5 framework like the other controls. byId() only checks the internal register.
You can use jQuery or standard JavaScript to fetch the element though, like $('#myChart') or document.querySelector('#myChart').
You will find the code for this in Core.js or Core-dbg.js.
Like Jorg said, byId is for retrieving controls. So if you were to put an id on the HTML control, you could retrieve that control and then call getDomRef() on it to get the outermost element, which in your example would be the div. If you'd further only put the canvas inside the HTML control, you'd get that.
If you're accessing the id of the canvas directly, like Jorg suggested, you'll run into trouble if you're going to use the view twice inside a page, because the id of the canvas isn't unique anymore.
There is a third and IMHO preferable option, that is to use html directly inside the view. First you'll need to declare a namespace for it, like
xmlns:html="http://www.w3.org/1999/xhtml"
preferably right on your View element.
Then you can write html directly in your xml view like this:
<html:div class="wrapper col-6">
<html:canvas id="mycanvas" width="800" height="400"></html:canvas>
</html:div>
This way you're getting a proper (unique) id for your canvas and can access it as part of the view's dom with this.getView().getDomRef("-mycanvas"). Note the extra leading dash, because of internal id generation inconsistency in UI5. Also note that getDomRef() is considered protected, but I doubt it will change. Finally, remember that you can only get a domref for rendered controls, so you'll probably want to access it from an afterRendering event.
I am trying to make an "Infobox" with TYPO3.
In my HTML Template i have the Infobox:
<div id="infobox">
<!-- ###infobox### start -->
CONTENT from the backend
<!-- ###infobox### start -->
</div>
...
Now in my Backend, i have a content element, that keeps the content for my Infobox in the Frontend:
What i want to do is: If i disable the content element via the "disable button" in the backend, i want to change the CSS of my #infobox (adding display:none) or if I re-enable it I want to remove the display:none.
I hope I could explain my issue and hope someone can help me.
As far as I understand, you want the disabled flag of the content element to only influence the rendered output, not switch off the rendering.
I fear that this is not easily possible. The disabled column is part of TYPO3’s so-called enable fields, for which checks are added all over the place by the TYPO3 API. Due to this, "hidden" records are usually not even selected from the database, so they are also never fed to the rendering engine.
An alternative would be to use a custom content type with a custom field for your purpose, hide the "hidden" field in the form for that type and put the custom field in its place. This can all be done with standard TYPO3 core mechanisms.
What you cannot avoid however is that somebody will be able to hide/disable the content element from the page or list module. This cannot be prevented as your content needs to live in the same table (tt_content) as the rest of the content—and the settings for enable fields are global per table.
You can use an custom fluid content element
see: http://www.creativeworkspace.de/blog/artikel/eigene-inhaltselemente-im-typo3-cms-62x-und-7x/
or: https://docs.typo3.org/typo3cms/extensions/fluid_styled_content/7.6/AddingYourOwnContentElements/Index.html
or you use a custom layout
TCEFORM.tt_content {
layout {
addItems {
item1 = Name of Layout
}
}
}
after this you can get it with {data.layout} in your template
{f:if(contition:'{data.layout} == item1',then:'display:none')}
I've created a custom form type in symfony2. This formtype has it's own template and this is working fine.
The form type also needs some javascript on the clientside to work nicely.
I would like to add this javascript to the page using the same template I use to render the widget. It's a bit more of a hassle to do this manually.
I could add the javascript manually on each page, but it would be nice if that just happened automatically.
I can't add the javascript just before or after the element itself, as it has a dependency to jquery which is only loaded at the bottom of the body.
I tried using a block which is defined in the "main template" (it is named block_javascript) to add the custom javascripts to the footer of the page, but it seems the rendering of forms works a little different and the block is not available.
I'm using assetic to prepare and return assets.
Is there a way I can use blocks from the main template being rendered when rendering a form widget?
I don't think yet about all the consequences or if it's doable, but here an idea that can solve your problem: use the event dispatcher.
an event for assets addition
a service that hold a list of assets to use and subscribe to above event
a Twig extension that use above service to make assets accessible in the template
trigger the event in the buildView() function of your form type with right parameters
use the Twig extension in your layout template
It theorically should work.
My Requirement is to have a global header and footer with author able properties.
So if we update the properties on one page it should be reflected across all pages.
What is the best approach to achieve this in CQ5.
ACS AEM Commons now supports this functionality without use of an iparsys - Shared Component Properties (http://adobe-consulting-services.github.io/acs-aem-commons/features/shared-component-properties.html)
Configure your menu with Shared and/or Global properties and you can simply template it directly onto all of your pages (no iparsys required). You can then edit the header/footer from any page on the site and it will by updated on all pages.
Unlike using design dialogs, Shared Component Properties supports standard content activation and internationalization (values stored below the homepage) and anything else you would expect from content.
If all of your pages site under a hierarchy, you could use an Inherited Paragraph System (iparsys). This is from an old version of the documentation, but is still a good intro:
The inherited paragraph system is a paragraph system that also allows
you to inherit the created paragraphs from the parent. You add
paragraphs to iparsys at for example, /content/geometrixx/en/products
and as result, all the subpages of products that also have iparsys
with the same name inherit the created paragraphs from the parent. On
each level, you can add more paragraphs, which are then inherited by
the children pages. You can also cancel paragraph inheritance at a
level at any time.
While not quite what you're describing in the original post (edit anywhere) it will allow you to edit the content once (at the parent page) and inherit the changes everywhere.
Traditionally you could create the components and swap the dialogs out for design dialogs. Basically you would rename your component dialog to design_dialog.
What this will do is save the changes you make to this object to a design path under etc. You can set a design path for site by going to the top level parent and setting a designPath property.
So node structure might look something like
parentNode
- #prop designPath = "designs/myapplication"
childNode1
childNode2
etc...
Any component using a design_dialog on the parentNode or its children nodes will get their information from the designPath. If you do not set a design path, the infomration is saved under etc/designs/default (or defaults, not sure, going off the top of my head).
There are some alternatives to this:
What our team did was in our siteHeader component we use http://dev.day.com/docs/en/cq/current/javadoc/com/day/cq/commons/inherit/InheritanceValueMap.html (inheritancevalue map) instead of the regular value map. The inherited value map will traverse the tree up looking for items from it's parents. This is a great source for learning how to use valuemap instead of just the default properties object:
http://experiencedelivers.adobe.com/cemblog/en/experiencedelivers/2013/02/valuemap-and-his-friend.html
This does get complicated with larger sites, and you'll have to do a lot of customization to get the system working the way you want, but it's an option if you don't want to have to manually set designPaths for every new site your authors create.
Alternatively, if you do like the idea of using designPaths and design_dialogs, you can always hook into the page creation workflow and have the page component add a designPath property on creation (this is a lot easier said than done though).
hope that helps