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.
Related
I want to have a couple html websites in a single file. Is this possible?
A website is not just an html "page".
An html file represents the document structure of one page.
Theoretically, saying that you want to represent multiple websites on one html file is like saying that you want to write different documents (your tax files, a book, a ticket for a movie, etc) based on one single template.
While theoretically you can dinamically change the structure of such a document, there is absolutely no point in doing so.
HTML describes the structure of Web pages using markup.
So why would you use a single HTML file to represent different web pages?
Sorry, but you can't. It's not possible. Why would you even do it?
The only thing that comes into my mind is to use <embed>tag, for ex. But it's probably not what you rly want
You must be more specific. The question is vague. In general you can write a code that can change dynamically the website appearance after inputs/actions from the users. For example a JavaScript code that shows/hides something (or the complete website) as long as the mouse is over an element or select/deselect an element. It all can be in a single html document (html5, css3, JavaScript/JQuery).
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.
I was wondering if there was any way to dynamically obfuscate html on a live server but not offline, so soon as my website was visited the source would be obfuscated rather than in plain text.
Since the client (browser) will have to parse it into a sensible DOM tree, this is pretty much fruitless. These days it's a lot more common to inspect a site using Firebug/Webkit Inspector, which provides a nicely formatted, navigable tree. Most people won't even notice that the HTML is "obfuscated", much less be stopped by it.
Executable code can be obfuscated by minimizing variable names and such without changing the result. HTML is the result though, if you change anything about it, the result will change. So "obfuscation" would mostly be limited to creative use of spacing anyway.
The real question you should ask yourself is "why do I need to obfuscate HTML?". If you're hiding sensitive information, then you should be either encrypting that data, or never presenting it to the client.
Most sensitive information or transactions should take place on the server, and the client only receives a token, or encrypted information, or a unique transaction identifier that can be passed back and forth.
Let me put it this way: There's no way to dynamically obfuscate the HTML on your site such that any reasonably competent person couldn't get it anyway.
You could use JavaScript to attempt to obfuscate it, but you'd have to do it in a way that didn't actually affect the DOM.
You could generate the contents of the page itself with JavaScript, but that is likely to damage accessibility, and once again the DOM will have to be in a condition the browser can use.
You could insert massive amounts of whitespace into the source, but that is easily overcome as well.
All this, and you make it harder and more annoying to manage your site. Minification has its purpose, but obfuscation here is lose-lose.
Your could search for and remove all tabs, newlines, extra spaces, and comments
If you are using php, IonCube has a plugin. it can be found here: http://www.ioncube.com/html_encoder.php it turns your html page into minified javascript.
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.
In a web application, is it acceptable to use HTML in your code (non-scripted languages, Java, .NET)?
There are two major sub questions:
Should you use code to print HTML, or otherwise directly create HTML that is displayed?
Should you mix code within your HTML pages?
Generally, it's better to keep presentation (HTML) separate from logic ("back-end" code). Your code is decoupled and easier to maintain this way.
As long as your HTML-writing code is separate from your application logic, and the HTML is guaranteed to be well-formed somehow, you should be okay.
The only code that should be mixed in markup-based pages (i.e, those that contain literal HTML) is the code used for formatting the HTML (e.g., a loop for writing out a list).
There are trade-offs whether you put the code in with the HTML or you use pure code to write the HTML out using quoted string literals.
No, if you want to build good and maintainable software, and to achieve loose coupling.
If I understand the question right, you're asking whether it's a good practice to mix markup with back-end code. No. While this is commonly done, it's still a bad idea.
You should read up on the MVC paradigm, as well as on existing questions on the matter, such as What is the best way to migrate an existing messy webapp to elegant MVC? and Best practices for refactoring classic ASP?
The point is to keep the display logic separate from the rest of the code. In any complex site you'll have code mixed in with your HTML, but the code should be for display purposes only. It shouldn't be doing any complex calculations.
For example, templates will contain loops and conditionals. Plus you'll probably have a library of HTML-specific routines, like printing out an <option> list based on a list object.
Imagine you were writing an application that has two output modes: HTML and something else. How would you write it, to avoid duplicating code? That will probably point you in the right direction.
The HTML that makes up the view has to get sent to the browser in some way. In .net, each server control emits its own HTML markup as part of the page lifecycle. So yes it is OK to use HTML in server side code.
Perhaps you should try following the ASP.net pattern. Create a bunch of controls that represent UI elements and make them responsible for emitting their own HTML based on their state.
Its fugly, and not type safe. But people do it without consequence. I'd prefer using a DOM or, at a minimum, classes designed to write HTML using type safe semantics. Also, its not all that good to mix UI with logic...
If I need methods that generate HTML I usually isolate them in an HtmlHelpers class. That way you keep some level of separation. The ASP.NET MVC Framework does this quite successfully.
If you mean printing out HTML in your code, then no. Unless you have a good reason not to, you should use templates
Even if you think you don't need this now, there's always a good chance you'll need it later. Maybe you want to output in a different format than HTML, or you want different presentation for the same data. You usually have the need for these things further down the road, so it's best to use one from the start.
I hate when developers print() a bunch of html. It's completely unnecessary and looks ugly in any text editor that shows print/echo strings in red.
I agree with everyone else that you should try as hard as you can to separate the HTML/XHTML markup from the application logic. However, sometimes you do need to generate HTML/XHTML in the application logic for various reasons.
In these cases what I have been trying to do is to ensure the bare minimum amount of presentation code is in mixed in with the application logic and try to migrate everything else over to the presentation code. It is worth nothing that is some cases you have situations where you could have everything moved over to the presentation layer, but it might be a bit easier to generate the markup as part of the application logic. In those cases, your best bet is likely to be to go the route that makes the most sense in terms of time.
I don't think there's any excuse for generating HTML inside your business logic. Don't even do it when it's just a "quick fix" or when you'll "go back and fix it later", because that never happens.
To reiterate my position from other questions, using some control logic (conditionals, loops) within HTML to construct it is OK. Do NOT do any data massaging or business logic in the HTML. You have to be disciplined, but it's worth it. Maintenance is much easier if your concerns (like logic and display) are separated.
Ideally you are aiming for a separation of concerns between your presentation (UI) code and your domain (business logic) code.
The reason why you should avoid coupling these two concerns (in either direction) is simple...
You will only have one reason to change a piece of code. whether this is from structural/styling changes in your html design, or from your business rules changing, you should only have to make the change in one place.
To a lesser extent, although many purists would disagree, by sprinkling HTML code through your domain code or vice versa you are creating noise for the next developer who comes along to read/maintain it.
I try to avoid using code to print HTML "directly". It is difficult to maintain, edit, add styles and etc. Some cases like generating an HTML email in the code, I create a text file or HTML file with markers like, [name], [verification code] and etc. I load this from the code and replace those markers. This way, you can edit the style of the email without re-compiling your code. Separating "presentation" and "logic" is a good practice in my opinion.
Mixing code within HTML is generally not a good practice in similar reasons as said in #1. However, I do use code in HTML for things like simple dynamic strings that are displayed multiple times on a page or pages. I think this is better than creating multiple server controls for same exact values to set. Since this is not code "logic" mixed in the HTML, I think this is ok.