Cells-4.0.4 : uninitialized constant Cell::Concept (NameError)

[byrnejb]

I am incorporating TBR into an existing project. I successfully got to the point of switching to cells from actionview and then things went off the Rails, so to speak. To determine what was going on I eventually removed all of the TBR related code that I had added, saving only that the application.rb file still contained the TBR require. I then used rails generate concept ar_invoice to create a pristine concepts tree. However, once this was done then rails will no longer start and one instead obtains the error given in the title.

I have an open question on StackOverflow (https://stackoverflow.com/questions/35319429/cells-4-0-4-uninitialized-constant-cellconcept-nameerror) with all of the relevant file contents from the original project. The generated code that give the same results is exactly as it was generated so I do not think there is much point in providing it.

I acknowledge that it is probably some configuration error on my part but I cannot find it,

[apotonick]

Answer on SO.

You have to say ::Cell::Concept not Cell::Concept, Ruby will look it up in the wrong namespace otherwise.

[byrnejb]

Is there something wrong with my TBR setup or should the concept generator be altered?

On Thu, February 11, 2016 00:30, Nick Sutterer wrote:

Answer on SO.

You have to say ::Cell::Concept not Cell::Concept, Ruby will look it up in the wrong namespace otherwise.

---

Reply to this email directly or view it on GitHub: https://github.com/apotonick/cells/issues/374#issuecomment-182719741

* e-Mail is NOT a SECURE channel * Do NOT transmit sensitive data via e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3

[byrnejb]

On Thu, February 11, 2016 00:30, Nick Sutterer wrote:

Answer on SO.

You have to say ::Cell::Concept not Cell::Concept, Ruby will look it up in the wrong namespace otherwise.

---

class ARInvoice::Cell < ::Cell::Concept
  def show
    render
  end
end

rails c
/home/byrnejb/Projects/Software/theHeart/code/proforma/app/concepts
/ar_invoice/cell.rb:1:in `<top (required)>': uninitialized constant
 Cell::Concept (NameError)

This by itself does not seem to work. Or have I misunderstood where ::Cell:Concept is supposed to be used?

[byrnejb]

I never ran into this problem before but evidently one must explicitly name a gem in ones Gemfile in order for it to load into the application. I had listed cells-hamlit in the Gemfile without naming cells itself. Cells-hamlit brings the cells gem into the bundled gem list as a dependency but it does not cause it to be loaded on application startup. And that caused the problem. Once cells was explicitly named then the original formulation of class ARInvoice::Cell < Cell::Concept worked as expected.

[apotonick]

Maybe because cells-hamlit doesn't require "cells" ?

[byrnejb]

Sorry about that. I initially took a different interpretation of the word require as inline code formatting does not show up well on my system. I have not previously run into a situation where one gem has a dependency upon another and yet does not require it.

[apotonick]

Here, that's what I mean: https://github.com/trailblazer/cells-hamlit/blob/master/lib/cell/hamlit.rb#L1 We don't require "cells" - we probably should do that in all gems cells-erb, and so on. Do you want to do that for all four gems? :heart:

[byrnejb]

I am not really in a position to suggest, much less recommend, any particular approach. I am just beginning to work with Cells and my experience with Trailblazer is not much greater. My comment referred to the fact that I had not encountered this situation before and I was surprised by it. On the other hand, this situation did forcibly impress on me one aspect of Bundler's behaviour that I had not given much thought to.

However, on further reflection, I think that the principle of least surprise should apply here and that gems should in general require() their dependencies; unless there is a very good technical reason not to. I do not know what common practice is but I tend to only explicitly list the minimum number of Gems in my Gemfile and allow the dependency tree to bring in everything else. This assists me in trimming back obsolete gem references to the bare minimum. Which, over time, have proven an amazingly large number in several projects.

Anyway, regardless of what you decide to do, thank you for your patience and help. I am now into yet another Cells set-up issue which will no-doubt be resolved by re-reading the documentation or further begging for help in various venues.

By the way, forgive me if I appear dense, but is it your remark meant to imply that I should do as you suggest and submit the changes as a pull request? I have no objection to doing so. I just want to make the situation clear to myself and assume nothing.

[apotonick]

Yeah, I agree with you that we should require cells as a dependency, and if you want, you can PR that on all four gems (unless it's already done in the particular gem). It would be of great help for us! :heart:

[byrnejb]

On Mon, February 29, 2016 06:34, Nick Sutterer wrote:

Yeah, I agree with you that we should require cells as a dependency, and if you want, you can PR that on all four gems (unless it's already done in the particular gem). It would be of great help for us! :heart:

---

Reply to this email directly or view it on GitHub: https://github.com/apotonick/cells/issues/374#issuecomment-190167115

I will try and get to it this week. Things are a little hectic atm.

Regards,

* e-Mail is NOT a SECURE channel * Do NOT transmit sensitive data via e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3