First of, I'd like to mention that I'm aware of XSLT and XML DOM. I'm learning XML and know the basics (proper syntax, some DOM, etc.). For efficiency purposes, I need to figure out whether to begin learning XSLT in detail first or DOM.
Here is what I'm trying to do...
A table comparing home vs. competitor:
first column holding names of different features
second column of a static company
last column of a competitor that can be chosen from a drop down.
Would it be best to draw this table using XSLT or would it be better to do it using javascript (this approach?
I know both are easily done, but I need to be able to make a single column visible or invisible so that only one competitor column shows up, which will make it easier for me?
Thank you!
EDIT: I have this pretty much done using data islands/tabular data control (CSV files), but since it's only IE compatible, I thought I'd learn some XML instead.
Definition of XSLT:
XSLT (Extensible Stylesheet Language Transformations) is a declarative, XML-based language used for the transformation of XML documents.
Its designed to transform XML from one form to an other, i would use it.
Related
I'm working on building a sort of "word cloud" in the browser using html and javascript. The idea is to have a while bunch of words on the screen each one maybe with a different size or different color.
Issue is that I may need 100k+ words on the screen as it is a big area that will be covered. I have attempted to do this using pure html, using span elements with different styles for each word. However this approach makes the browser choke as I assume it is rendering too many DOM elements. Approaches using tables and divs were also unsuccessful.
I am wondering if I am approaching this the wrong way? I suspect there is a more performant way to do this, perhaps using canvas or svg, though these will require more work to integrate I would assume. I also want the user to be able to interact with some of the words such as deleting them or changing them. This makes the html approach seem easiest.
Any help or pointers would be appreciated!
I've made some code (tool? framework? Not sure what to call it) that is intended to make it possible to style CSS with Javascript but not jump when reloading or changing pages (so for use in traditional multi-page sites... not sure the conventional term for that). I'm no web expert so am unsure if it's worth developing this further or if there's better solutions to what I'm trying to solve (more than likely).
The basic structure is
A. Under certain client-side conditions (e.g. browser resolution, but could be anything, like a certain user using the site), CSS is generated by client-side JS, written to a file on the server under the appropriate heading relative to scenario (e.g., 1024x768.css, 102400x76800.css).
B. The server code checks (via cookies) if client-side condition is met, checks if css file pertaining to condition exists, uses it, otherwise generates it (A.)
Potential uses
You inherit a legacy site or clients insist on a certain template (Wordpress theme), with predetermined HTML structure, such that it's difficult to achieve a custom look just modifying the CSS. It might be much quicker to make calculations and adjustments with Javascript than refactor the HTML or figure out the solution in CSS (time permitting the ideal solutions, arguably). On the other hand, you don't want the style to jump every time you load the page since that looks tacky.
Edit: example of the above
As noted below in the comments, I can't think of a great example off the top of the ol' noggin. Right now my test is modifying a navigation menu of the type <div class="menu"><ul><li><a>Section 1</a></li><li><a>Section n</a></li></ul></div> such that the <a>'s have just enough padding on both sides that the menu <div> fully fills up the width of the browser.
I imagine there's a conventional solution to this, so if you're feeling in the mood, please let me know.
You want particularly complicated sizing, positioning based on complex calculations (dependent on screen size, or not), but, again don't want things jumping around.
Edit: example of the above
Positioning elements in a spiral pattern (say this kind) with diminishing size. This seems to be nontrivial in CSS, perhaps done by calculating the positions beforehand and placing with absolute positioning. But then there's the problem of having everything scale depending on screen resolution.
Alternately Javascript could calculate positions and sizes dynamically. Of course writing the method to correspond to the mathematical spiral function would be a challenge (though an interesting one).
There could be other solutions like using .svg, but if written generically it would be possible to position according to other mathematical functions (e.g., sine wave), or complex ratios (golden mean) fairly easily.
You want a site where the user can customize the look (reposition or even resize elements) and you want the customization to automatically get remembered and generated in the server-side code (perhaps even without a login). I'm sure this is facilitated by many frameworks, but this kind of divests the process from a specific framework.
I was wondering if other folks had thoughts on whether:
A. There's a better solution to all this I've missed.
B. The system I described of pushing CSS from JS to be written on server sounds sound, or if the same thing could be achieved another way entirely client-side.
C. And I guess since it's not a specific technical question whether this is the right place to ask this question, and if not, where I should.
Like I said, I'm no expert, so would greatly appreciate any feedback or other things that might help me to learn.
Thanks
I'm working on a JavaScript (using HTML as display tech) widget framework for an embedded device where memory consumption is a big deal.
Recently I tried to create a table-layout using only DIVs. But to mimic the colspan and rowspan functionality it became quite complicated, adding extra logic to make it all dynamic.
The result came out quite good layout-wise, but at the cost of too much memory consumption (had to have several JS objects representing each cell and then a DIV as presentation)
Wouldn't it be better to just use the TABLE element instead, getting the col- and rowspans and layout for free? Especially since all markup is crated by the framework and that the user (of the framework) never actually touches the HTML itself.
Or am I missing something here?
well tables are perfectly fine for tabular data if you want to do it right semantically.
And imo, you have to go for the best solution in your situation. Performance is more important than using div's or not in this case i guess.
If you start out with the mentality of "I need a table-layout", it's inevitable that you'll end up deciding that you need to use a <table>, because CSS cannot deliver on the subtleties of colspans and rowspans. But do you need a table-layout? You don't describe the underlying layout requirements, so it's impossible for us to steer you either to or from <table> except in broad generalities.
Go ahead and use a table. One of the main reasons that CSS layouts are encouraged is accessibility (probably you don't care about). Another reason is separating content from layout - you are probably creating both. So, the disadvantages of tables are of very low importance compared to the advantages in your case.
This is a bit of a vague notion which I have been running over in my head, and which I am very curious if there is an elegant method of solving. Perhaps it should be taken as a thought experiment.
Imagine you have an XML schema with a corresponding XSL transform, which renders the XML as SVG in the browser. The XSL generates SVG with appropriate Javascript handlers that, ultimately, implement editing-like functionality such that properties of the objects or their locations on the SVG canvas can be edited by the user. For instance, an element can be dragged from one location to another.
Now, this isn't particularly difficult - the drag/drop example is simply a matter of changing the (x,y) coordinates of the SVG object, or a resize operation would be a simple matter of changing its width or height.
But is there an elegant way to have Javascript work on the DOM of the source XML document instead of the rendered SVG? Why, you ask? Well, imagine you have very complex XSL transforms, where the modification of one property results in complex changes to the SVG. You want to maintain simplicity in your Javascript code, but also a simple way to persist the modified XML back to the server.
Some possibilities of how this may function:
After modification of the source DOM, simply re-run the XSL transform and replace the original. Downside: brute force, potentially expensive operation.
Create id/class naming conventions in the source and target XML/SVG so elements can be related back to each other, and do an XSL transform on only a subset of the new DOM. In other words, modify temporary DOM, apply XSL to it, remove changed elements from SVG, and insert the new one. Downside: May not be possible to apply XSL to temporary in-browser DOMs(?). Also, perhaps a bit convoluted or ugly to maintain.
I think that it may be possible to come up with a framework that handles the second scenario, but the challenge would be making it lightweight and not heavily tied to the actual XML schema. Any ideas or other possibilities? Or is there maybe an existing method of doing this which I'm not aware of?
UPDATE: To clarify, as I mentioned in a comment below, this aids in separating the draw code from the edit code. For a more concrete example of how this is useful, imagine an element which determines how it is drawn dependent on the value of a property of an adjacent element. It's better to condense that logic directly in the draw code instead of also duplicating it in the edit code.
We have done this in our in-browser XML editor Xopus. You can see an example here.
We load the XML source document, an XML Schema and an XSLT that outputs HTML+SVG. Internally we rewrite your XSLT into XSLT' which will allow us to track the output HTML+SVG back to the original XML that was the context in the XSL to output that HTML or SVG node. This is the framework you're referring to.
To facilitate editing we position a cursor over your XSLT output and update the XML DOM when you type or insert elements. After each change we will rerun the XSLT. For performance reasons we will compare the XSLT output with the previous output and apply the changes using HTML DOM operations to the WYSIWYG view.
We diff the two XSLT outputs using another XSLT. We can do so because we have modified the original XSLT (resulting in XSLT') so that is will output unique and persistant IDs for each output node. So all new nodes will have new IDs and missing IDs are removed nodes.
XSLT' is the rewritten version of the original XSLT you provide. It is still XSLT, but we've added a few things to it so it outputs IDs for all output nodes (we do so with yet another XSLT). Other than that it is functionally equivalent to your original XSLT.
Maybe use can AJAX: Instead of editing the document locally, send editing commands for the original XML to the server which transforms again and then sends the new SVG back.
The main problem here will be what happens when you update the SVG element on the current page. Will drag'n'drop still feel smooth? If not, then you might have to resort to some mix of the two methods: Drag the SVG node using JavaScript and when the user drops the node, send an update to the server for a new SVG.
You will want to avoid trying to synchronize updates in XML and the local SVG (which would mean to replicate part of the XSLT in JavaScript -> stay on one world, don't mix).
I have been working on a project that dynamically creates a javascript file using ASP.NET which is called from another site.
This jquery javascript file appends a div and fills it with a rather large HTML segment and in order to do that I need to turn the segment into a string like so:
$(document).ready(function(){
var html = "Giving this magazine such a lofty epithet may seem a bit presumptuous, but for a non scientifically trained outsider this magazine offers a fresh and challenging look at the fast paced world of science that doesn't shy away from humor and the use of terms and ideas that may require its readers to go online and define a term. And in some cases it may inspire the reader to pick up a book on science by such greats as Hawking and Greene in order to better grasp some of the concepts dealing with time, space and atoms. This magazine isn't dumbed down. It includes well placed and efficient illustrations to help explain some of the more abstract points. It is not designed in the way popular magazinea are, in so much as they only touch upon a topic in the simplest manner and then move on before the audience is lost. Yet this magazine keeps the attention of the reader by combining explanatory notes that help people with no background knowledge have some grasp of the topic and by using humor and well written articles to clearly make their points. <br />For a magazine with a serious and well researched list of topics having small cartoons the likes of the New Yorker shows how comfortable this magazine is with itself. From the moment I picked up this magazine for the first time I felt like every word I read mattered and was worth my time to read. (Not true of many other magazines) American Scientist may not have the audience of Discover or National Geographic, nor is it as accessible as said titles, but for those with a true interest in science willing to challenge themselves and commit to real learning this magazine may be a perfect fit. At $4.95 it is certainly worth it to pick a copy on the news stand and try it out."
$("#divname").append(html);
});
As you can see the segment will be pretty large and I have no way of knowing how big as it is generated dynamically from my database depending on the reviewID which is defined by the user in their request.
The html to be inserted into the div is a list of reviews and is generated using asp.net MVC by a repeater which loops through a list. (if that helps give you an idea of what I am doing).
Is there any way to turn this large segment into one string which can be inserted into the append script?
Thank You
Cross domain jquery json
http://docs.jquery.com/Release:jQuery_1.2/Ajax#Cross-Domain_getJSON_.28using_JSONP.29
Some ideas:
You can replace new lines with spaces and create a huge line. There shouldn't be a problem with it.
Use string concatenation. Split the string and lines and do:
var html = line1 +
line2 +
...
linen;
Make an Ajax call to fill the div:
$("#divname").load(service_url);
You need to create a service that will return the string.
In my opinion the 3rd option is better than the other ones.
Correct me if i'm wrong but i think everything between the starting and ending quotation marks would be considered part of that string no matter how many lines it has. Unless your string has got any quotation marks in itself, in which case it'll be better to do the equivalent of php's addslashes() function in ASP on your string, which should add a \ before all the " marks in the string.
Another idea can be to use Json to encode/decode the string.
i don't see what's wrong with just generating one big-ass long single-line string and appending it just like you are doing. period. done. Fancier isn't going to gain you anything.
Hide it else where on the page and populate the div with it when you need it?