I would have 10 bootstrap buttons on a single html page.
Each button opens a ootstrap modal filled with a html fragmen via an ajax request.
<div class="modal fade" id="myModal"></div>
$('#myModal').modal();
Should I create 10 different divs with 10 different ids? Or even 10 different instances?
var dialogInstance1 = new BootstrapDialog({
title: 'Dialog instance 1',
message: 'Hi Apple!'
});
or
should I create ONE dialog?
I would expect kind of caching problems when I open modal1, then just when I open modal2 I see still for some miliseconds modal1 html fragment from a prvious ajax request.
And how should I create those modals? The samples should this:
$('#myModal').modal();
and the instantiation? This is very confusing.
Can someone please share his experience how to approach with many bootstrap modals?
I would expect kind of caching problems when I open modal1, then just when I open modal2 I see still for some miliseconds modal1 html fragment from a prvious ajax request.
Assuming you're referring to data-remote's caching, you will probably be able to disable that in Bootstrap v3.2.0 (see https://github.com/twbs/bootstrap/pull/13183/ ).
However, I'd still recommend against using data-remote since it doesn't give you much control. It:
doesn't provide or easily let you do any error handling
doesn't give any "loading..." indication
forces you have to generate modal HTML on the server side (as opposed to, e.g., returning JSON from the server and using client-side templating)
IMO, you should:
include just one instance of the blank modal markup
setup your own click event handlers on the buttons that summon your modal
initiate the AJAX request in your click event handler
use client-side templating to generate a corresponding modal using the results of the request
use $(...).modal() or $(...).modal('show') (depends on how your templating works) to show the modal after the templating completes
Related
Im looking for an option to limit the scope of every selector to a parent selector.
Am trying to abstract away a lot of the (internal implementation) details of our WebApp for the testers that will actually write the UI tests.
If our application shows a Modal dialog (just a div tag that lies op top of all the other content and prevents interacting with the underlying content), I'd like to restrict all Selectors used in the tests written by testers to be automatically limited to the scope of this Modal Dialog div.
Our new client UI framework uses just divs for Modal Dialogs, while our previous client UI framework used an embedded iframe for each modal dialog. In the iframe scenario, we'd call .switchToIframe(), which would effectively limited all selectors used in tests to this iframe.
Am trying to achieve something similar for the new client framework that uses just divs
I'm not sure you can limit the scope of the DOM like that, but you could build out a Page Object Model (POM) design that would only intelliSense existing locators from their respected repos. This way, if they begin typing a locator and it doesn't pop up, a hint that they aren't in the 'scope' of the modal.
I've tried the following to format a date in the locale of the browser:
<script>document.write((new Date(2021, 4, 14)).toLocaleString().split(",")[0])</script>
However, based on this question Document.write clears page it seems like it is writing after the document stream is closed, thereby opening a new stream and replacing the content on my page.
Using htmx is there a recommended way of formatting dates to the browser locale?
Is there an htmx tag that allows me to execute this javascript safely?
This is the html I'm using to invoke htmx:
<div hx-get="/open_orders"
hx-trigger="load"
hx-target="this"
hx-swap="outerHTML">
<img class="htmx-indicator"
src="[[=URL('static', 'images/spinner.gif')]]"
height="20"/>
</div>
-Jim
As you mentioned, document.write() does not play well with htmx. This is true for most front-end libraries/toolkits/frameworks that want to control what is displayed in the browser window.
Instead, there are a number of ways you could do this instead:
Try rendering the time on your server and simply displaying the value via htmx. This library works best when you put the server in charge whenever you can. I would recommend starting with this, if you can, instead of rendering a date via Javascript.
If you really need to update this information on the browser (for instance, to update the display as the data changes, write to a specific DOM element instead:
<span id="time"> </span>
<script>
document.getElementById('time').innerHTML = currentTime();
</script>
You can also hook in to a wide range of events that htmx triggers. This works well if you want to update information on the browser whenever htmx does something -- for instance, you can update the date/time displayed whenever htmx loads a new html fragment into the DOM.
Can a Web page communicate directly with a Safari extension on JavaScript level?
Ideally, I'd like some way to invoke the JavaScript in the extension's global page, but talking to the injected script will do, too, since that can talk to the global page via messages.
Direct function calling doesn't work. The window object the page and the injected script have are distinct. safari.self is not available to a regular Web page. Is there dispatchMessage in some other DOM object that's visible to the Web page code?
Found one clumsy workaround. The injected script and the page share the document object. The injected script would create an HTML element in the page (an <input type="hidden"> in my case), give it an agreed-upon ID, and hook its onclick. The page would find that element by ID and invoke onclick, passing some arguments along. The injected script gets control. For script-to-page callbacks, I'd use onchange on the same element.
The calls are synchronous, even.
The injected script would then pass the message on to the extension's global page using safari.self.tab.dispatchMessage().
I'm working in selenium with Firefox browser.
The Html code shown in View Source (CTRL+U) is different from the html code i see when inspecting the elements in Firefox.
When i run the driver.getPageSource() i only get the View source (CTRL + U) codes.
Is there is any way to access the Inspect element code instead of View source code?
I think your question is answered here.
The View Source html is what is sent by the server. I think of it as compile time html, or the initial state of the DOM.
The Inspect Element html could have been updated by ajax responses or javascript so will not necessarily be the same. I think of it as runtime html, or the current state of the DOM.
The GetAttribute() method queries the current DOM element state. You can return a particular html attribute value directly
webElement.GetAttribute("class")
or get the whole html string.
webElement.GetAttribute("innerHTML")
There are some fundamental difference between the markup shown through View Source i.e. using ctrl + U and the markup shown through Inspector i.e. using ctrl + shift + I.
Both the methods are two different browser features which allows users to look at the HTML of the webpage. However, the main difference is the View Source shows the HTML that was delivered from the web server (application server) to the browser. Where as, Inspect element is a Developer Tool e.g. Chrome DevTools to look at the state of the DOM Tree after the browser has applied its error correction and after any Javascript have manipulated the DOM. Some of those activities may include:
HTML error correction by the browser
HTML normalization by the browser
DOM manipulation by Javascript
In short, using View Source you will observe the Javascript but not the HTML. The HTML errors may get corrected in the Inspect Elements tool. As an example:
With in View Source you may observe:
<h1>The title</h2>
Whereas through Inspect Element that would have corrected as:
<h1>The title</h1>
getPageSource() always returns the markup obtained through View Source.
I have a long form made up of multiple sections, each with its own questions. Each section can be saved independently with an <input type="submit" value="Save" /> button.
Each section is loaded dynamically into the page (and there are a variable number of sections).
Each form is authored separately as an Ajax.Begin() ajax form, but with dynamic loading of the forms it appears UnobstrusiveJavaScript will not bind the submit buttons and they perform a standard postback.
What is the simplest way to reconnect the ajax functionality of the submit buttons?
After checking the source of UnobstrusiveJavaScript (which is quite small) it leaves permanent event handlers using .on('submit') so it should just work with dynamically loaded pages.
Turns out the master form was missing the inclusion of UnobstrusiveJavaScript:
#Scripts.Render("~/bundles/jqueryval")
Worth checking fiddler when this sort of thing occurs :)