I have a XML which works with an XSLT file that transforms the XML into a table on an HTML page.
I need to be able to update this table based on what the user selects from a drop down. Two options:
send new parameters to XSLT processor, re-transform, clear old HTML content, places new HTML content; do this every time drop down changes value
use javascript function to navigate HTML code directly and unhide/hide table data cells.
What would be better performance-wise?
EDIT: basically trying to apply filters
The second option. There's a difference between modifying HTML and modifying serialized DOM. If you clear the DOM and give the browser a new HTML string to replace it with, it will have to serialize that HTML into DOM. If you use JavaScript to modify parts of the DOM, then not only will you skip that step, but you'll be taking advantage of optimisations in the rendering engine that restrict re-layouts to affected elements in the DOM, rather than the entire document.
Related
I produced a manual for my Eclipse RCP application using Eclipse help system.
I would like to export this documentation as a browsable offline html documentation.
To do so, I used Eclipse export function from Help System at runtime which produced a plain HTML file with table of content in the top of the document.
My question is, is there an automatic way of separating the table of contents and the contents itself?
Example, specifying an Iframe that use this single document and specify src attribute from the beginning of the document to the end of the table of contents, and a second Iframe with same plain html document as src but which would begin at the beginning of the contents.
For instance, using two iframes, the left hand one for the table of contents and the right hand one for the contents.
I could do it manually or implement a parser using jdom but if you know a better solution...
I also thought about enclosing the whole HTML document with a table with a single row and two columns, one for the table of contents and one for the contents but the bad point is that when selecting an entry in the table of contents, both "sides" will scroll I think. I would like the two parts to be decorrelated, fixed table of contents with a vertical slider if needed and contents in the right part.
Best regards,
Christophe.
I'm running a Django site with XML text stored in TextField properties. It's stored as XML rather than plain text because it's heavily annotated with information about the underlying manuscript, such as abbreviations and symbols. Here's an example:
class Entry(models.Model):
# Name and description.
chapter = models.ForeignKey(Chapter)
latin_text = models.TextField()
Here's an example of the content of latin_text:
<initial type="2">I</initial>n <place type="0"><span>Ricmond</span></place>
ten<abbr type="1">et</abbr> aeccl<abbr type="0">esi</abbr>a
de Cietriz .ii. hid<abbr type="0">as</abbr>.
I'd now like to start displaying that XML text on my HTML pages.
I know I can display raw XML by dropping it into a textarea: the issue is that I'd like to display it in a more beautiful way, with:
styling (all the abbr elements in italics, the place element in bold)
JavaScript events to let the user explore the abbreviations (when the user mouses over an abbr or place, show a pop-up explanation)
I'm not sure if XSLT can do what I need, or even if it can be used alongside HTML. So my question is:
Should I transform the XML into HTML before adding it to the Django database?
Or can I do all the rendering I need on the fly with XSLT or JavaScript?
I would use xslt to transform it and then attach events programmatically with javascript. It is data and converting it before hand prevents you then interpreting it in a different way later. Html should be layout only and separate from the data. You could translate it with Javascript but that will be intensive on the client. Xslt and css will be cleaner and attaching events in js is lightweight.
Not familiar with Django but maybe check this answer out : Can I use XSLT in Django?
Yes, XSLT will do everything you want and is heavily used by those who store XML just like you have. It is why and how XHTML came to be. For those who stored data and text in XML but wanted to present it to web browsers.
Once you have it in (X)HTML form, adding and using javascript is no different.
I have two divs for different sections of my webpage, a working and a reference section. One is fixed size, the other is variable sized and they are vertically stacked. I am trying to design it so that if you want to work on something in the reference pane, you click a link and it swaps all the data between the two panes. My idea was to do the following:
var working = $("#working_pane").html();
var ref = $("#reference_pane").html();
$("#working_pane").html(ref);
$("#reference_pane").html(working);
The problem with this, is it seems that any javascript referenced inside of these panes (for example, in place editors) get broken upon switching. No javascript errors occur, it's just that nothing happens, like the javascript ties are broken.
Is there any to move the html without breaking the javascript contained?
When you are working with bits of an HTML document, you should aim to work with the Node objects that are the content as the browser sees it, not HTML strings.
To get HTML the browser has to look at the Nodes and serialise them to a string. Then when you assign that HTML to another part of the document (with innerHTML or jQuery html(...)), you are telling the browser to destroy all the content that was previously in the element, laboriously parse the HTML string back into a new set of Node objects, and insert these new Nodes into the element.
This is slow, wasteful, and loses any aspect of the original Node objects that can't be expressed in serialised HTML, such as:
event handler functions/listeners (which is why your editors are breaking)
variable references other JavaScript code has to the Nodes (also breaks scripts)
form field values (except, partially, in IE due to a bug)
custom properties
So — and this applies whether you're using jQuery or the plain DOM — don't throw HTML around! Take the original node objects and insert them into the place you want them (they'll leave the place they originally were automatically). The references stay intact so scripts will keep working.
// contents() gives you a list of element and text node children
var working = $("#working_pane").contents();
var ref = $("#reference_pane").contents();
// append can be given a list of nodes to append instead of HTML text
$("#working_pane").append(ref);
$("#reference_pane").append(working);
This could be happening maybe as a result of duplicate ids. basically you may have element a in a div which has the id=id1 now this gets stored in a var and gets injected into a new div. now currently seems you have no mechanism for making sure you do not have duplicate ids at the same time. this can break js
So look into this and if you do make sure elements are first stored in a var then the originals are removed and then appended into a new location.
I'm building the HTML code within an XML DOM object to be used as the contents of the innerHTML of a div element using an XSL template. Traditionally we create a new XML DOM document and add the input parameters as XML Elements for the transform via javascript. This is all very time-consuming as we are basically hand picking the data from another XML document that represents our current account and copying the data into a transient XML DOM document.
What I'd like to do is clone the relevant node of the account document (i.e. customer info) and use it as the basis for the transform. I don't want to use the account document directly as I'd like to be able to add transform specific input, without making changes to the account object.
How efficient is using .cloneNode(true) for a desired node of about typically less than 200 elements from a document of typically 2000+ elements? The target platform is IE6 with no external tools (i.e. ActiveX).
CloneNode is pretty efficient but it will be consuming more memory doing it that way.
Another approach to consider is to use a Template object and a processor, pass your additional/changed data as parameters to the processor and the element that you would have otherwise cloned as the input element. This approach would require fairly significant mods the XSL though.
IE will fail on certain things.
e.g. checked radio/checkboxes will not be checked when you add your copy to the DOM.
Example:
http://webbugtrack.blogspot.com/2008/03/bug-199-cant-clone-form-element-in-ie.html
http://webbugtrack.blogspot.com/2007/08/bug-242-setattribute-doesnt-always-work.html
To see what IE will actually return, try replacing the url with this in the Address Bar of one of your pages, and press enter.
javascript:'<xmp>'+window.document.body.outerHTML+'</xmp>';
If you are happy with the results, great!, but I think you'll end up less than satisfied at what IE returns (both in the DOM, and this "string" value equivelant.
If you don't need form-elements, cloneNode is a real reliable tool ...
-- and in inserting ajax-data it is incredible in efficiency ...
However, as especially IE has a history of having problems with name-attributes, it is inconvenient to address any of these if you insert data ...
-- I don't really understand your XSL(T)-using, to me it sounds like using a gas-station as a (not !-) convenient place to change a 1960 WV to a 2008 Skoda ...
Userely they have some common technology, though it is not used in the same way, computerization in some way is just a minor problem, the major problems is in nearly any other way !o]
Have you got any need for form-elements ?-)
I'm trying to make an AJAXy submission and have the resulting partial be inserted into my list at the proper place. I can think of a few options, but none is terribly good:
Option 1: Return JSON, do rendering in Javascript. That seems like the wrong place to render this, especially since the list itself is rendered in my application server. It has the benefit, though, of making it easy to access the value to be sorted (response.full_name).
Option 2: Return an HTML fragment, parse the sort value out. Parsing HTML in Javascript is probably worse than rendering it.
Option 3: Return an HTML fragment that also contains a <script> section that gets evaluated. This could add the DOM node to a master list and then make a JS call to insert itself at the right point. The downside here is that IE doesn't evaluate <script> tags when innerHTML or appendChild are called.
Personally I would do #1. Nothing is wrong with combining the server-side generated HTML with the client-side generated one, but if it is a complicated procedure it is better to keep it in one place (on the server in your case). So you may want to return (as JSON) two values: the sort value, and the HTML snippet.
After that it is simple: find the position, instantiate the snippet (e.g., using dojo.html.set()), and place it with dojo.place(). Or instantiate it directly in-place.