I have been developing web apps for a while now and for the past year I have been really exploring as many technologies as possible. I know some people are creating pages using XML and XSLT or maybe css style sheets; however, it seems to me that the trends are still not moving in direction. Plus it seems less functional/easy than XHTML/CSS based pages.
What are the benefits of using XML/XSLT, and is it ideal to start developing in that manor? Is there anything else new that is pulling ahead of the pack in regards of front end web development?
The reason I am bringing this stuff up is because it seems that many people are switching from XML as a datasource to JSON, which makes more sense as a datasource; however, XML is still functional as a markup language...
And on that note, why would I even want to use XSLT vs CSS for the XML pages if i were to start develop that way. It seems to me that they serve the same purpose except that XSLT looks like tag soup.
I hope this question makes sense....
XSLT can be useful if you have an XML data source that needs transforming into HTML. Otherwise you should be using HTML, CSS and jQuery for front-end development.
Right now, there is no reason to use XSLT at all. It's virtually incomprehensible compared to XML/XHTML, and offers no real advantage for you or your users.
As for using XML in lieu of (X)HTML, with the growing acceptance of the emerging HTML5 standard, I can't see why you'd give up canvas and the (eventually, they'll be good!) audio capabilities for XML. Even now, XML is nice for marking up documents, but for marking up a webpage, HTML is king – it's essentially XML tailor-made for the web.
There is no antagonism between XML/XSLT and XHTML/CSS, these are complementary technologies. Thus, in my web apps, XHTML pages are produced by mean of XML/XSLT (transformation occurs in client side).
You'd use XSLT to transform some XML document into XHTML. Then you'd use CSS to style the XHTML.
XSLT is for transformation of one XML format into another. The data stays the same, but the representation changes. There is even XSLT-FO, which transforms XML into other objects, like pdf.
Also note, XSLT can be used client-, or serverside. You can do XSLT transformation in the browser or with a simple handler on the server. Java-based nonsql data stores like existdb use XQUERY to transform database entries with XSLT to any other XML format, including XHTML.
Using XSLT to generate XHTML from simple XML documents basically gives you a templating engine.
Since browsers still lack XFORMS support, you can use javascript+XSLT to transform XFORMS into valid HTML.
JSON is used to serialize and deserialize objects and transport them, thus replacing XML as a transport format, more specifically as a AJAX query response, in rich internet applications.
Related
I have a URL which is using an API key and driven and displayed as XML. I have attached a screen shot as to how the information is being displayed in a browser. However, I need it to look more user friendly. Is this possible at all? The information is the details of an address book from DotMailer.
I'm rubbish at coding so an idiots guide would be great! : )
Depending your knowledge, you have a lot of options, eg.:
using XSL in this or in this way, if you could not modify the XML (you should be able to put the stylesheet directive with the xsl file there to let the browser do the transformation), you can execute an XSLT in javascript
using javascript to parse the XML, and you can generate and add the HTML version to an output div
if your XML is generated at server side, you can use XSL too, or you can generate HTML at the server side using pure server side language (PHP, C#, Java, etc.), if you are a bit advanced, you can choose a template engine (smarty for PHP, T4 for C#, freemarker or velocity for Java, etc.), and go with it (the template engine can be an option at client side too), or you can stick at XSL, almost every server side language supports it.
Of course, you should create some CSS too to produce a nice output.
If you can provide some additional hint I can provide more accurate answer.
We have an old ASP.Net application which gets data from a database and generates HTML output to present that data using normal ASP.Net features.
Our customer wants better control of the HTML output, and is therefore suggesting that we store data in XML files, and they deliver and XSL file which transforms the XML into the desired HTML.
The produced HTML contains HTML tables, lists, CSS class references and javascript.
My first thought here is what is the need for ASP.Net then? We cannot avoid using it, as a lot of our code is written in C# and ASP.Net. But are there some issues we should keep in mind, as to why not to choose this method? Does anyone out there have experience doing as we are about to do? Will we meet any dead ends that make us incapable of fulfilling the customers' needs? What about performance for example. All those questions popped to my head when I heard about their request.
Any advice is welcomed here
Thanks
Jihad
If presentation is the only problem, you can use a Jquery type framework with HTML5 and better CSS to improve it. There is no reason to go the XML+ XSLT way.
All you will need to do is to change the style/design on the .aspx pages leaving the .cs pages intact.
How do you minimize the pain in your development process when it comes to reporting?
For web frameworks, there is a pretty straightforward way to both produce content as well as graphically design it; content is represented semantically through HTML, and the design is separately specified through CSS. And browsers are fairly consistent with how they render the output (and the inconsistencies are well-known and can be planned for). There are even WYSIWYG editors to help out less-CSS-savvy graphical designers.
But what do we do about print content?
At one company, I created a process that worked like this: A script generated a semantic representation through XML. The XML was passed through XSLT to generate an XML-FO document. Then, this was passed to another tool (Apache FOP, I believe) to generate a PDF. This worked well for that company.
At this company, however, output appearance matters to management, and we have a graphical designer. Currently, we are using a reporting tool (XtraReports from Developer Express, version 8.1). It isn't bad; it outputs to a variety of formats, has a WYSIWYG designer, reports are implemented through C# classes, and it supports data binding to data sets (unfortunately, not POCO's). However, we have some major pain points with this setup:
The reporting framework has major limitations on how you can lay out and group your reporting bands
Presentable elements, especially charts, lack the capabilities we need to fine-tune and achieve the look of our mock-ups.
There is no good way to share styles and layout among reports akin to what we can get through CSS.
Good composability of reusable parts is very hard to implement. So we end up with a lot of copy & paste inheritance of functionality; this is bad news whenever we need to make sweeping changes across all reports.
Now, maybe there's some kick-ass framework out there that can eliminate the pains of reporting frameworks, but I assume that they all have their weaknesses. Do you have a framework or process that works well for you and reduces the pain points inherent in reporting?
Prince XML is a really cool tool which allows you to use HTML or XML styled with CSS (including CSS paged media for printing) and generate PDFs from it.
Option #1 : Adobe Acrobat is really nice. You can design form enabled PDFs and then use something like PDFSharp to manipulate the PDF document. You can create template PDF's that you dump your generated stuff into. I've done this before and it was pretty successful. I also used POCO objects nicely.
Option #2 : You could start creating XPS documents, which is XML based anyways. And they can be easily converted to PDF if necessary.
Option #3 : Run for your life.(might not be an option)
i-net Clear Reports is a nice product. It's based on Java but you can also work with ASP.NET. There is a bridge. The .NET version is in work if you want work with POCO. Because the Java version can work with POJO that the coming .NET version will also work with POCO.
It has been suggested that I use CSS for displaying XML. I know in my heart that this is wrong, but cannot find the words to adequately convince others. Can anyone provide me with a list of pros/cons of using CSS and XSLT for displaying XML.
Thanks!
What your heart tells you is correct. Though it is possible to use CSS for XML, XML itself does not have any semantics. CSS is meant for the web, for HTML and for giving semantic data a (good) look.
XML is way more general then that. XSLT is was invented for transforming one data format to another (XSLT 1.0 only XML, XSLT 2.0 any Unicode data format), i.e., XML to HTML or XML to XSL-FO or another XML or text format. XSL-FO was invented for laying out XML on paper or screen and is much more detailed then CSS.
Some pros and cons on CSS+XML
Mainly cons, esp. in the light of using XML in a browser. Skip to the overall advice below if you don't want all my babbling ;-)
CSS cons 1: no CSS+XML for internet
The cons: it depends a lot on the context, but if you want to use XML for display on the internet, think again: don't use XML, but transform it into HTML. Then use CSS + HTML to display your data. If you use XML on the internet, no search engine or crawler, will understand the difference between <x> and <y>, but they will understand the difference between <h1> and <h2>.
This alone is enough a reason for using XSLT to transform to HTML + CSS and avoid XML on its own.
CSS cons 2: CSS means lots more work
The other extremely big reason you can use: XML + CSS means defining each and every element in CSS. Using HTML + CSS means user agents already know the default layout properties for all elements. Using XML + XSLT means usually you create HTML + CSS. You should do this on server side, because client side XSLT is not very reliable and cross-browser compatible still.
CSS cons 3: accessibility
(sorry, I can't find pros) Unless XML has semantics (SVG, as mentioned by another user), it makes little sense to use CSS for layout. If the layout is supposed to be semantically understood by a user agent, XML + CSS is a no-go. Text-to-speech readers have no idea what to do, WAI (accessibility) validity will be impossible etc.
CSS cons 4: maintainability, understandability, scripting, trouble
Using XML makes it hard to do any client side scripting (yes, the DOM is available, but how do you tell the browser what the script-tag is? But perhaps it'll react to <script>, but hey, you need XSLT to get that tag in there) and makes it hard to make it cross-browser correct (some browsers have a hard time using XML per se). Anything HTML (like meta, title, body, script) will not be available. There's no way to add title attributes or to tell the browser what an image is (afaik).
No script in existence will work on you XML-only page (prototype.js? jquery.js? ajax? no no and no).
Anybody looking at your code will have to learn what each tag "means". Using XSLT to transform to HTML, prevents this. This extra step is beneficial and should be applied whenever you go from XML to browser display.
CSS pros 1: domain specific
If your domain is SVG, SMIL, OD or anything else, you probably already know this: CSS is an integral part of the specification and should be used. This is completely different from pure, possibly unstructured, data XML.
AJAX thought
Just for comparison: any asynchronous AJAX call (should) return XML. But any library working with it, will either interpret it as HTML, or will use XSLT or another means to transform it prior to injecting it in an existing page.
Overall advice
Based on the remark from the OP, we are looking at data XML (not SVG or OpenDocument) and it needs to be displayed in browsers. Accessibility and indexability are not important. But that doesn't really matter: you shouldn't use XML + CSS alone, unless you're really into some adventure and want to find out all the shortcomings of XML in browsers, want to invent every HTML tag again and define each and everything, only to give up after a while and revert to HTML (XML + XSLT == HTML + CSS).
Update: added cons 2
Update: added cons 3 and pros 1
Update: added cons 4, AJAX note and a conclusion
CSS:
Styling and overall visual presentation
XSLT:
Styling and visual presentation (if desired)
Allows complete and radical changes of the actual tree that's rendered
If your XML maps pretty nicely to individual layout elements then use CSS, if you need more work in adapting it for display, then use XSLT. Things like arbitrary re-orderings of content or collapsing multiple lists of values into a table, etc. don't lend themselves well to CSS. CSS really only works nicely if your overall structure of the document is already the same you want to display.
CSS seems to fail for XML in IE8: How to apply CSS to namespace prefixed elements in IE8?
There is nothing inherently wrong with using CSS to style XML, it's just not done very often (although I've done it in the past as an experiment).
Take SVG as an example: it's XML, and it can be styled with CSS. Also, have a look at section 3.1, "Definitions", of CSS 2.1:
Source document
The document to which one or more style sheets apply. This is encoded in some language that represents the document as a tree of elements. Each element consists of a name that identifies the type of element, optionally a number of attributes, and a (possibly empty) content. For example, the source document could be an XML or SGML instance.
Document language
The encoding language of the source document (e.g., HTML, XHTML, or SVG). CSS is used to describe the presentation of document languages and CSS does not change the underlying semantics of the document languages.
(My emphasis).
The primary possibilities to consider in deciding whether whether to use CSS as opposed to XSLT strike me as being:
Does it make sense to transform the XML document into a different structure (e.g. XHTML) the better to represent the semantics of the document?
Is the semantic structure of the document sufficient in itself, such that only presentational styling needs to be applied?
If you have some pretty arbitrary and meaningless XML - something like <data><column><row><value>1</value><value>foo</value></row></column></data> then the XSLT route would make sense. If however you have a document that has its own clearly defined semantics (e.g. an SVG file, or one of any number of XML applications) and all you want to do is make the headings stand out and the font look nice, then CSS is fine.
Ultimately, do the simplest thing that could possibly work. CSS - at least from version 2 onwards - was specifically designed to be language-agnostic (that is, not tied to HTML) so there's no good reason not to use it when it makes sense.
Did they mean a stylesheet? Any XML Stylesheet is different to a CSS stylesheet. XSL is sometimes refered to as a Stylesheet so you might both be right :)
Simple situation. I'm trying to write my own blog with a minor twist. Part of the blog will be controlled from a client application instead of a web interface. Basically, I'm still in the design phase and haven't written a single line of code. But I'm trying to combine several techniques into an interesting exercise in software development. Thus I want a client application which I can use to write articles in, which can then upload the article through a web service to the server. (The client would be Delphi 2007/WIN32 and the service is ASP.NET/C# with SQL Server.)
The article itself would be stored in RTF format, including images. This would be in a local database on the client, which would also keep track of the article's status. Once uploaded, it will keep the article synchronised with the version on the server. Technical details are just boring and as said before, still in a design phase...
But I do need a good solution to convert the article from RTF in the database to HTML to be displayed in the blog. I have two options:
Upload both the RTF and HTML from the client, with the client doing the convertion from RTF to HTML.
Upload just the RTF and let it convert on demand on the server. (Or convert on the server when the RTF is uploaded.)
Option 1 would need a Delphi/WIN32 solution to convert it while option 2 would need a .NET solution for the conversion. I don't want an RTF editor for .NET but need a good option to use in Delphi 2007. And I need something to convert an RTF to HTML, which would keep (almost) all formatting and which would include all images from the text. This could be both in .NET or Delphi.
So, I have the following questions:
Is there a good, free RTF editor for Delphi which can handle images?
Is there a good RTF-to-HTML converter for Delphi or C# which can keep as much of it's formatting intact as possible, including images?
Some good suggestions for .Net:
Convert Rtf to HTML
Since you provided so much background about why you are doing it, I am going to provide some feedback on the whole plan. This may not be an answer to your question directly though. Sorry.
You might consider looking at Windows Liver Writer for the client. If you just implement an API it supports then it can do all the editing.
Also, I would suggest skipping RTF all together. Converting from RTF to HTML will loose some formatting, and typically create sub-optimal HTML. Creating an RTF with the sole intent of converting to HTML is a less than optimal solution.
Instead keep it HTML for the round trip. If you must use RTF, then limit the RTF formatting to the HTML formatting you want to support. That way the conversion will be more accurate. Then convert as soon as possible, providing a preview for the poster. Since it won't always convert accurately you want the poster to see any of the conversion oddities before they make them public. That way they can fix them before they are embarrassed.
You'd better take a look at TRichEditWB component in EmbeddedWeb component pack. The whole pack is open-source:
http://www.bsalsa.com/forum/forumdisplay.php?f=29
You can add image, and even controls like buttons and checkboxes to TRichEditWB. It also can hilight HTML and XML code, and recognize URLs automatically.