Problematic rendering 'ready' callback on a route that is called more than once

[andrew.c....@gmail.com]

Hi There

Say we have a Batman app with a route called 'information', as defined below.

------------

class App.AppController extends Batman.Controller
routingKey: "app"

# One possible route
information: (arg) ->

# Set the value of a key, used by the view
@set 'somekey', 'somevalue'

# Wait for the DOM to be redered
@view = @render()
@view.on 'ready', =>

# Do something
$('#myelement').fadeIn(500)

-------------

This code above works well for accessing the 'information' route for the first time. However, if we then call the 'information' route for a second time, then the "@view.on 'ready'" callback doesn't seem to work correctly, i.e. the callback function is called before the page has been fully rendered.

I have confirmed this by replacing the "@view.on 'ready', =>" with "setTimeout => ... , 1000" call, and the page renders correctly.

Am I missing something?

Thanks
Andrew

[Jeff Berg]

Andrew,

It might be an issue with the view cache. Can you try:

@view = @render(cache: false)

@view.on 'ready', =>

   $('#myelement').fadeIn(500)

--
You received this message because you are subscribed to the Google Groups "batman.js" group.
To unsubscribe from this group and stop receiving emails from it, send an email to batmanjs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Jeff Berg
Owner/Developer
Ministry Centered Technologies
=================================
REVOLUTIONIZE the way you plan your SERVICES at planningcenteronline.com
REVOLUTIONIZE the way you plan your EVENTS at smartevents.com

[Andrew Symington]

Hi Jeff

Yes, that seems to sort the problem out, and I no longer require a timeout to make the page load correctly. Is this a workable solution for now?

Cheers

Andrew

[Kristian Plettenberg-Dussault]

We're considering removing the existing implementation of the view cache.  For now, you can disable it via: 

Batman.View::cache = false

Also, as a side note, unless you're using @view somewhere else, I'd recommend not assigning it as a property on the controller but rather just keeping it as a local reference in that function. By keeping it on the controller (which is never destroyed), you maintain a reference to that view and leak any DOM it references.  This is only really an "issue" when you have the view cache disabled because the view cache would keep the full DOM around anyway.

[Andrew Symington]

Hi Kristian

In the last week I've spent some time trying to understand / playing with the Batman render cache, and its actually really useful! I don't think that it's something that should be dropped. My use case was graphing large volumes of data. The plotting tool leaked a little bit of memory on destruction, which compounded with time. The render cache saved me a significant amount of memory and processing overhead.

If others are experiencing problems with the render cache then maybe it should be disabled by default. 

I'm using Batman 0.14.1 and found that the 'ready' event fired every time I switched to the view, irrespective of whether caching was enabled. I therefore had to maintain some boolean variable in my controller to check whether the graphs should be constructed. i.e.

someView: (args) ->

   @render false

   # ...Do some @get and @set operations

   view = @render 

      cache: true

   view.on 'ready', =>

      if not cached

         # ...Construct the graphs

         cached = true

      # Load graph data 

Perhaps there is an easier way?

Cheers

Andrew