[Nitro] nitro 0.50: first encounter

[Jonathan Buch]

Hi,

> If I'm in the wrong mailing list to expose my issues and to ask for
> help, just let me know where i have to post them and please, sorry for
> the noise.

you are quite right here, and up front:  I _really_ like the way your
post looks like.  It's informative, high amount of descriptions and
event code to replicate.  Many thanks for that.

> 1. Collisions

Not sure what's going on here, I'm hoping Arne can reproduce that.

[22:16]  <arne_b> wait a sec, have to try something
[22:18]  <arne_b> mmm can't reproduce the name clash

> 2. Question: how does #{content :method} really work ?

All I know is:  it's supposedly used for rendering 'sub elements'
inside of an element.  I also know that it is a hash (which makes
multiple same-named sub-elements impossible).

In my early days of Nitro I have looked at these and shoved them
away as too complex for my little mind to grasp.

> 3. Annotation and elements

> Also, i certainly misunderstood the annotation stuff ;)

Yes you do.  :P

> An example to illustrate the behavior:
>
> 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)

In the contrary, normal Ruby rules apply.  So, the constant
`Post` will be looked up:  first Blog::Controller::Post, then
Blog::Post, then Post.  Same applies to BlogPage, so the error isn't
really surprising.  If you want absolute the 'correct' constant, use
`::Raw::Element::BlogPage`.  There's no magic going on here, it's
really just plain ruby lookup rules, annotations have nothing to do
with that.

Annotations are a system to 'tag information to a symbol'.
`ann :self, :foo => :bar` adds merges the hash `{:foo => :bar}` into
the information which is available on the symol :self.
Too confusing?

Just think of annotations as a way of saving/retrieving information.


> 4. Just to mention it
>
> You need to press Ctrl-C twice to stop webrick

Yes, quite normal, Webrick just is that way, for a better experience
use mongrel.  :P


> 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).

> undefined method `each' for nil:NilClass
>   (eval):3:in `post___html___view'

Yes, I agree that this should probably better point to the template
(I assume that's where the error comes from).  Perfect error reporting
is one of the hardest things in a web-framework, really, especially
with templates.
I hope that George when he comes back can come up with a scheme where
he can pinpoint the error better.

> 6. Helper required
>
> When i need an helper for a class,
>
> include MenuHelper
>
> i have to declare explicitly the pathname for the helper in the file
> were include is called,
>
> require "#{File.dirname(__FILE__)}/../helper/menu"
>
> Also, isn't app/helper the default directory for the helpers ?

That always depends on your load path, if you need to explicitly
require paths or not.  For debug purposes, look into the global `$:`.
As the `helper :menu, :stack` method has been deprecated (removed?)
by George in this release, normal ruby rules apply and no special
path is searched/added by default. (I think.)

> 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'

Looks evil and like a bug, /me cries for George.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/