I'm studying Thymeleaf and have found out that in almost all examples there are Thymeleaf's tag values as well as standard HTML values like:
<title th:text="#{product.page.title}">Page Title</title>
<link href="../static/css/bootstrap-3.3.7-dist/bootstrap.min.css" rel="stylesheet"
th:href="#{/css/bootstrap-3.3.7-dist/bootstrap.css}"/>
<script src="../static/js/jquery-3.1.1.js"
th:src="#{/js/jquery-3.1.1.js}"></script>
These standard tag values like Page Title or href="../static/css/bootstrap-3.3.7-dist/bootstrap.min.css" etc. are ignoring by controller and don't rendering on the page.
I'm wondering – is it just a good practice to leave them to improve code readability or it is better to remove them to clean up code?
Because for the compiler they are useless and have not any affect to the rendering result.
This depends entirely on your development process.
You could keep the HTML attributes around in the early phases, while you are still trying to lay out the page using just your browser.
But, once you get to a point where you are using automated unit / web testing, you can safely remove the HTML attributes because this testing should always be using a prod-like environment (which would include thymeleaf).
Related
Although I know JSP (basic understanding), I have some doubts on the JSP technology.
Consider the below simple jsp:
<html>
<head>
<title> This is demo</title>
</head>
<body>
<h1> The current time is <%=new java.util.Date()%> </h1>
</body>
</html>
With respect to this, I have some doubts (which I have been keeping at the back of my mind):
1) The basic text of this jsp is same, is it dynamic page because it has JAVA code in it?
2) When a user accesses this jsp page, does the container first execute the java code and replaces the output of java code inside the page?
3) What makes this a jsp page? Do mixing of html and java code make it a jsp?
4) Can the java code (within <% %> ) live independent of html? or they are coupled (the java code has to be present in html page).
They might be basic questions, can anyone help me in understanding them?
Yes it is dynamic because it is computed (even partially) at run time - here the java scriptlet is the dynamic part
Not exactly. JSP is not a template engine. JSP pages are fully translated to java source and then compiled to class files by the servlet container. Then those classes are executed at run time.
the extension .JSP makes it a JSP file. Then it must respect the JSP syntax to be correctly processed by a servlet container.
Reverse the question. Java code normally lies in java source files. A Java class implementing the HttpServlet interface can be directly map to an URL by the servlet container. And Java code can lie in a scriptlet in a JSP
But as you were said in comment, you really should read documentation on that before asking questions here.
1) it's dynamic if it contains any JSP elements, like code snippets, JSP tags etc. If it contains only HTML, then it's pretty static, although if it is processed as a JSP, then the constant response is computed dynamically on each call (safe Caching).
2) yeah much like that. Actually the static text of the JSP goes into out.write() Statements in a Java class; the whole JSP is transpiled to a Java class.
3) funny question. It's all a question of Interpretation. If you name it .jsp or have your web container process it as JSP in some other ways (depends), then you may call it a JSP.
4) this question is not quite clear. The snippets are executed after the static text has been output up to this point.
I have a JSF page which is outputting XHTML (from a facelet). One of the fields has user-generated HTML which is causing parsing errors in my web browser (Safari).
I understand that this is because XHTML is strict and follows the rules of XML, unlike HTML. What is the best way of embedding this HTML while avoiding fatal parsing errors?
One thing I've thought of is replacing all instances of say <br> with <br />, but there's got to be a better solution than that.
Here's another example of something I need to embed:
This is my sample text.<br>The address is Wind & Fire.
Notice here that the line break tag needs to be self-enclosing, and the ampersand should probably be &aamp;
Use a HTML parser which returns well formed HTML syntax. I can recommend Jsoup for this.
Kickoff example:
String userHtml = "foo<br>bar&baz";
String wellFormedHtml = Jsoup.parse(userHtml).body().html();
System.out.println(wellFormedHtml); // foo<br />bar&baz
Just apply this once when you're about to process submitted user input.
Jsoup offers more advantages as well, such a Whitelist which you can use to strip out potential malicious HTML/JS code which can open XSS attack holes.
I'm really not sure about this: does using "JSP Document" / "JSP in XML notation" imply outputting XHTML?
If so, is there anything special to look after as to produce a "valid" XHTML page?
More specifically: can I have a valid "JSP Document" (JSP in XML) that is producing an invalid XHTML page?
I'm really not sure about this: does using "JSP Document" / "JSP in XML notation" imply outputting XHTML?
It at least implies consuming and producing well formed XML. If you write invalid XML, then it will error during parsing. If it produces well formed XML, then it can impossibly be HTML4 because closing shorttags like br, hr, meta and link is disallowed.
What would you recommend to serve when using JSP Document? transitional? strict? HTML5 XML? HTML5 HTML? (HTML5 allows closing tags like <br/>)
Since it's well formed XML, you should choose either XHTML or HTML5. While HTML5 specification is still in draft mode, it allows closing shorttags. Also see the end of chapter 3.2.2 Elements:
Some elements, however, are forbidden from containing any content at all. These are known as void elements. In HTML, the above syntax cannot be used for void elements. For such elements, the end tag must be omitted because the element is automatically closed by the parser. Such elements include, among others, br, hr, link and meta
HTML Example:
<link type="text/css" rel="stylesheet" href="style.css">
In XHTML, the XML syntactic requirements dictate that this must be made explicit using either an explicit end tag, as above, or the empty element syntax. This is achieved by inserting a slash at the end of the start tag immediately before the right angle bracket.
Example:
<link type="text/css" href="style.css"/>
Authors may optionally choose to use this same syntax for void elements in the HTML syntax as well. Some authors also choose to include whitespace before the slash, however this is not necessary. (Using whitespace in that fashion is a convention inherited from the compatibility guidelines in XHTML 1.0, Appendix C.)
Then, the choice between transitional and strict depends on the degree of web standards you'd like to support. For that, the table at the bottom of this website gives an excellent overview.
To start, you'd like to avoid the Quirks Mode as much as possible since that triggers the box model bug in MSIE browser which causes inconsitenties in margins, paddings, dimensions of the elements when specified by CSS. The lack of the doctype or an incorrect doctype will trigger this mode.
I strongly recommend to pick a Strict doctype since the box model and behaviour would then be as much as possible consistent among the different webbrowsers the world is aware of. Either of the following doctypes is okay, depending on what elements/attributes you'd like to support/vaildate.
XHTML 1.0 strict:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
or the newer XHTML 1.1 (strict, module-based):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
or the (still in draft mode) HTML5 doctype:
<!DOCTYPE html>
Note that you need to ensure that the HTTP Content-Type header is set to text/html, not application/xml nor application/xhtml+xml when going for XHTML, else MSIE may still go mad since it doesn't support that. Also see the aforementioned doctype website for more detail. The same article indeed mentions that serving XHTML as text/html is considered harmful, but that only applies when it get rendered with the <?xml?> declaration and/or contains inline JavaScripts not embedded in CDATA blocks.
It depends on your definition of XHTML. For most people, XHTML simply means HTML in well-formed XML. In that sense, JSP Document implies XHTML because JSP Document itself is well-formed XML.
However, JSP Document itself doesn't enforce any XHTML rules. For example, you can still generate XHTML 1.0 Strict document with deprecated tags like <center>.
It's also possible to use custom tags in JSP Document that generates non-XML tags, which renders whole document non-XML.
I have the following requirement: Based on some user input, I need to generate a HTML form that the user can embed on a separate Web application. I thought on doing this with GWT since I'm familiar with it.
I'm clear on the input parsing and widget generation part. What I don't know how to do is how to export the root widget's (most probably a Panel) compiled code, so the user can take the code and include it in some other page.
Something like:
String rootPanelCode = rootPanel.exportCode();
Dialog codeDialog = new DialogBox();
codeDialog.setText(rootPanelCode);
Then the user copies the displayed code in some HTML file:
<script type="text/javascript" language="javascript">
//copied code goes here
</script>
Requiring a particular <div id="required_id" /> in the HTML file is not a problem. Or maybe javascript code is not enough, and the user is required to download a zip file with js and html files, copy those to a directory and reference them in the page. This again is not a problem.
Is my use case possible with GWT?
Thanks in advance.
I'd say... no :) Mainly because when a GWT application is started it first runs the bootstrap file that in turn chooses the particular permutation for the current browser. So the code that you would get might include some stuff that wouldn't work in all browsers. This might be side stepped by providing some sort of "lightweight" boostrap file/method to download but I doubt that would work.
Besides, the JS code you get is heavily optimized (and with GWT 2.0 the JS file contains JS, CSS and even images), for example, when possible strings are put into variables for performance reasons - but these variables are usually grouped together and put in one place in the compiled JS file, so even if you could somehow get to the code that creates your form, it could contain references to some undefined variables. In other words, the compiled code is meant to be used as a whole.
A more "elegant" solution (and more importantly, feasible with GWT ;)) is to export the form to some sort of abstract form/language, maybe JSON, so that you could parse/recreate it easily in the other web app:
{
"form1": [
{ "label1": "value1" },
{ "label2": "value2" }
]
}
Hmm, I just thought of a possible hack.. With the right use of code splitting it might be possible to separate the code responsible for the form creation - but that would make it maybe easier to "export", it's not a complete solution (and I wouldn't recommend it.. just an interesting/possible hack).
I'm working on crawling pages for information, and have run into many problems with parsing the pages in Groovy. I've made semi-solution that works most of the time using juniversal chardet and just scanning the page for tag in the head, but sometimes two of these tags are found on one page, for example:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
...
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
Is there a standard on which one to use (first, last, both..?) or some easier way to do this? Thanks.
I would do it heuristically:
Is everything actually ASCII? If so, it doesn't matter which you use.
Does it conform to valid UTF-8? If so, I'd use that.
Otherwise, use ISO-8859-1.
You might want to look at the content-type header coming back from the web server, too...
Fundamentally the page is broken, but the above should give a reasonable "best guess."
The behavior of this is undefined by the HTML spec. You can't have two seperate content-type tags in the same document. Since presumably you'd have to parse this document anyway, your best bet is to make an educated guess about the developers intent.