I want to reuse the html of a complex UI that I created using underscore template. The issue is that the template constructor takes the data and generates the plain html with data.
Now, I want to cache the generated html for future to use it as a template and would change the data of specific html nodes by selecting each of them using jQuery selectors.
My goal is to reduce the memory consumption by keep re-using the JS and DOM objects once created.
Has anybody done something like this before?
Okay. I myself have found a way. I am caching the DOM fragment (without removing from body) prepared by underscore template. When next time same fragment is needed, I re-use the cached fragment by updating the values using jQuery selectors.
It is still WIP but looks promising.
Related
I've encountered an issue with ember's (app is on 2.6.0, but seems to happen in latest as well) rendering process and its compatibility with the MathJax.js library. I have an ember twiddle (linked below) that isolates the problem, but essentially it seems like MathJax's rendering of inline equations that occur in the middle of a single text node breaks ember's re-rendering, in that the single text node becomes multiple text nodes after MathJax transforms the inline equation text into its Math elements, and the 2nd text node becomes orphaned, and remains in the DOM across re-renders.
https://ember-twiddle.com/cadfb80d7c90df98353cc3d9900f2b73/1ab7f66c3c6ca4aad15bf443bbe02fbb1f79a0d4?openFiles=controllers.application.js%2C
It may just be that my integration of mathjax with ember is just not correct, so I'd love some pointers if thats the case.
I was able to fix this with a somewhat hacky workaround:
https://ember-twiddle.com/cadfb80d7c90df98353cc3d9900f2b73
The issue (as confirmed on slack by some ember core team members) is with how MathJax modifies the DOM, in that ember is not able to keep track of the extra nodes it creates, and as a result can not properly clean up after it on re-renders.
To solve this, the component which contains the mathjax content manually sets its element's innerHTML to whatever the content attribute is set to when didRender() is fired, effectively wiping out all the DOM created/modified by MathJax. MathJax's rendering process is then invoked to render any formulas in the newly rendered content.
Note that if your content does not contain any HTML, it is recommended to set element.innerText instead of element.innerHTML.
Quite often we deal with lists of things on our site. These initially get loaded with the rest of the page from the server. However, any updates received we would like to update these lists using Ember.
All of the examples I have seen so far with Ember views deal with controlling content on a page that has always been created purely by Ember. What options are there for dealing with DOM elements that already exist on the page with Ember views?
There has been some discussion around this idea here: https://github.com/emberjs/ember.js/issues/563
In the current situation two approaches come to my mind:
Replace the static rendered list with an Ember.CollectionView as soon as all list items are available to ember as data objects (e.g through ember-data)
Use plain old jQuery to append the latest updates at the beginning / end of the list
I guess it depends on how complex your list items and the updating logic is. If updates need reordering of items and your list needs complex interaction, the first approach using ember might be better suited, although there could be a "flickering" of content while the lists are replaced. The second approach is much simpler but also limited. I would only use jQuery for appending / prepending content. Still, if the lists are simple it would be overkill to even use ember in this case.
I have a view called "contests_slider" with a block display. I'm hiding all fields and using a "Customfield: PHP code" field instead which calls a function called display_front_contests(). In that function, querying the database and building some html and returning it. I'm displaying the output in a block. The problem is Drupal is adding alot of extra divs that I don't want. I went to "Theme: Information" and copied the theme "views-view-field.tpl.php" to "views-view-field--contests-slider--block-1--phpcode.tpl.php" and put just: in it and it's still outputting all the extra html.
Any ideas? am I using the wrong template?
If you are only using views to create a block, but otherwise query the datebase, create the markup etc, you should consider making a block in a custom module. All the work is in the code you have already written. That way you wont have to think about the many templates that views uses, but instead you'll just use the block.tpl.php.
Take a look at hook_block for info on how to do it.
I have a django view, and this view returns a table which is populated asynchronously with an ajax call.
From the design point of view, which one should I follow:
the django view, called via ajax, returns the content of the table as a json response, containing html markups for each cell. The javascript callback handler takes the contents and slaps them untouched into the table cells.
the django view, called via ajax, returns pure data about what should go into the table, again as a json response. The async javascript callback takes the data, formats them with proper markup, and puts it into the table.
In other words, who should have the responsibility for markup formatting of the cell contents? the view or the javascript ?
I would be tempted to say the first, since the view already returns marked up content. If it returns a json containing marked-up content, there's not much difference.
I would like to hear your point of view.
If you're populating the whole table, you can put your table in its own template and return the table's html via ajax/json.
You'll need to edit the original template to include the table template:
{% include "myapp/_table.html" %}
And in the view, return the rendered template as a json variable, which your javascript will substitute in:
return { 'table': render_to_string("myapp/_table.html", context) }
This approach is good where you always want to update the entire table, and the rendering of the table doesn't require the full context. I'm not sure what the performance is like, but it is a clean way of updating part of the page, because you only define your table once.
It depends (as so often).
If the data is requested only here and now, it would be easier and less error prone to just let it render on server-side with the same set of templates that already rendered the standard view.
If you could think of use cases however, where the data would be needed in other places (like auto-complete fields), it would be better to let JavaScript do the job and create a clean, reusable JSON export.
These options add to all the other answers, and finally it's up to you to decide.
In a MVP system such as Django, the View decides what data should be shown, and the Presenter decides how it should be shown. Therefore the JavaScript should do the bulk of the formatting unless it proves intractably difficult to do so.
It is a good to practice Unabstrusive javascript, also called by some people as Hijax
So, you first have a standard page, that presents the table along with the rest of the page, with table in a particular django-template block.
Once you have this, you can include the extends part of the django template within an "if not ajax", so you only get the required table part in the ajax response which you can load in the client to the required div.
It is un-necessary and redundant to maintain the markup twice once at the server and once at the client, in javascript.
hence, I'd prefer the first option, of server redering, and client only loading the rendered html.
I've come across this several times before, and I generally opt for the latter, where the view returns pure JSON.
However, the approach you choose should definitely depend on several factors, one of which is targeted devices (and their CPU/network constraints). Pure JSON will generally result in smaller payloads and so may be optimal for mobile devices.
It may also make sense to expose both HTML and JSON versions of your content. This is especially helpful if you're looking to create a very lightweight API at some point for your site.
Finally, you can use a library such as John Resig's micro-templating or Closure Templates to simplify client-side HTML generation.
I would go with first choice, sine it presents more pros for user: page loads instantly (no wait for async call), no JS required (e.g. for mobile device)
I want to include things like twitter status, or delicious tags, in my django templates.
These things are dynamic, yet regular. How would this be done?
There are a number of ways to handle this, so you can choose a method that best matches your own personal style or requirements:
Template context variable: as answered by Alex you can put your content into a context variable that is included in the context of every template created by every view. Django even provides a mechanism for doing this automatically, called a context processor. Pros: very straightforward. Cons: won't dynamically refresh new content on client browsers.
AJAX dynamic loading: as mentioned by Alex and Dave you can dynamically load your content using AJAX methods. As an example using jQuery, you would put a placeholder in your template something like <div id="twitterfeed"></div> and then in a javascript block in your template put $("#twitterfeed").load("{% url twitterfeed %}"); where twitterfeed is a url so named in your urls.py. Pros: will dynamically update browsers. Cons: can be tricky if you don't know Javascript.
Inclusion tag: Django provides a type of template tag called an inclusion tag, which is basically a custom template tag that can render dynamic content. In a way it's similar to a context variable, except your code to generate the content will only be called when you use the custom template tag in your template instead of being called for every view. Another benefit is the content is generated from a template of its own. You could do this with a normal context variable of course, but it's not as clean (IMHO) as using an inclusion tag. Pros: very straightforward, clean. Cons: won't dynamically refresh new content on client browsers.
The simplest approach is to use {{ mycontent }} in your template (where you want the dynamically generated content to appear) and put the correspondence between mycontent and its value in the context you use to render the template -- i.e., the most fundamental part of django's templating.
If what you mean is that you want Ajax support whereby Javascript on the page continuously refreshes such content according to what the server wants it to be at any given time, I suggest looking into dojango, the Dojo/Django integration project -- it's not yet as fully mature as each of Dojo and Django are on their own (not version 0.4 yet), but it is already usable and useful.
A common technique is to leave a placeholder div in the generated content, then fill the div in on the client side via an AJAX call from Javascript that you include in the page.
That gives you the benefit of having a cacheable (fast loading) primary page, with separate dynamic bits. Depending on how live you want the dynamic bits, you can can even cache them for shorter durations.