Confused about inconsistent widget updates

[John Lane]

Hi Nick,

I'm having a problem with widget updates, I wonder if you can help?

I have a widget that drives a modal pop-up made with bootstrap. The widget has an event that does something like this:

message :info, 'some text'
render :state => :new

"message" is a method that adds a nested "message" widget within a "messages" widget. The "message" widget displays a flash-like message. The "messages" widget tree is on the page in two places - the main page and in the modal pop-up. The messages appear in both places.

It works as expected with the code as above in the event. However, if I don't do the "render", the new message only appears on the main page but not in the modal.

I don't understand why I need the render. I only added it to see if it would make the message appear in the modal (which it did), but I didn't need to do anything extra for it to appear on the page. So, why the difference?

Furthermore, if I do anything else after the render then the message doesn't appear in the modal even with the render in place. I mean anything, even a simple variable assignment "x=nil' breaks it.

I do need to write something after the render call, so I'd like to understand what's going on here.

Cheers,
John

[Nick Sutterer]

Hi John,

#render is explicit, it simply returns what it rendered, so you need to do run it last or store the result in a variable and then return it.

def show

  # do something

  html = render

  # do more stuff

  html

end

This is different to Rails per design.

Furthermore, it often helps to track what's sent back to the page from the render_event_response AJAX request - people use the Chrome Developer extension or Firebug for that. Usually, after seeing the output of the widgets, you understand why things didn't work before.

Does that help?

Nick

--
Sie erhalten diese Nachricht, weil Sie in Google Groups E-Mails von der Gruppe "Cells and Apotomo" abonniert haben.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an cells-and-apot...@googlegroups.com.
Weitere Optionen finden Sie unter https://groups.google.com/d/optout.

[Nick Sutterer]

Oh, and calling #message isn't enough as this just adds a new widget but doesn't render anything. Apotomo is not that clever, everytime you change the widget tree you have to sync that manually to the page (e.g. by replacing the top widget).

[John Lane]

On Sunday, 13 July 2014 23:46:09 UTC+1, Nick Sutterer wrote:

Oh, and calling #message isn't enough as this just adds a new widget but doesn't render anything. Apotomo is not that clever, everytime you change the widget tree you have to sync that manually to the page (e.g. by replacing the top widget).

Yeah, I think I do that already... #message triggers an event on the messages widget. That adds a child widget containing the message and then calls "replace :state => :display". It seems to work ok :)

[John Lane]

On Sunday, 13 July 2014 23:42:18 UTC+1, Nick Sutterer wrote:

Hi John,

#render is explicit, it simply returns what it rendered, so you need to do run it last or store the result in a variable and then return it.

Thanks for that, I remember it now, duh! I knew it, I've done it before !

 

Furthermore, it often helps to track what's sent back to the page from the render_event_response AJAX request - people use the Chrome Developer extension or Firebug for that. Usually, after seeing the output of the widgets, you understand why things didn't work before.

Does that help?

Yes, I have it working now. It just slipped my mind about how render works. Those dev tools are very handy, I use them frequently.

[Nick Sutterer]

So what exactly was the problem? The missing return + render? :)

--

[John Lane]

On Monday, 14 July 2014 12:03:37 UTC+1, Nick Sutterer wrote:

So what exactly was the problem? The missing return + render? :)

The message bit was nothing to do with my problem, it was the need to render properly that was the issue and I had broken that by doing things on multiple lines and fogetting that the render returns an explicit block of text that my event needed to return. So I just concatenated two lines like this

    render(:state => :waiting) + redirect_to(session_new_path(params[:session]))

(actually I still don't understand why the widgets in the page body did update (even though the render was broken) but the ones inside didn't. I'm not going to worry about it too much as I have to get on...)

Oh, you'll see there that I used "redirect_to". That is something that I needed and I see you already have a pull request pending for it. Hopefully that'll find its way into the code at some point...

[Nick Sutterer]

Yeah initially I wasn't a big fan of adopting this redirect_to Rails behaviour into a widget framework (which shouldn't know about HTTP) but we can merge that into a JS "helper" class that gives you common operations. Yes, I'm becoming more and more pragmatic :)

Nick

--