[Nitro] nitro 0.50: first encounter

Arne Brasseur arne at arnebrasseur.net
Tue Jul 3 15:23:54 EDT 2007

Jimmy Jazz schreef:
> 1. Collisions
> For instance, if I name a class Menubar with a lowercase 'b' in the 
> skin.rb file and its associated render method contains a <div 
> class="menubar">, the template <Menubar></Menubar> won't render 
> anymore until the class name is renamed MenuBar with a uppercase 'B'. 
> Also, the page will be always well rendered if <div class="menubar"> 
> is declared inside the htmlx template file.
> To illustrate the issue.....
It looks to me like you're mixing up two different things.

An Element is defined in a class, which corresponds with an XML tag 
(class Menubar and <Menubar>). To access any content within the XML tags 
you use the content method.
   <p>some random content</p>

class Menubar
  def render
    # here content has the value "<p>some random content</p>"
    # do with it whatever you like

The other thing is the special tag <render href="something" />, which is 
converted by the TemplateFilter (the last filter in the html pipeline) 
to the ruby code
render "something"

which is a method in Raw::Controller that renders a certain action on a 
certain controller. So render "menubar" will render the menubar action 
on the current controller, and that way the menubar.htmlx template gets 
rendered. (Hope you're still with me.)

What puzzles me is that according to the rdoc, a template file in the 
Element template_root gets converted to an Element class. I can't find 
this functionality in the code. Also what's the Element template_root? 
only Template has a template_root setting.
This could be what causes your name clash, I couldn't reproduce it.

G, if you're there, please enlighten me.

> 2. Question: how does #{content :method} really work ?
with #{content :element_id} you can access the content of sub-elements.
  <Menubar id="menu1">content related to menu1</Menubar>

class Page
  def render
    #content(:menu1) == "content related to menu1"
> 3. Annotation and elements
> class Blog::Controller
>   ann :self, :element_namespace => Post
> doesn't return an error and is linked to Blog::Controller::Post. I 
> think that is wrong ( it should be Raw::Element::Post)
> ann :self, :element_namespace => BlogPage
> returns an exception,  :  uninitialized constant 
> Blog::Controller::BlogPage
This looks simply a ruby thing. Remember a classname in ruby is just a 
constant that has an instance of Class asigned to it. When you write 
Post ruby will look up the constant Post in the current namespace. It 
will also look in some other places like top-level, I don't remember the 
details exactly. There's some discussion about the way constants are 
looked up anyway, IIRC it might change in ruby 1.9/2.0.

Anyway, Nitro can't do much magic here (except by using const_missing 
perhaps). If you write BlogPage and ruby can't find that constant, 
you're out of luck.
> 4. Just to mention it
> You need to press Ctrl-C twice to stop webrick
Not sure what to say here, anyone?
> 5. That is a bit Greek (Chinese?) to me
> Some messages are really hard to understand and to debug and make the 
> source look fragile. That can be very frustrating especially if the 
> method are part of ruby language (e.g. each).
> DEBUG: Rendering '/blog/post'
> DEBUG: Compiling 'post' super-method
> DEBUG: Compiling 'post' view sub-method [format: html]
> --------
> undefined method `each' for nil:NilClass
>   (eval):3:in `post___html___view'
> /home/lilo/workspace/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/publishable.rb:36:in 
> `send'
> /home/lilo/workspace/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/publishable.rb:36:in 
> `method_missing'
This basically looks like you've called nil#each in a template. The 
post__html__view method is generated by nitro, it renders the post 
action with the html format. It basically is a ruby version of your 

Perhaps the __view methods could be wrapped in a begin/rescue for nicer 
error reporting. Also a possibility is defining methods on nil to do 
error reporting, e.g. nil#each : You had a nil where you weren't 
expected it, you probably wanted an instance of Enumerable, like Array. 
Rails does this, probably because many who are new to ruby go to rails 
and get confused by ruby stuff. (for the record, I'm not suggesting this 
should be done, but it's a possibility.)
> 6. Helper required
> Also, isn't app/helper the default directory for the helpers ?
As far as I know there's no such thing as a 'default helper dir' in 
Nitro. I'm guessing, but G isn't a fan of the term 'helper'.
> 7. miscellaneous
> I often get the following message on the screen. What is wrong with 
> the arguments ? I don't use it.
> --------
> wrong number of arguments (1 for 0)
> /home/lilo/workspace/repo.nitroproject.org/script/lib/../../raw/lib/raw/compiler.rb:65:in 
> `index'
> /home/lilo/workspace/repo.nitroproject.org/script/lib/../../raw/lib/raw/compiler.rb:65:in 
> `send'
> /home/lilo/workspace/repo.nitroproject.org/script/lib/../../raw/lib/raw/compiler.rb:65:in 
> `index___super'
> /home/lilo/workspace/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:79:in 
> `send'
> /home/lilo/workspace/repo.nitroproject.org/script/lib/../../raw/lib/raw/controller/render.rb:79:in 
> `render'
I have seen this also, would have to take a closer look. Could this be a 

I hope this already helps somewhat. Keep posting whatever you have.

One tiny suggesting, if you could make a post for every subject that 
would make it easier for people to reply or to follow a thread.

a bientot,

Arne Brasseur
arne at arnebrasseur.net

More information about the Nitro-general mailing list