enter image description here
I want to know how to provide the numbering for each tab, so that author can provide the number as per their requirement.
This is the strangest requirement I ever heard of. You can sure do that, but it didn't make much sense of doing it system wide as one author can feel the dialog one way, other in completely different. The only reasonable solution is to use javascript to reorder the tabs in the way an author want and than save the settings for this specific component in his user profile. You can start implementing it by creating a clientlib with the category cq.authoring.dialog. In your JS you have to listen to specific dialog loading event as shown below. I think this should be enough and it's a good starting point.
// necessary as no granite or coral ui event is triggered, when the dialog is opened
// in a fullscreen mode the dialog is opened under specific url for serving devices with low screen resolution
if (location.href.match(/mnt\/override/)) {
$(window).on('load', function(e) {
setTimeout(doSomething, 100);
});
} else {
$(document).on('dialog-ready', function(e) {
Coral.commons.ready(function(){
setTimeout(doSomething, 100);
});
});
}
You can use granite:rel to define specific identifiers in the dialog definition and use save them later in the user settings. You can define drag & drop events using the tab selector [role="tab"].
This is not trivially possible. Decide upfront about the order when building the component, provide meaningful labels and go with that. Touch UI does not provide the feature you need.
Related
Problem:
By default in instantsearch.js, the reset button in the search field is hidden until you start typing. However the submit button doesn't hide, causing them to overlap, this seems default behavior(?)
Here is a demo that demonstrates the issue:
https://codesandbox.io/s/quizzical-leakey-7shzr
Expected Outcome:
I want the search submit button to replace (toggle) with the reset button on typing.
Things I've tried:
I have looked through the documentation and can't find any solution to this. There is a showReset and showSubmit parameters as seen here: https://www.algolia.com/doc/api-reference/widgets/search-box/js/ but these just disable them completely.
Changing the template for them in the widget, only stylizes them, rather than adjust their function.
I do have a heavy handed solution I've written in jquery below but my question is: Is there a way to configure this behavior in instantsearch.js?
$( ".ais-SearchBox-input" ).on("keyup", function() {
if($('.ais-SearchBox-input').val().length > 0){
$('.ais-SearchBox-submit').addClass('none');
}else{
$('.ais-SearchBox-submit').removeClass('none');
}
});
$(document).on('click', '.ais-SearchBox-reset', function() {
$('.ais-SearchBox-submit').removeClass('none');
});
The submit button is initially designed to be on the left hand side of the searchbox, and the reset one on the right hand side, as you can see in the InstantSearch.js SearchBox Storybook. In your demo, there's custom CSS that aligns them both on the right, which is why they're overlapping. But they're two orthogonal concepts, so they weren't designed to replace one another out of the box.
Your solution is fine, although I understand that having imperative logic like this on top of InstantSearch.js might feel icky. Another approach is to directly hook into the rendering logic of the widget by using the connectSearchBox connector. You'll be able to fully control what is rendered, and you'll have access to query which you'll be able to leverage to decide whether to show one button or the other.
My advice is to start from the full example and adapt it for your use case.
We are working on tracking a site which has components built using Shadow DOM concepts, when we are creating a rule in launch to add tagging to these components it’s not working.
Can you guide us with best practice on tagging components in Shadow DOM?
I found unanswered questions about google analytics Google analytics inside shadow DOM doesn't work is this true for adobe analytics also?
Best Practice
Firstly, the spirit of using Shadow DOM concepts is to provide scope/closure for web components, so that people can't just go poking at them and messing them up. In principle, it is similar to having a local scoped variable inside a function that a higher scope can't touch. In practice, it is possible to get around this "wall" and have your way with it, but it breaks the "spirit" of shadow DOM, which IMO is bad practice.
So, if I were to advise some best practice about any of this, my first advice is to as much as possible, respect the spirit of web components that utilize shadow DOM, and treat them like the black box they strive to be. Meaning, you should go to the web developers in charge of the web component and ask them to provide an interface for you to use.
For example, Adobe Launch has the ability to listen for custom events broadcast to the (light) DOM, so the site developers can add to their web component, create a custom event and broadcast it on click of the button.
Note: Launch's custom event listener will only listen for custom event broadcasts starting at document.body, not document, so make sure to create and broadcast custom events on document.body or deeper.
"But the devs won't do anything so I have to take matters into my own hands..."
Sadly, this is a reality more often than not, so you gotta do what you gotta do. If this is the case, well, Launch does not currently have any native features to really make life easier for you in this regard (for the "core" part of the below stuff, anyways), and as of this post, AFAIK there are no public extensions that offer anything for this, either. But that doesn't mean you're SoL.
But I want to state that I'm not sure I would be quick to call the rest of this answer "Best Practice" so much as "It's 'a' solution..". Mostly because this largely involves just dumping a lot of pure javascript into a custom code box and calling it a day, which is more of a "catch-all, last resort" solution.
Meanwhile, in general, it's best practice to avoid using custom code boxes when it comes to tag managers unless you have to. The whole point of tag managers is to abstract away the code.
I think the TL;DR here is basically me reiterating this something that should ideally be put on the site devs' plate to do. But if you still really need to do it all in Launch because ReasonsTM, keep on reading.
'A' Solution...
Note: This is a really basic example with a simple open-mode shadow DOM scenario - in reality your scenario is almost certainly a lot more complex. I expect you to know what you're doing with javascript if you're diving into this!
Let's say you have the following on the page. Simple example of a custom html element with a button added to its shadow DOM.
<script>
class MyComponent extends HTMLElement {
constructor() {
super();
this._shadowRoot = this.attachShadow({
mode: 'open'
});
var button = document.createElement('button');
button.id = 'myButton';
button.value = 'my button value';
button.innerText = 'My Button';
this._shadowRoot.appendChild(button);
}
}
customElements.define('my-component', MyComponent);
</script>
<my-component id='myComponentContainer'></my-component>
Let's say you want to trigger a rule when a visitor clicks on the button.
Quick Solution Example
At this point I should probably say that you can get away with doing a Launch click event rule with query selector my-component#myComponentContainer with a custom code condition along the lines of:
return event.nativeEvent.path[0].matches('button#myButton');
Something like this should work for this scenario because there are a lot of stars aligned here:
The shadow dom is open mode, so no hacks to overwrite things
There are easily identifiable unique css selectors for both light and shadow DOM levels
You just want to listen for the click event, which bubbles up and
acts like a click happened on the shadow root's light DOM root.
In practice though, your requirements probably aren't going to be this easy. Maybe you need to attach some other event listener, such as a video play event. Unfortunately, there is no "one size fits all" solution at this point; it just depends on what your actual tracking requirements are.
But in general, the goal is pretty much the same as what you would have asked the devs to do: create and broadcast a custom (light) DOM event within the context of the shadow DOM.
Better Solution Example
Using the same component example and requirement as above, you could for example create a rule to trigger on DOM Ready. Name it something like "My Component Tracking - Core" or whatever. No conditions, unless you want to do something like check if the web component's root light DOM element exists or whatever.
Overall, this is the core code for attaching the event listener to the button and dispatching a custom event for Launch to listen for. Note, this code is based on our example component and tracking requirements above. It is unique to this example. You will need to write similar code based on your own setup.
Add a custom js container with something along the lines of this:
// get the root (light dom) element of the component
var rootElement = document.querySelector('#myComponentContainer');
if (rootElement && rootElement.shadowRoot) {
// get a reference to the component's shadow dom
var rootElementDOM = rootElement.shadowRoot;
// try and look for the button
var elem = rootElementDOM.querySelector('button#myButton');
if (elem) {
// add a click event listener to the button
elem.addEventListener('click', function(e) {
// optional payload of data to send to the custom event, e.g. the button's value
var data = {
value: e.target.value
};
// create a custom event 'MyButtonClick' to broadcast
var ev = new CustomEvent('MyButtonClick', {
detail: data
});
// broadcast the event (remember, natively, Launch can only listen for custom events starting on document.body, not document!
document.body.dispatchEvent(ev);
}, false);
}
}
From here, you can create a new rule that listens for the custom event broadcast.
Custom Event Rule Example
Rule name: My Button clicks
Events
Extension: Core
Event Type: Custom Event
Name: MyButtonClick
Custom Event Type: MyButtonClick
Elements matching the CSS selector: body
Conditions
*None for this scenario*
From here, you can set whatever Actions you want (set Adobe Analytics variables, send beacon, etc.).
Note:
In this example, I sent a data payload to the custom event. You can reference the payload in any custom (javascript) code box with event.detail, e.g. event.detail.value. You can also reference them in Launch fields with the % syntax, e.g. %event.detail.value%.
What is the proper way to use the SDK to make a dialog (which is not anchored to the add-on bar, etc. but shows centered on screen)? It doesn't seem like there is any API for this important capability. I do see windows/utils has open but I have two problems with that:
The dialog opening seems to require "chrome" privs to get it to be centered on the screen (and I'd be expectant of add-on reviewers complaining of chrome privs, and even if not, I'd like to try to stick to the SDK way).
While I can get the DOM window reference of the new window/utils' open() dialog, I'm not sure how to attach a content script so I can respond to user interaction in a way that prompts (and can respond to) privileged behavior ala postMessage or port.emit (without again, directly working with chrome privs).
Ok, this answer should have been pretty obvious for anyone with a little experience with the SDK. I realized I can just use a panel. In my defense, the name "panel" is not as clear as "dialog" in conjuring up this idea, and I am so used to using panels with widgets, that it hadn't occurred to me that I could use it independently!
Edit
Unfortunately, as per Bug 595040, these dialogs are not persistent, meaning if the panel loses focus, the "dialog" is gone... So panel looks like it is not a suitable candidate after all... :(
Edit 2
I've since moved on and have gotten things working mostly to my satisfaction with sdk/window/utils and openDialog on whose returned window I add a load listener and then call tabs.activeTab.on('ready', and then set tabs.activeTab.url to my add-on local HTML file so the ready event will get a tab to which I can attach a worker. There is still the problem with chrome privs I suppose, but at least the main communications are using SDK processes.
Update to Edit 2:
Code sample provided by request:
var data = require('sdk/self').data,
tabs = require('sdk/tabs');
var win = require('sdk/window/utils').openDialog({
// No "url" supplied here in this case as we add it below (in order to have a ready listener in place before load which can give us access to the tab worker)
// For more, see https://developer.mozilla.org/en-US/docs/Web/API/window.open#Position_and_size_features
features: Object.keys({
chrome: true, // Needed for centerscreen per docs
centerscreen: true, // Doesn't seem to be working for some reason (even though it does work when calling via XPCOM)
resizable: true,
scrollbars: true
}).join() + ',width=850,height=650',
name: "My window name"
// parent:
// args:
});
win.addEventListener('load', function () {
tabs.activeTab.on('ready', function (tab) {
var worker = tab.attach({
contentScriptFile: ....
// ...
});
// Use worker.port.on, worker.port.emit, etc...
});
tabs.activeTab.url = data.url('myHTMLFile.html');
});
if the panel loses focus, the "dialog" is gone...
It doesn't get destroyed, just hides, right? If so, depending on why it's getting hidden, you can just call show() on it again.
You'd want to make sure it's not being hidden for a good reason before calling show again. If there's a specific situation in which it's losing focus where you don't want it to, create a listener for that situation, then call if (!panel.isShown) panel.show();
For example, if it's losing focus because a user clicks outside the box, then that's probably the expected behaviour and nothing should be done. If it's losing focus when the browser/tab loses focus, just register a tab.on('activate', aboveFunction)
Simply adding ",screenX=0,screenY=0" (or any values, the zeroes seem to be meaningless) to the features screen seems to fix centerscreen.
private ImgButton button = new ImgButton();
...
button.setSrc("iconName.jpg");
GWT or SmartGWT, I cannot tell exactly, generate state word to concatene it on the name of file.
Example to clarify :
On focus, iconName.jpg become iconName_Focus.jpg
On mouse down click, iconName.jpg become iconName_Down.jpg
On over, iconName.jpg become iconName_Over.jpg
Because these images are custom images, I want to tell GWT to take a default image when I didn't provide the corresponding image.
For example, when over event is fire and iconName_Over.jpg does not exist then use iconName.jpg.
Use the setShow{State} or setShow{State}Icon methods accordingly. For example for disabling the mouse down state, use setShowDown(Boolean.FALSE). For not showing a different icon when the mouse goes down on the button, use the setShowDownIcon(Boolean.FALSE). The rest of the actions have accordingly named methods you can look up at the ImgButton's javadoc page.
GTK+ noob question here:
Would it be possible to customize the GtkFileChooserButton or GtkFileChooserDialog to remove the 'Places' section (on the left) and the 'Location' entry box on the top?
What I'm essentially trying to do is to allow the user to select files only from a particular folder (which I set using gtk_file_chooser_set_current_folder ) and disable navigating to other locations on the file system.
This is the standard file chooser dialog :
This is what I need:
It doesn't look like that is possible with the standard file chooser dialog. For example, here is a document discussing why such a thing would be useful and how it could be implemented, but the idea never made it to fruition.
What you can do, perhaps, is write your own dialog that implements the GtkFileChooser interface, based on the GtkFileChooserDialog code, but hides the location bar and bookmarks list.
You can get a handle on the individual children by finding out where there are with gtkparasite and then accessing them with get_children.
Make sure to use .show() instead of .run() for inspecting the dialog with gtkparasite. If you use .run() the dialog is shown in modal mode so you can't inspect it.
For example I hide the Path and Places widgets with the statements below:
dialog = gtk.FileChooserDialog("Open***", None, gtk.FILE_CHOOSER_ACTION_OPEN,
(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL,gtk.STOCK_OPEN, gtk.RESPONSE_OK))
dialog.set_show_hidden(True)
dialog.set_default_response(gtk.RESPONSE_OK)
vbox = dialog.get_children()[0].get_children()[0].get_children( [0].get_children()[0]
vbox.get_children()[0].hide()
vbox.get_children()[2].get_children()[0].hide()
Of course this is not an exposed API so it can always break from underlying changes.
Hope it makes sense ...
Tried to post an image but I am a new user ....