[Erector-devel] Trouble with partials

[Alex Chaffee]

I know Erector's only got partial support for partials (har har) but it
seems something has changed, opening up a can of worms. I haven't coded in a
few months, and when I dusted off my pet webapp, I was getting a bunch of
weird stuff -- hanging, and eventually, huge stack traces. I think I tracked
it down to a few problems: (1) I'm using render(:partial,...) and the rails
extension to widget.rb didn't have a render_partial method, which led to a
NoMethodError being thrown. (2) Rails wraps the NoMethodError in a
TemplateError, which contains a pointer to the template, which is the widget
object. So when it called to_s on the template aka widget in order to
display its name &c for debugging purposes, it kicked off an Erector to_s,
which called render, which led to an infinite regress. (3) Ruby doesn't seem
to handle infinite regresses very well, and would occassionally swallow the
whole stack trace and abort the process without any console output.
I'll probably need help unraveling most of the following:

* to_s may not really be appropriate as a synonym for render_to_string (or
whatever) due to its important role in debugging and system uses.

* action_view_template_handler#render seems to have a bug where it picks the
wrong class for partials: given "moments/_form" it still instantiates
Moments::Edit as its template class. It's picking it up from
"view.first_render" rather than "template.path". I've hacked in a fix but
I'll need to add tests.

* Once we get this widget that we're using as a partial, we need to prime it
with all the "assigns" and possibly "locals" from the render :partial call.

Anyone have any time to pair on this? I'm feeling very rusty and even more
in need of pairing than usual.

 - A

---
Alex Chaffee - alex at stinky.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/erector-devel/attachments/20081110/306fc0e0/attachment.html>