May sound a stupid statement but what surprised me it came from a well educated java professional. He argued:
"JSP is HTML. Take a look at some decent jsp/servlet applications, and you will see that over 90% of your jsp file is html."
According to him since JSP pages contain a lot of HTML, so JSP is HTML. Then he continued
"Decent jsp files are basic html expanded with some additional tags and el functions."
I am awed with these statements. Am I missing something?
IMHO the generalization that "JSP is HTML" goes a bit too far.
I agree that, for the most part, JSP files will have a lot of html in them, but that is just because most http request that users make are for html files (which afterwards make their own requests for images, scripts, etc...).
If everyone started making requests for lisp files then most JSP files would be full of parenthesis, but the JSP technology in itself would remain the same.
And of course, most additional tags and el functions deal with HTML related stuff just because that is what most usefull to most developers.
In theory, whatever content types the browser sets in the accept header of the request, you should be able to respond with a JSP. Have a look at this example: http://code.google.com/p/json-simple/wiki/JSPAndAJAXExamples
Furthermore, one must realize the truth: at runtime, there is no JSP. Then you will see that it is not the JSP that writes HTML into the response, it is only Java.
This is because all JSPs are compiled (or ideally precompiled) into Java servlets that reverse what you have written in the JSP file and write that content into a stream. So in this respect a JSP is much more a piece of Java code than an HTML file...
As for the rest of the conversation going on about what is valid html, css and validation, it's just a big red herring.
My two cents.
Well the file as a whole would not be HTML if it has PHP in, it would be a PHP script with HTML in it. Once PHP process it and returns your response then it becomes HTML. (Obviously this is only the case if your PHP is returning HTML, it could be returning other things).
Im not sure I understand:
not even all html is html a valid statement :)
If he is trying to say that not all HTML is valid HTML then he is correct, there are certain standards, certain tags, certain places you can use certain attributes all available in the HTML spec.
EDIT after reading conversation:
Ok, so I just read the conversation and what I said stands, he was saying all html is not valid html which is true. Just because it has html tags in and some text doesn't mean its valid, you can check if its valid or not by going here.
As for JSP etc not being valid html, that is correct but they do/can produce valid html. a JSP/PHP/ASP page is not HTML but has/can have html in it. When a request is made to the server the file is processed server side and returns in the http response your HTML, this again may or may not be valid HTML.
Furthermore what they tell you about HTML is correct, it is not in itself styling, it is a markup that tells the browser the structure of your document. The browser has its own default styling for those particular elements, which you can override by implementing your own style in CSS.
Related
The form.as_ul shortcut works completely fine but the html isn't formatted. The only solution I found was to include a middleware which beautifies the complete html but I only want to do that for the form part. Is there a other way than write my own form template?
If you are talking about the formatting of the HTML code itself, consider not worrying about it.
In most cases the formatting of your HTML code is unimportant. It gets consumed by a browser and rendered for users. It is that rendered output that is important.
(Just for fun, load up your local Google search page and have a look at its source. It's definitely not optimized for people to read.)
In case you do want to format your HTML in a particular way you can always render fields manually.
For plain old HTML, I use the W3C validation service, but it has objections to Angualr directives.
I am having problens with WARNING: Tried to load angular more than once, and some possible solutions that I read suggest that it is caused by malformed HTML, specifically unclosed tags.
How can I detect such problems?
Obviously, I have checked that I am not directly including Angular twice
I'd say proper indentation and a good IDE are the best tools you have on this front - personally I use PHPStorm (WebStorm would also do the same) for my Angular development which will highlight warnings for the angular attributes by default but highlight errors like unclosed tags/quotes etc. in red
Indentation prevents things like open tags, the IDE helps out with open quotation marks on attributes which are probably the 2 issues most likely to cause issues.
Angular doesn’t “see” your raw HTML
The real trick here is that JavaScript (and, in turn Angular) does not work directly with your HTML. It works with the page’s DOM, which is created from your HTML.
When a browser creates a DOM from HTML, one of the major things is does is to "auto correct" any errors in the HTML. So, Angular won’t even see the errors in your HTML — it will just see the resulting “auto-corrected” DOM. (Of course, the more errors in your HTML, the more likely something would be auto-corrected in a way that causes you a problem.)
In theory, you could compare a page’s HTML source with the resultant DOM to find differences which might be errors. In practice, that would be highly problematic, and prone to reporting a high volume of false positives.
What then, can we validate HTML from web sites?
If you would like to validate your HTML markup from a web page, the best way would be to install your instance of a well-suppored HTML validator (like W3C’s validator) and hook into that.
You can capture a page’s DOM with a little jQuery (which you most likely have if you are using AngularJS):
var domString = $("html").prop("outerHTML");
Then, just post that string as input to your favorite validator.
I think you would need to compare the validation of this DOM string to validation of the HTML, as an error in the raw HTML is more likely to be where your problem is.
For example, if a file is updated while someone is viewing the page, automatically display this update, instead of requiring a refresh.
I want to make sure before I start JavaSripting to pull in the file on a interval and append it. Unless I'm mistaking, I don't think this can be done, but I'm just checking, just in case.
No. HTML is for structuring a document. Without a refresh, there is no way for HTML to change its contents.
HTML is a markup language related to SGML for creating structure and formatting in a web page. To achieve interaction beyond the initial request and response, you must utilize a programming language, not a document markup language. JS, possibly with some AJAX, is your subject matter. Good luck.
I have a situation where the underlying application provides a UI layer and this in turn has to be rendered as a portlet. However, I do not want all parts of the UI originally presented to be rendered in Portlet.
Proposed solution: Using Datapower for parsing an XML being a norm, I am wondering if it is possible to parse a HTML. I understand HTML may not be always well formed. But if there are very few HTML pages in underlying application, then a contract can be enforced..
Also, if one manages to parse and extract data out of HTML using DP, then the resultant (perhaps and XML) can be used to produce HTML5 with all its goodies.
So question: Is it advisable to use Datapower to parse an HTML page to extract an XML out of it? Prerequisite: number of HTML pages per application could vary in data but not with many pages.
I suspect you will be unable to parse HTML using DataPower. DataPower can parse well-formed XML, but HTML - unless it is explicitly designed as xHTML - is likely to be full of tags that break well-formedness.
Many web pages are full of tags like <br> or <ul><li>Item1<li>Item2<li>Item3</ul>, all of which will cause the parsing to fail.
If you really want to follow your suggested approach, you'll probably need to do something on a more flexible platform such as WAS where you can build (or reuse) a parser that takes care of all of that for you.
If you think about it, this is what your web browser does - it has all the complex rules that turn badly-formed XML tags (i.e. HTML) into a valid DOM structure. It sounds like you may be better off doing manipulation at the level of the DOM rather than the HTML, as that way you can leverage existing, well-tested parsing solutions and focus on the structure of the data. You could do this client-side using JavaScript or you could look at a server-side JavaScript option such as Rhino or PhantomJS.
All of this might be doing things the hard way, though. Have you confirmed whether or not the underlying application has any APIs or web services that IT uses to render the pages, allowing you to get to the data without the existing presentation layer getting in the way?
Cheers,
Chris
Question of parsing and HTML page originates when you want to do some processing over it. If this is the case you can face problems because datapower by default will not allow hyperlinks inside the well formed XML or HTML document [It is considered to be a security risk], however this can be overcome with appropriate settings in XML manager present.
As far as question of HTML page parsing is concerned, Datapower being and ESB layer is expected to provide message format translation and that it indeed does. So design wise it is a good place to do message format translation. Practically however you will face above mentioned problem when you try to parse HTML as XML document.
The parsing can produce any message format model you wish [theoretically] hence you can use the XSLT to achieve what you wish.
Ajitabh
From time to time, I see web pages whose content is solely written in XML (not HTML or XHTML). These pages usually have some style sheets (either XSLT or CSS) attached to them which makes them look like any other ordinary web page.
My question is, what are the advantages of such an approach (if any), and why would anyone choose to work this way?
EDIT: If this is a good thing, why is it not widespread?
EDIT 2: Thanks everyone for the great responses. They really enlightened me. I also found this question whose content is also related.
It's easier to generate it programmatically and reuse it for other purposes than displaying as webpage.
Update:
EDIT: If this is a good thing, why is it not widespread?
Not everyone needs to generate it programmatically or reuse it for other purposes than displaying as webpage. It's then easier to use plain HTML.
One possible advantage would be for use of the data of the page in something other than a web browser; that would (presumably) be easier to do if a page's content were well-formed XML. Of course in theory a well-formed, semantic XHTML page should be nearly as able to be parsed, as well.
It can also be easier to generate XML instead of XHTML, depending on the data source.
When you are getting XML data in to your system, and you are supposed to present this XML data then it is much easier to write some XSLT for that XML instead of parsing it using some sort of parser and then presenting the data.
That can be a valid point for using XML instead of XHTML or HTML
Update
To answer your question on why this is not widespread, is because XSTL is tedious and hard to work with. Specifically XPath, which can be for some people quite difficult to use.
Those pages use XSLT to get rendered on the client side. Not every browser (especially older ones) supports rendering XML + XSLT. XML can however be used server-side as template and get transformed to HTML by the application running on the server. I personally don't see any advantages to this approach.
There are a lot more web pages that are written solely in XML than you know. You're only seeing the ones that do the XSLT transformation on the client side. Server-side transformation of XML is not at all unusual, because there's a plethora of things that produce data in XML, and transforming XML to HTML in XSLT is straightforward. You'll never know this is happening if you just look at the HTML, which bears no signs of having been generated via XSLT.
Personally, I don't understand it either though one of the biggest problems is support in IE. I created a skeleton ecommerce site serving XML, transformed by XSLT and styled using CSS. I sorely missed the ability to use XLink and other wonderful XML features. It's also nice to be able to tag the data for what it is. I used a 'menu' tag for the restaurant menus. 'price' tags for prices and so on. If a user clicked on a link to change menus, all I had to do was send the name of the item, the price and the description instead of the complete page. iirc, a 4K or more HTML menu page was only 200 bytes of sent data.
As far as the "one error makes everything crash in XML" type comments, the same is true of any programming language so proper coding should be no bother for programmers and careful HTML/CSS types.
Before anyone says that what I did was actually XHTML...no. I served XML. I did call up XHTML namespaces when needed for links, images and HTML type things but only when necessary.