I was wondering when the DOM is created ? Is it when the browser receives the response it first creates a DOM representation of HTML ? Also, where can I read about internal implementation of DOM for some popular browsers ?
Related
I'm working on a URL preview widget, so I'd like to extract the meta tags from the HTML of a given URL.
However, the problem is that websites like Twitter don't return the entire HTML when they detect there's no JavaScript engine enabled (i.e. doing a GET request from the http package).
So, I'd like to know if there's any workaround for these cases, for example, using some kind of headless browser to get the entire HTML.
Thanks!
I am looking at an Adobe forum post where the link rewrite is happening. How is the LinkTransformer class triggered? For example if I am testing this in local, and put a debug inside the class does a page refresh get to this class?
Thanks..
The Link Transformer will run on every request that renders HTML. It is used to rewrite all of the configured HTML elements.
It will for example rewrite the href attribute of all <a> HTML tags. But there are several more HTML elements and attributes that are rewritten.
So in theory your debugger should halt at a breakpoint on every request. (Except if you call the page through the Dispatcher which usually will cache the HTML after the first request. So every subsequent request would not be answered by AEM and therefore, the debugger will not halt.)
I have an HTML form which a user may have filled in or partially filled in. I want to snapshot that state and render it as a PDF document. I've been using wkhtmltopdf.
I've tried this from both the client side and the server side, and the rendered result is always the original form, never the filled-in one.
I notice if I reload the filled-in form page I get back the filled-in form, but if I cut and paste the form's URL into a new window, I get the initial, non-filled-in form.
So I've convinced myself that, if I could use CGI::Session properly, I could successfully open a session identical to the filled-in session. I tried using CGI::Session::Plugin::Redirect with no joy. I think the key is that window.open() has to use the SID of the filled-in form window.
I don't have a lot of experience with CGI session management, so this has been a four-day quest to nowhere. Any advice is appreciated, even if it's to abandon this approach and go back to the more common post->render a new form in a new window, and generate the PDF from that. I'd like to avoid all of that if I can.
Say you have the following HTML document on your web server:
/var/www/html/index.html
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
</head>
<body>
<form action="/process.cgi">
<input type="text" name="foo">
</form>
</body>
</html>
When you navigate to http://hostname/index.html in your browser, the webserver returns this document and the browser displays it.
When you fill in the text field in your browser, the document on the webserver doesn't change. So anybody who navigates to http://hostname/index.html will get the original, unmodified form. This is why you can't simply copy and paste the URL into another browser tab and get the filled-in form.
Most browsers use caching by default. When you fill in some fields in a form, the browser caches what you entered. When you reload the page, the webserver sends the exact same document as before* (i.e. the unmodified form), but the browser uses the cached data to fill in the form fields the way you had them. If you override the cache when you reload the page (Ctrl+F5 in Firefox), the form fields will not be filled in. Note that neither the URL nor the document on the server have changed. This is why you can't copy and paste the URL into another browser tab after reloading the page and get the filled-in form.
wkhtmltopdf takes a URL, renders the corresponding page, and generates a PDF based on what is rendered. Based on the explanation above, it should now be clear why wkhtmltopdf always generates an image of the unmodified form.
The solution
If filling in form fields doesn't change anything on the webserver, what does it change? It changes the DOM, a structure describing the document in your browser that you can access using JavaScript.
One approach would be to use a client-side JavaScript PDF generator like jsPDF; since it runs on the client, it has access to the DOM that the user is interacting with, so it can "see" the values the user enters into the form fields.
* Actually, the webserver will typically send a 304 Unmodified response to save bandwidth, but form caching works the same either way.
The explanation from ThisSuitIsBlackNot is accurate about why your design is failing. Typing characters into form fields in a browser changes only your screen and the data in the memory allocated to the browser.
I suggest a different solution. The WWW::Mechanize::Firefox module is a variant of WWW::Mechanize that uses a real browser application to retrieve and render web pages. It is mostly chosen when a site requires JavaScript support, but it is useful here because it has a content_as_png method which returns a PNG image of the current page. Hopefully that is enough for you to build a PDF file with the required content
I have a jsp form which takes in user details. On submit button it goes to a jsp page where the details are entered into the database. But before that I would like to check if the username is available as soon as the user clicks the check availability button. How can this be done?
2 ways:
Just redisplay the same page after submitting the form wherein you conditionally display the validation message. This is rather trivial and already covered in the Hello World example in our Servlets wiki page.
Use Ajax to send an asynchronous HTTP request and manipulate the HTML DOM based on the response of the request. This requires a bit more in depth understanding of how websites really work and what JavaScript is. You can find some concrete examples in How to use Servlets and Ajax?
Use AJAX(Asynchronous Javascript and Xml). Its the best web2.0 technology. You can manipulate DOM based on the answer from server
I've been using wicketTester.getServetResponse.getDocument to get the text of the current page for testing, only to find that after an ajax request it is set to the ajax response, not the whole page.
Is there any way to get a representation of the whole rendered page, as the browser would be seeing it after the ajax manipulation?
With WicketTester, you can simulate an Ajax call and see that your app sends the correct Ajax response. But it doesn't really exercise the ajax.
So I don't believe there's a way to get that from WicketTester.
If you actually need to test the app all the way to the UI including Ajax/javascript effects on the rendering, you likely need to use something like Selenium for that portion of your testing.
Thinking the Wicket way I hope the following approach should work:
#startPage(YourPage.class)
do some Ajax calls
#startPage(wicketTester.getLastRenderedPage())
wicketTester.getLastRenderedPageAsString()
The idea is: you start a page for testing, the first response is complete page response, then you do some Ajax calls which change some models around, then you start the last rendered page as an instance - this way it will render the page with the updated models from the Ajax calls.
The trouble is that you can put any Javascript in the response to an Ajax call. But if you don't want to deal with that, you can save the original full-page DOM, iterate through the objects in the Ajax response, find them by id in the full DOM and replace them with the new versions.
How useful this would be, I don't know, my guess would be not very. so I'd probably go with Selenium too.