I am trying to use the Capturing helper <http://nanoc.stoneship.org/docs/api/3.3/Nanoc/Helpers/Capturing.html>to capture summary information from a set of children pages to be displayed on the parent's page. If I wipe out the contents of the output directory and compile everything: it works as expected. If I then make a change to the parent page and then either compile with nanoc or with the autocompiler: I do not get the summary information but I still get the title attribute. If I wipe out the tmp directory and compile: it works as expected I have tried creating a ChildrenDependencyFilter which explicitly depends on the children but it does not seem to affect the output. How do I either force the recompilation of the children pages or ensure that the content_for_summary attribute is preserved?
Child page: <% content_for :summary do %> Summary text here <% end %> <%= content_for(@item, :summary) %>
Parent page: <% for @child in @item.children %> http:<%= @child.identifier %>[<%= @child[:title] %>]:: <%= content_for(@child,:summary) %>
<% end %>
Attempted filter to force dependency: class ChildrenDependencyFilter < Nanoc::Filter identifier :childrendependencyfilter type :text def run(content, params={}) print "#{item.children.length}\n" if @item.children.length > 0 depend_on(@item.children) end content end end
This looks like a bug in nanoc (or at least the capturing helper) to me. Dependency handling should automatically happen behind the scenes everywhere, so there should be no need to declare them manually. It is a bit late here at the moment, but I will take a proper look at the problem tomorrow.
> I am trying to use the Capturing helper to capture summary information from a set of children pages to be displayed on the parent's page.
> If I wipe out the contents of the output directory and compile everything: it works as expected.
> If I then make a change to the parent page and then either compile with nanoc or with the autocompiler: I do not get the summary information but I still get the title attribute.
> If I wipe out the tmp directory and compile: it works as expected
> I have tried creating a ChildrenDependencyFilter which explicitly depends on the children but it does not seem to affect the output. How do I either force the recompilation of the children pages or ensure that the content_for_summary attribute is preserved?
> Child page:
> <% content_for :summary do %>
> Summary text here
> <% end %>
> <%= content_for(@item, :summary) %>
> Parent page:
> <% for @child in @item.children %>
> http:<%= @child.identifier %>[<%= @child[:title] %>]:: <%= content_for(@child,:summary) %>
> <% end %>
> Attempted filter to force dependency:
> class ChildrenDependencyFilter < Nanoc::Filter
> identifier :childrendependencyfilter
> type :text
> def run(content, params={})
> print "#{item.children.length}\n"
> if @item.children.length > 0 > depend_on(@item.children)
> end
> content
> end
> end
> -- > You received this message because you are subscribed to the nanoc discusssion group.
> To post to this group, send email to nanoc@googlegroups.com
> To unsubscribe from this group, send email to
> nanoc+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nanoc?hl=en
Since it looks like a bug I created a small test project that shows the problem. The runtest.sh script will reproduce the files in the testresults directory.
> Since it looks like a bug I created a small test project that shows the problem. The runtest.sh script will reproduce the files in the testresults directory.
> Cheers,
> W
> -- > You received this message because you are subscribed to the nanoc discusssion group.
> To post to this group, send email to nanoc@googlegroups.com
> To unsubscribe from this group, send email to
> nanoc+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nanoc?hl=en > <capturetest.tgz>
I am seeing the same behavior on both the test project and my full project. I verified that the updated file is being run. Is it possible that something else changed since 3.3.6 that could be affecting this? I see how the recent bugfix could cause this problem. Since nanoc debug shows the proper dependencies it looks like if a file uses content_for then its dependencies need to regenerate the CaptureStore. I am new to ruby and gems but comfortable with other languages so I will grab the master branch and see if it corrects the situation. Thanks again for the help and a great package.
> Can you double-check whether this fix works for you? With a patched nanoc, > your test case gives the right results.
> Cheers,
> Denis
> On 06 May 2012, at 05:47, Warren Knight wrote:
> > Thanks,
> > Since it looks like a bug I created a small test project that shows the > problem. The runtest.sh script will reproduce the files in the testresults > directory.
> > Cheers, > > W
> > -- > > You received this message because you are subscribed to the nanoc > discusssion group.
> > To post to this group, send email to nanoc@googlegroups.com > > To unsubscribe from this group, send email to > > nanoc+unsubscribe@googlegroups.com > > For more options, visit this group at > > http://groups.google.com/group/nanoc?hl=en > > <capturetest.tgz>
I verified the problem still occurs with the head of the 3.3.X branch and I have spent a little time familiarizing myself with the code. I don't see how you are going to meet the conflicting requirements of issue 111<https://github.com/ddfreyne/nanoc/issues/111>and having content_for remember information of other pages from previous runs. Off the top of my head the only thing I can think of is a reverse dependency graph for content_for that forces the children (source pages) to be recompiled when the parent (summary page) needs to be rebuilt. I assume you will still need a check for the issue 111 case where the source and summary are on the same page.
For now I will make my first attempt at creating a command to be to reimplement the -force option (I read about in another post) and regenerate the full site each time (since it is small). I will keep an eye out for any fixes you add.
Now that I dive deeper into the issue, it indeed appears that there is
more to it than I just thought. The problem occurs when captured
content from a cached item is requested: in this case, the captures
store will be empty and it will appear that nothing is captured at
all. A fix for this would be to ask the compiler to forcefully
recompile the item, ignoring any cached data.
There is no immediate easy way around this issue. The capturing helper
has always been a tricky one to get right, because it really operates
outside the normal nanoc workflow. Because of this, I recommend not
using the capturing helper. I will nonetheless still fix this issue,
but it is not unlikely that the capturing helper will be deprecated at
some point.
On Mon, May 7, 2012 at 6:44 AM, Warren Knight <w...@umbisag.org> wrote:
> Hi Denis,
> I verified the problem still occurs with the head of the 3.3.X branch and I
> have spent a little time familiarizing myself with the code. I don't see
> how you are going to meet the conflicting requirements of issue 111 and
> having content_for remember information of other pages from previous runs.
> Off the top of my head the only thing I can think of is a reverse dependency
> graph for content_for that forces the children (source pages) to be
> recompiled when the parent (summary page) needs to be rebuilt. I assume you
> will still need a check for the issue 111 case where the source and summary
> are on the same page.
> For now I will make my first attempt at creating a command to be to
> reimplement the -force option (I read about in another post) and regenerate
> the full site each time (since it is small). I will keep an eye out for any
> fixes you add.
> Updated capturetest attached
> Cheers,
> W
> --
> You received this message because you are subscribed to the nanoc
> discusssion group.
> To post to this group, send email to nanoc@googlegroups.com
> To unsubscribe from this group, send email to
> nanoc+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nanoc?hl=en
After thinking about it more, creating a summary attribute in yaml at the start of each page makes more sense for what I am trying to do and it compiles correctly each time. So this one isn't an issue for me now.
On Monday, May 7, 2012 2:24:24 AM UTC-5, Denis Defreyne wrote:
> Hi Warren,
> Now that I dive deeper into the issue, it indeed appears that there is > more to it than I just thought. The problem occurs when captured > content from a cached item is requested: in this case, the captures > store will be empty and it will appear that nothing is captured at > all. A fix for this would be to ask the compiler to forcefully > recompile the item, ignoring any cached data.
> There is no immediate easy way around this issue. The capturing helper > has always been a tricky one to get right, because it really operates > outside the normal nanoc workflow. Because of this, I recommend not > using the capturing helper. I will nonetheless still fix this issue, > but it is not unlikely that the capturing helper will be deprecated at > some point.
I’ve just fixed this issue (in a very ugly way, sadly) so this should no longer be a problem. nanoc’s current architecture makes it difficult to fix this issue properly. However, once nanoc gets support for parallel compilation (which will require some re-engineering), the implementation of the fix should become a lot cleaner.
> After thinking about it more, creating a summary attribute in yaml at the start of each page makes more sense for what I am trying to do and it compiles correctly each time. So this one isn't an issue for me now.
> Cheers,
> W
> On Monday, May 7, 2012 2:24:24 AM UTC-5, Denis Defreyne wrote:
> Hi Warren,
> Now that I dive deeper into the issue, it indeed appears that there is > more to it than I just thought. The problem occurs when captured > content from a cached item is requested: in this case, the captures > store will be empty and it will appear that nothing is captured at > all. A fix for this would be to ask the compiler to forcefully > recompile the item, ignoring any cached data.
> There is no immediate easy way around this issue. The capturing helper > has always been a tricky one to get right, because it really operates > outside the normal nanoc workflow. Because of this, I recommend not > using the capturing helper. I will nonetheless still fix this issue, > but it is not unlikely that the capturing helper will be deprecated at > some point.
> Regards,
> Denis
> -- > You received this message because you are subscribed to the nanoc discusssion group.
> To post to this group, send email to nanoc@googlegroups.com
> To unsubscribe from this group, send email to
> nanoc+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nanoc?hl=en
