From apotonick at gmail.com Sun Jan 3 05:18:51 2010 From: apotonick at gmail.com (Nick Sutterer) Date: Sun, 3 Jan 2010 11:18:51 +0100 Subject: [Cells-talk] content_for renders nothing In-Reply-To: <60E6B9F0-C14C-412F-AB8D-6BDDF1913470@gmail.com> References: <1248211724.24919.27.camel@wyjec> <1248247770.11331.5.camel@wyjec> <1248282045.11331.16.camel@wyjec> <1260438405.4521.26.camel@wyjec.localdomain> <60E6B9F0-C14C-412F-AB8D-6BDDF1913470@gmail.com> Message-ID: hey emmanuel, hi list! after introducing #global_content_for i really see the need for some prepare hook when having a cache hit (as you already proposed, emmanuel). however, after reflecting the problem more deeply, i see a severe problem with nested cells. assume the following setup: render_cell :parent, :show_family | ---> render_cell :child, :show_avatar if :show_family is cached it will execute its #prepare_for method in the following render cycles. anyway, we completely loose information about nested states! what if :show_avatar also would need to prepare something? what if it had to add some javascript block? i'm really not sure how to handle that (generically) in cells, while i see something that could work with Apotomo. in Apotomo we have two advantages: we know if there are children at any time and since they're persistent they could also store caching informations and propagate that up to the highest cached widget instance. what do you guys think? oh- and a happy new year ;-) cheers, nick On Thu, Dec 10, 2009 at 5:46 PM, Emmanuel Gomez wrote: > I'm currently working on a solution to a subset of this problem: exporting js requirements from a cell on a per-state basis to the parent controller. Required js will be declared per-state in the cell with a class macro (like Cell::Base.cache). > > My solution has a few assumptions about the parent controller and its view, but they basically boil down to a helper module JavascriptHelper#javascript, which accepts a string and stores it in an array, and a call in the layout that invokes javascript_include_tag with the list of required files. > > The final piece of the puzzle is a method Cell::Base#prepare_for(state) and a modification of Cell::ActionView#render_cell that calls #prepare_for before rendering. This allows the cell instance to call the #javascript helper method on the parent controller's template and register the required js files. > > There are a lot of moving pieces; in general it's more complicated than I'd like. But, it does work with cached states. I've found content_for is problematic with caching in general. Well, any sort of side effects aside from the view complicate caching, but that's another discussion. > > I have some of the described code in my fork of cells on github (http://github.com/emmanuel/cells), and most of the rest is at: http://pastie.textmate.org/737474. If anyone is interested in this, I'll add some tests for these modifications and push them to github in the next couple of days. > > Emmanuel > > > On Dec 10, 2009, at 4:40 AM, Nick Sutterer wrote: > >> hey my friend! >> >>> I like the idea of with_global_scope with nested blocks (maybe because >>> it's mine) but it seems to be tricky do make it work... or even >>> impossible. Image situation like that: >>> <% with_global_scope do |view| %> >>> ?<% @foo = capture do %> >>> ? ? ? ?Some text >>> ?<% end %> >>> <% end %> >>> >>> In that case @foo should be set in parent view. The more I think about >>> things like that the more I believe it should be simply unsupported by >>> cells. >>> In my opinion with_global_scope shouldn't be introduced into cells as it >>> may work only with content_for without a block and nothing else. Instead >>> maybe just override content_for so it may be parameterized to use cell >>> view or parent view scope. >>> >> i like your idea of #with_global_scope, too, as i would like to >> provide as much "rails" functionality in cells as possible. >> however, there are two things that prevent the introduction of >> #with_global_scope. >> >> 1. it simply breaks encapsulation. cells are meant to be independent. >> with the usage #capture and friends in cell views they access some >> globals which they shouldn't. >> >> 2. the more i dove in the rails view code, the more i got scared of >> it. the problem begins with rails distinguishing between "views" and >> "partials", and it ends with code as found in renderable.rb >> >> view.with_template self do >> ? ? ? ?view.send(:_evaluate_assigns_and_ivars) >> ? ? ? ?view.send(:_set_controller_content_type, mime_type) if >> respond_to?(:mime_type) >> ? ? ? ?view.send(method_name(local_assigns), local_assigns) do |*names| >> >> i mean, i simply don't WANT to know what's going on there! >> >> >> we should better spend our time thinking about a cell-ish approach for >> the problem of having global blocks in independent cells. many people >> want to insert JavaScript code so we could at least provide something >> for that. anyway, this should work by propagating the global block to >> the parent cell recursively where the root cell will insert the markup >> into the layout or whereever. >> >> any thougts? >> prost! >> >> nick >> >> >> >> >>> Or maybe you've got an idea of wider use with_global_scope, I mean not >>> limited to content_for only? >>> >>> zdr?wko >>> -- >>> Micha? ?omnicki >>> >>> >> _______________________________________________ >> Cells-talk mailing list >> Cells-talk at rubyforge.org >> http://rubyforge.org/mailman/listinfo/cells-talk > > _______________________________________________ > Cells-talk mailing list > Cells-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/cells-talk > From apotonick at gmail.com Wed Jan 13 15:26:45 2010 From: apotonick at gmail.com (Nick Sutterer) Date: Wed, 13 Jan 2010 21:26:45 +0100 Subject: [Cells-talk] finally- cells gemified! Message-ID: hey all, thanks to grimen's work we now have a cells gem! http://gemcutter.org/gems/cells cool, isn't it? cheers! nick From apotonick at gmail.com Thu Jan 14 08:48:45 2010 From: apotonick at gmail.com (Nick Sutterer) Date: Thu, 14 Jan 2010 14:48:45 +0100 Subject: [Cells-talk] review of our RuPy 2009 talk on Cells and Apotomo Message-ID: dear friends, here's a new blog post i wrote, discussing my trip to poland and the talk with Micha? ?omnicki and me at the RuPy 2009. http://apotomo.de/2010/01/enjoy-rupy-and-do-enjoy-the-polish-beer/ hope to hear from you guys! cheers, nick