Best way to cycle through pages of data in multiple tables? - javascript

I'm aggregating network data from all our Cisco switch ports, plus other stuff from other databases, and am outputting into an HTML file that renders strikingly like this (except I'm an idiot and just realized I drew "tbody" everywhere instead of "thead"):
I'm only displaying 10 rows of data for now in each table (which they are HTML tables with tbody, thead, and tfoot tags assigned; No PHP, Javascript, etc. at all yet, just pure HTML) to keep everything neat and similar (some switches have 48 ports, some 24, etc.). I'd like to use those "Prev, 1, 2, [...], Next" buttons to cycle through the data of each switch, preferably without the page refreshing.
What I've used in the past is this setup:
Give each possible data set to show up its own "div" id
Make their "style.display" attribute = 'none' (except the first page)
Have a Javascript function that puts these divs in an array
The function can hide and show divs and will show only the div I pass
as an argument
Tie this function to an HTML button's onClick event
Is this the best way to go? Since I'm creating this HTML dynamically (I'm outputting text from a C++ program to index.html like a boss), it would mean an issue of assigning div ID's to many different sections, and even then could I create the function to update only the div that the button's parent is in?
I'm thinking this is possible and certainly time-consuming, but I'm not a great web programmer. If there is a better way out there, I'd like to hear it before I proceed to spend too much time on this.

If you don't mind an additional library, datatables would make paging easy (and, as you mentioned, just pre-populate then let JS do the work).
The downside is it's an included library (which means either directly including it in the HTML within a <script> or find a CDN reference to it). The upside is that the paging is built-in and all you have to worry about is getting the data in there. Then, with a few quick config options, and optionally some .CSS changes, you have the desired result.

You can use event delegation to set only a few event handlers:
var footers = document.getElementsByTagName('tfoot');
for(var i=0; i<footers.length; i++) {
footers[i].onclick = function(e) {
console.log(e.target); // the clicked element within the footer
}
}
This will create a single click handler for each table footer, and you can detect which button was clicked by looking at the event object's target property (or srcElement on oldIE). Then you can traverse the DOM relative to that element, using standard properties like parentElement (see MDN for reference).

Related

Continue modifying DOM as user scrolls

I have a chrome extension that modifies the DOM based on keywords. The problem is, for websites like twitter that have an infinite scroll, I need a way for my function to keep firing as the user scrolls through the page.
Is .livequery() the only way to do this or is there a better way?
Right now all of the logic is plain JavaScript/Jquery, but I'm open to using a framework like Angular if that's the best way to do it.
I have several functions that interact -
1) a hide() function that adds a class to divs containing words I want hidden
2) a walk() function that walks the DOM and identifies divs to call hide() on
3) walkWithFilter() function that gets words to filter from localstorage and calls walk() function
The last function walkWithFilter() is called in a window.onload() event
It seems like the onScroll event would be a natural match for this. The trick would be that you'd need to keep track of what's already been processed to avoid reprocessing old content. If you're assuming that the user is always exposing new content below the existing content, that could be as simple as keeping a pointer to the last processed item and restarting the walkWithFilter method from there. That doesn't seem like an entirely safe assumption to me, though.
If you want to be more robust in that regard, you could try a virtual DOM approach: you maintain a copy of the DOM as you last saw it, compare it to the DOM as it currently exists, and take a diff. I know there are a bunch of premade libraries for this kind of thing, but I haven't used any and can't recommend a specific one (the link just goes to the first example that showed up in Google). It also doesn't appear to be overly burdensome to roll your own, if you're so inclined.

Sequence divs using javascript onclick

Is there a way to click on a div and save this click sequence value in the db.
Say I have ten items in 10 small small divs and I want them to be sorted in the sequence i click on them. So clicking on the first one will be sorted first and the next and then next.
Want to be able to do this with Javascript. Have seen this happening in desktop application where form fields are sequenced for tab order as you click on the fields.
The easiest way to do this is to bind to the click event of the divs, and pushing the div elements onto an array whenever they're clicked. Then you can use .prepend() to the container array by popping the elements from the array. Here's an example..
I can give you a conceptual format, because a full-fledged deal will be quite long, and also because you've posted no code.
Ensure that each div has a unique id, and has at least one common CSS class e.g. sortable - this is critical, as it will allow you to query the DOM for those elements for further sorting. And, regarding ideas for the id of the divs, I have seen variations of usually some identifier like post id from a database;
You have a listening function is run when the window is loaded, that listens for when any div that has the class sortable is clicked. You override the default action, and use the class in tandem with the div id to keep a record of which elements were clicked and sort them accordingly by whatever criteria you deem fit (id, date, content). However, then you have to manipulate the DOM to be modified to properly represent your new ordering. This can be done in two further ways:
Your sort can be real-time (which is laborious and involves higher RAM usage and a lot of DOM manipulation, but it is doable).
Or, option 2: perform a static sort where this information is passed via a form to another page, which redirects to the same page or a new page with the reordered DOM. Another way of doing that is to purge the DOM tree and rebuild it in the same page with Javascript using the sorted information upon the submission of a form, or the click of a button.

is it possible to view one html element twice on the same page, or must I create a duplicate?

I am creating a site that allows viewing and editing the contents of the 'src-div' contents within the 'edit-div.' I am not editing the src-div directly, because its thumbnailed using css zoom property.
I have considered using knockout.js to bind both elements to an observable. Currently, I have implemented the feature with jquery .html() function: simply set edit-div innerhtml to src-div innerhtml on 'select', and reverse the process after changes are made to edit-div to update the src-div.
I am wondering if I really need 2 divs here, or if there is some way to actually view the same element twice on a page, and any changes made will automatically reflect in both 'views,' elimiating the need to copy innerhtml property back and forth between two elements.
essentially, this is like a mirror effect, without the flip.
the closest thing I found so far is:
http://developer.apple.com/library/safari/#documentation/InternetWeb/Conceptual/SafariVisualEffectsProgGuide/Reflections/Reflections.html
Any recommended practices for performing this task are appreciated.
(Almost) everything you see on a page has a counterpart in the DOM. Everything in the DOM gets exactly rendered one time (apart from pseudo-classes). And every node in the DOM can only have one parent (no exclusions).
Unfortunately you'll have to clone the specific node and add changes to both, as there is no copy & translate mechanism in the current CSS documentation.
If you're using jquery you can use one div and "clone" it. You can read this for more information.
http://api.jquery.com/clone/
If you set the class of the div to the same thing, you can have changes propagated to both. Then you can apply .addClass to the second div to apply a "reflected" affect (if that's your final goal).

Proper way to show popup data on a web page?

I have a list of items for which I want to show a couple of items, then a "more" button. I would like the more button to show the new items in a popup box. There are many ways to make this work, but I'm trying to figure out what is the best practice.
Here is my approach. We use MooTools and Clientcide on our site:
Directly following the "more" button, I include a div that contains the content I want to put in the popup (the full list, including a duplication of those items that are visible by default), with a class that includes the style "display:none".
I attach an event to the more button that runs a script called "popupNext". popupNext takes the next element after the button (using getNext from mootools), and creates a new StickyWin (via Clientcide and stickywin.ui) with that element as its content. Then (and this is the part that feels especially hacky) it removes the class that includes the "display:none" style from the content element.
Finally, I use element.store() (from mooTools) to store the StickyWin (with the key "win") in the event element. I neglected to mention above: when popupNext runs, it first checks via element.retrieve() whether there is an existing StickyWin, and shows it, if there is.
This all seems OK, I guess--the biggest disadvantage is page bloat--while I'm showing only first couple of elements of each list, there may be more that are loaded with each page but never seen. But I'm curious whether there is some better, standard way of doing this. For example, I could reduce bloat by retrieving the elements via ajax, at the expense of slower response when a user wants to see the full list.
Check out StickyWin.Ajax - it seems to be closer to what you need than the plain StickyWin.

using hidden elements in pages to store data

I need to store data in html documents that are associated with elements, and that I can get to with javascript. I think I want to avoid arbitrary attributes on elements, since after reading various posts here I don't trust them. I can't use id or class, since I those are used for other things and I don't want to mess with them (my project has to work on wide varieties of html so I can't make any assumptions as to the design of the class and id structure). Another thing I need is for whatever I do, it needs to survive round-tripping through innerHTML (of a parent or ancestor element of the element I need to tag with data), with data intact.
I have considered various hidden elements (including script tags and html comments), which I insert into the document right before the element I need to tag with data. Currently my favorite is hidden form elements (i.e. input with type "hidden"). I can stick any data I want into the "value" of the element, and I can find all such elements easily enough with getElementsByTagName(). Also importantly, it doesn't seem to affect the layout of the page.
I'm curious about the ramifications of this, and if anyone can think of any any problems with it. I need to be able to put them anywhere in body of the page, before any element. For instance I might need them associated with an option element (a child of a select element), so that rules out using a hidden div, since putting one of those inside a select element is illegal. I don't think they will affect form behavior, since they don't have a name attribute (I can avoid using id's if that helps).
Any thoughts on this, or suggestions for other ways of accomplishing the same that meets my needs?
If this is going to be data for JavaScript's purposes, why even try to put it in the HTML at all? Here's a simple example of what I mean
<script type="text/javascript">
var nodeData = {
foo: {/* Data to associate with div#foo */}
, bar: {/* Data to associate with div#bar */}
};
</script>
<div id="foo">Foo!</div>
<div id="bar">Bar!</div>
It's simple and elegant since the principle of IDs being unique per document nicely matches with javascript's dictionaries requiring unique keys per entry.

Categories