I have an old-style CGI program which generates a large HTML table. Because the table contents are slow to calculate (even though it's not that big) I would like to print it one row at a time, and have the browser display rows as they are fetched.
If you search online you'll see that style="table-layout: fixed" is supposed to help some browsers do this, but on the other hand Firefox can render incrementally even without it. My test browser is Firefox 4.0b10 on Windows but I cannot get it to display incrementally using the simple example below:
<html>
<head>
<title>x</title>
</head>
<body>
<table width="100%" style="table-layout: fixed" rows="4" cols="4">
<col width="10%" />
<col width="20%" />
<col width="30%" />
<col width="40%" />
<tr><td width="10%">a</td><td width="20%">b</td><td width="30%">c</td><td width="40%">d</td></tr>
<!-- flush output, one second pause... -->
<tr><td width="10%">a</td><td width="20%">b</td><td width="30%">c</td><td width="40%">d</td></tr>
<!-- flush output, one second pause... -->
<tr><td width="10%">a</td><td width="20%">b</td><td width="30%">c</td><td width="40%">d</td></tr>
<!-- flush output, one second pause... -->
<tr><td width="10%">a</td><td width="20%">b</td><td width="30%">c</td><td width="40%">d</td></tr>
<!-- flush output, one second pause... -->
</table>
</body>
</html>
Instead the page is blank until the end of the download, when the whole table appears. I've tried various ways to tell the browser the table dimensions in advance so it should have no problem displaying it as it arrives, but they don't help. (Removing the hints doesn't help either.)
If I modify my CGI script to close and restart the table between each row, with an extra blank paragraph in between, then the page does render incrementally in the browser. This shows that the data is getting to the browser incrementally - just Firefox is choosing not to render it.
Ironically, much more complex scripts producing larger tables seem to do what I want, showing one row at a time as it downloads, but whenever I try to reduce the output to a minimal test case it doesn't work. This leads me to suspect there is some complexity heuristic used by Firefox's rendering engine.
What's the magic dust I need to tell the browser to always display the table as downloaded so far?
For what it is worth.
The Firefox I use Firefox 3.6.16 does not display until the page is downloaded, regardless of what is being downloaded.
You could look for settings in about:config, but I have not seen any solution to this,
there are addins to help with displaying placeholders. but they don't always work either.
Just found this
Read it OR try
about:config - in browse bar
select new
create integer
nglayout.initialpaint.delay
set value to 0
cheers
First of all, I'd say it's seldom good user interface design to load huge amounts of data at once. In most cases, it's better to offer some sort of search or at least paging functionality. There may be exceptions, but people simply cannot process very large quantities of information, and apps serving far more data than people have any use for aren't just wasting cycles, they are badly designed. Imagine if Google displayed the first 10,000 hits by default, or even 1,000. Most users wouldn't even look beyond the first 5 or so, and the amount of wasted bandwidth...
That said, it may of course not be your fault if the page is badly designed. Or it may be, but you'll need a quick fix before coming back to redesign the solution later. :)
One way to make this happen would be to render the table client-side instead of on the server. If there's nothing else heavy on the page, the user would be served quickly with the other content, and the area where the table will appear could contain an animated GIF or similar to indicate the software is "working". You could use an AJAX-call to fetch the data for the table, and modify the DOM in Javascript. You could then create for instance 100 rows at a time and use window.setTimeout to allow the browser to render the updated DOM before continuing.
A good article explaining the event dispatch model may be of help if you choose to go down this path:
http://dev.opera.com/articles/view/timing-and-synchronization-in-javascript/
OK, so how about dropping client-side rendering but fetching and replacing server-side rendered HTML within a placeholder (and thus the table) multiple times? The server-side would have to use a background thread and supply a handle (e.g. a GUID) in it's initial response that an AJAX call could then use to ask for the table. The server could reply with a few rows plus an indication that it's not done, prompting the client to repeat this until finished.
I suppose it would be a little messy, but at least it would allow you to use the same page for your report. A query string parameter could tell the page whether to render completely or emit script to call back to get the data.
Related
I am trying to automate a workflow for automatically creating HTML newsletters based on information stored in a spreadsheet.
Currently, I am using a newsletter drag and drop tool, in which several pre-programmed blocks are available (e.g. full column block, 2 column block etc). When creating a newsletter, I drag and drop a block and fill in my content (e.g. uploading an image, inserting a url). This is all well and good, however, since I have to create the same newsletter in 10 different languages, this process is quiet time consuming and prone to human error. While all newsletters are the same in terms of layout, the images and urls differ.
To solve this issue, I would like to get rid of the drag and drop process, and instead automate the workflow in some other way.
One idea that I have already tried, but that doesn't seem like the perfect option to me, is to dynamically create the needed HTMLs in Excel. Basically, the idea is to take the existing block template structure, and put it into Excel with some formulas.
I could then copy and paste the links to the images (in a simple format, such as EN1.jpg, ES1.jpg, etc.), as well as to urls (url.com, url.es).
This is some example block:
<img alt="" align="center" width="700" style="max-width:700px;" class="resetWidth" border="0" src="IMAGE" />
My final expected result is something like this:
I define the layout in a very quick manner (e.g. writing fullcolumn, half column, fullcolumn). The corresponding code is taken from the template. I then provide the attributes (image url, link url) in the form of a list or so. The end result should then be 10 html files that I simply have to upload to the newsletter software.
I would appreciate it very much if anyone had any ideas on this.
Another option for translating the page is to do something like this https://www.w3schools.com/howto/howto_google_translate.asp
it adds a selection for languages to translate into.
As for automating the images, you could set up folders for each langauge and reuse the name of images based on where you want them so they would be placed in the correct location.
All you'll have to do it replace the images with the same file names and swap the default language on the Google Translator.
So something like this that the html will stay the same with regards to the image names
For the link variables you may be able to write some JS or another language to take advantage of the
<html lang="">
and based on which lang is set, insert a set of links to the file.
In my Typo3 extension I us a <f:for to iterate trough a couple of items. Exactly 184 Items.
I generate a slider out of this.
Problem is that this iteration is extremly slow. Is there a way to fast it up. Backend is fast less than a sec. Only the frontend rendering needs to long time.
My full frontend Code looks like this:
<f:if condition="{videos -> f:count()} > 4">
<f:then>
<f:for each="{videos}" as="video" iteration="i">
<f:if condition="{i.isFirst}">
<f:then>
<div class="item active">
</f:then>
<f:else>
<div class="item">
</f:else>
</f:if>
<div class="col-lg-3 thumbnailParent">
<f:link.action controller="FrontendVideo" action="show" arguments="{video : video}">
<f:render partial="Video/ShowThumbnail" arguments="{video : video, userAuthorization : userAuthorization}"/>
</f:link.action>
</div>
<!-- adding slider-class to one of all slides. condition: slide must have more than 4 videos for slide-effect -->
<f:if condition="{i.isLast}">
<f:then>
<script type="text/javascript">
addClassForSliding('{myCarouselID}');
function addClassForSliding(myCarouselID) {
$("#myCarousel"+myCarouselID).addClass("isCarousel");
if(!$("div.videoSlide").find("div").hasClass("thisIsTheOnlySliderWhichSlides")){
$("#myCarousel"+myCarouselID).addClass("thisIsTheOnlySliderWhichSlides");
}
}
</script>
</f:then>
<f:else></f:else>
</f:if>
</div>
</f:for>
</f:then>
<f:else>
<f:for each="{videos}" as="video" iteration="i">
<div class="item active">
<div class="col-lg-3">
<f:link.action controller="FrontendVideo" action="show" arguments="{video : video}">
<f:render partial="Video/ShowThumbnail" arguments="{video : video, userAuthorization : userAuthorization}"/>
</f:link.action>
</div>
</div>
</f:for>
</f:else>
</f:if>
Make sure your caches are enabled - if they are not, don't judge the performance based on uncached renderings.
Try to avoid the many conditions you use. And definitely don't leave the empty nodes like <f:else></f:else>.
Move the stuff you do in the last iteration, outside of the loop (thus saving another condition and a lot of node construction).
Avoid the iteration variable whenever possible. It adds additional processing and variable assignment to each iteration.
I assume you use JS to activate the component. So use JS to set the active CSS class, thus avoiding 1) opening and closing tags incorrectly like you do, and 2) avoid another condition that only is true a single time, like the other one.
Check your partial that you render. It may not be compilable. And every time you render it, the partial must be resolved. Note: in this type of use cases, a section almost always performs better than a partial. One tool I wrote which you can use, which also pre-compiles your templates and can fail if any template is not compatible: https://github.com/NamelessCoder/typo3-cms-fluid-precompiler
Generally speaking: don't output <script> in Fluid unless you have an extremely good reason. Whenever possible, load scripts externally and store whichever values the script needs, in for example data- properties. Faster parsing, faster loop.
Use actual profiling tools to precisely locate the bottleneck. Your code uses ViewHelpers and is also sensitive to configuration, e.g. the more setup you have for paths etc. the more processing needs to be done in f:render calls. Do not profile in development context!
Do not profile on a Docker setup - unless you're running Linux. And even then, take results with some reservations: file system performance will never be equal.
Avoiding iteration and your conditions, and moving the last block outside the loop, should remove a good 80% of the cost (not counting what happens in your partial you render - it could be absolutely horrible in performance and we'd never know since you didn't paste that one).
Finally, when selecting whether to render a partial or a section there are a couple of things to consider. Most of these completely depend on your use case (as in: how do you need your templates to be structured - does it make more sense with a partial you can overlay than a section you cannot?) but it is possible to say something general about performance:
When you render a section, which exists in the same template, the rendering takes place with a single function call to switch to that section with a new set of template variables.
But when you render a partial, the template file for this partial first has to be resolved before rendering can take place.
The resolved template is not possible to compile since the same compiled template must be possible to render in multiple different contexts.
Thus, resolving of a partial template may only be cached once per context, which means that if this same template is rendered in multiple contexts multiple times on a page, performance may suffer a lot compared to using a section (which gets compiled to a plain function call).
The more template paths you have, the tougher this is on file resolving.
You always need to choose the right tool for the task - that's one of the things our job is as developers - so these points are pretty generic. Some uses cases simply have no difference in performance between sections and partials, some don't suffer noticeably from using iteration; it all depends on your setup requirements and the data you are rendering. Profiling your templates certainly helps finding the right solution so I highly recommend doing that.
I am writing a program for managing an inventory. It serves up html based on records from a postresql database, or writes to the database using html forms.
Different functions (adding records, searching, etc.) are accessible using <a></a> tags or form submits, which in turn call functions using http.HandleFunc(), functions then generate queries, parse results and render these to html templates.
The search function renders query results to an html table. To keep the search results page ideally usable and uncluttered I intent to provide only the most relevant information there. However, since there are many more details stored in the database, I need a way to access that information too. In order to do that I wanted to have each table row clickable, displaying the details of the selected record in a status area at the bottom or side of the page for instance.
I could try to follow the pattern that works for running the other functions, that is use <a></a> tags and http.HandleFunc() to render new content but this isn't exactly what I want for a couple of reasons.
First: There should be no need to navigate away from the search result page to view the additional details; there are not so many details that a single record's full data should not be able to be rendered on the same page as the search results.
Second: I want the whole row clickable, not merely the text within a table cell, which is what the <a></a> tags get me.
Using the id returned from the database in an attribute, as in <div id="search-result-row-id-{{.ID}}"></div> I am able to work with individual records but I have yet to find a way to then capture a click in Go.
Before I run off and write this in javascript, does anyone know of a way to do this strictly in Go? I am not particularly adverse to using the tried-and-true js methods but I am curious to see if it could be done without it.
does anyone know of a way to do this strictly in Go?
As others have indicated in the comments, no, Go cannot capture the event in the browser.
For that you will need to use some JavaScript to send to the server (where Go runs) the web request for more information.
You could also push all the required information to the browser when you first serve the page and hide/show it based on CSS/JavaScript event but again, that's just regular web development and nothing to do with Go.
I've used one static cfm page and it's has a single select query for showing a above 3000 records(without pagination). When i am try to view that page in FF its takes the 15 sec for shows the content. If any way(without pagination) to reduce the browser loading time?
Create a page that uses that uses AngularJS to show the table. Then populate the table via an AJAX call to get JSON.
Use fixed table layout so that the browser does not have to re-flow the content as it loads.
Don't load the data into a table at all. Do the layout with div's and span's
Optimize the SELECT query
Only select columns you need.
Avoid wildcards (*) in the SELECT clause
Don't join unnecessary tables.
You can also consider loading content dynamically via ajax.
Without seeing your code (or example code), we can't provide anything specifically tailored to your implementation of the query.
You could potentially
<cfflush>
the content, so it will start sending the response to the browser straight away, rather than building the entire page, then pushing the response back
Some other solutions are better options, especially for long term scalability and maintenance. However, if you're looking for a quick solution for now you could try breaking it up into a series of HTML tables. Every 500 records or so add this:
</table>
<cfflush>
<table...
This will insure that html rendered so far is sent to the browser (via the cfflush) while ColdFusion continues to work on the rest. Meanwhile, by closing out the table before doing so you're allowing the browser to properly render that block of the content in full without risking it waiting for the remainder.
This is a patch, and something you should only do until you can put a more involved solution (such as JQGrid) in place.
At my website I have a single < sign that I want deleted that shows up just before the table and just after the YouTube video.
The thing is, that character does not show up in the index.html file. I have checked it in three editors just to be sure. I have no idea where it is coming from.
If you delete the table in Firefox it disappears, but if you delete the YouTube video it does not. So it has to be linked to the table somehow.
When I look it up as view source selection in Firefox, a small < sign shows up to the left side of the table code. But if you look in the index.html file, there's nothing there.
I'm a quasi-intelligent person who can code a site this good but I cannot for the love of all that is electrical squash this bug. Help would be appreciated and it know it's stupid simple to fix. It has to be. I just don't know what I'm missing at this point.
On line 250, you have:
<<td><img src="images/sample.jpg"></td>
Remove the extra < at the start.
This is part of "Album 2", by the way. Anything outside of proper markup in <table>s tends to get bumped ahead of it.
It's inside the table, here:
<tr>
<td>Album Two</td>
<td>Inter5tellar</td>
<td>A digital song produced in fruity loops for your listening pleasure.</td>
<<td><img src="images/sample.jpg"></td>
<td><img src = "images/button.jpg"></a></td>
<td>$0.99</td>
</tr>
However, since it's not actually inside a td (or th) tag, browsers cannot render it normally. Different browsers might do different things, but it seems that Firefox, at least, in effect "pushes" it out of the table and puts it before it instead.
By the way, you might want to run your page through an HTML validator: it has a number of other errors, including a div inside the head section, duplicate closing tags and some unescaped ampersands in URLs.