[Nitro] [ANN] Nitro/Og 0.31.0

[gabriele renzi]

(forwarding from nitro's list)


Nitro version 0.31 is a maintenance release, mostly aimed at fixing
small things in 0.30 release.

The release is mostly due to the great work of Bryan Soto at integrating
patches from the community and to the nicety of darcs


** Changes

= Og ==

* Increased size of ogtype field in single table inheritance tables to
50 from 30.

* Made Og (Mysql) respect the port option when creating and dropping
databases.

* Added thread_safe to Og.setup options.

* Added #to_xml and #to_rexml method to Og managed objects.

== Nitro ==

* Mongrel adapter updated to work with latest versions of Mongrel.

* Fixed a long-standing bug where the template root wasn't determined
correctly (would result in blank pages).

* Added sendfile support.

* helper/pager.rb: add option to set nav link titles

* Fixed strip_path support. When this setting is set to a path, it
will be stripped from urls. Given,

Router.strip_path = '/nitro-apps'

when the dispatcher gets a url like /nitro-apps/blog it will strip out
/nitro-apps and resolve to the controller for /blog.

* Wee helper is removed.

* Updated Nitro start page with links to the examples.

== Glue ==

Bugfixes. Refactored taggable.rb and removed attribute in favor of
Facets's cattr which was then replaced with settings.

** Contributors
Andrew Thompson
Bill Kelly
Fabian Buch
Fang Sun
Felix Wittmann
Gabriele Renzi
Guillaume Pierronnet
James Britt
Jan A. Lambert
Matt Moriarity
Michael Fellinger

** Get it by running

# gem update -y nitro

or

# gem install -y nitro

Archives for manual installations and example apps (examples, spark
and flare) are also available for download from

http://rubyforge.org/frs/?group_id=418

 

[Eric Armstrong]

Suggestion: If an announcement like this contained
a sentence or two telling me what nitro is, I'd
have some idea whether I wanted to google it or
traverse the rubyforge link in hopes of finding some
documentation.

 

[Jeff Pritchard]

Suggestion: If an announcement like this contained
a sentence or two telling me what nitro is, I'd
have some idea whether I wanted to google it or
traverse the rubyforge link in hopes of finding some
documentation.

From the rubyforge summary:
Nitro is an efficient, yet simple engine for developing professional Web
Applications using the Ruby language.

Guess it is a rails wannabe.

jp

 

[Jamey Cribbs]

Nitro is an efficient, yet simple engine for developing professional Web
Applications using the Ruby language.

Guess it is a rails wannabe.

I personally have not used Nitro, and I have no idea how many hours the
Nitro team has spent working on the project, however, I am pretty sure
that the amount of work put into Nitro warrants that it deserves to be
referred to as something more than "a Rails wannabe".

I don't mean to come across as critical of your statement; I just felt
like this should be said.

Jamey Cribbs

 

[James Britt]

I personally have not used Nitro, and I have no idea how many hours the
Nitro team has spent working on the project, however, I am pretty sure
that the amount of work put into Nitro warrants that it deserves to be
referred to as something more than "a Rails wannabe".

I don't mean to come across as critical of your statement; I just felt
like this should be said.

I've built applications in both Rails and Nitro. They're different
enough that both are worth knowing.

I believe that Nitro was underway at the same time as Rails was getting
going; both are frameworks extracted from actual applications built to
solve real-world problems. The projects may or may not have copied
ideas from one another (though I assume all good projects steal from
everything they can), but neither is a wannabe.

I find that Nitro lends itself to a different way of thinking about Web
and application development than Rails, and Og (the O/R part of Nitro)
is better suited for certain data and object persistence needs than
ActiveRecord.

The best part, of course, is that it's not an either/or choice, and if
you're serious about Web development in Ruby you owe it to yourself to
spend some time with Nitro, IOWA, Rails, and Wee, for starters.

Ruby gives you choices. Pick the best tool for the job.

--
James Britt

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://refreshingcities.org - Design, technology, usability

 

[Bill Kelly]

I personally have not used Nitro, and I have no idea how many hours the
Nitro team has spent working on the project, however, I am pretty sure
that the amount of work put into Nitro warrants that it deserves to be
referred to as something more than "a Rails wannabe".

I don't mean to come across as critical of your statement; I just felt
like this should be said.

I'd like to add that I'm not affiliated with the Nitro project itself,
but I'm using Nitro to develop a commercial web application.

I *think* Nitro has been around about as long as Rails. Certainly
Nitro and Rails were both around before either one became
popular.

On my current project, I started out in Rails, and bought the
excellent PragProg Agile Development w/ Rails book, and also
the superlative Rails Recipes book... Personally, (and this is
100% PERSONAL OPINION) Nitro ended up fitting the
contours of my skull better than Rails, so I switched to Nitro.
And I'm happy.

.... I was going to write more, but I just refreshed the unread
messages, and I see James Britt has already said the rest. <grin>

* * *

After some deliberation, I'd like to share a paragraph I
wrote to the Nitro mailing list, circa my decision to switch
from Rails to Nitro. . . . I am hoping this is acknowledged
as personal opinion, and is recognized to be just my
__personal impressions__:

2006-05-07
"(One of the things I _loved_ about Nitro vs. Rails, is
how Hello World in Nitro can be literally one .rb file and
maybe five simple lines of code. And how that Hello World
can be morphed steadily--as in the screencast--into a more
complex project piece by piece incrementally. Contrast
this with Rails, which generates a skeleton project of
44 files and 31 directories - just for Hello World. I'm
sure the argument is that for a large project one will
eventually _need_ all this structure; but I much prefer
the way Nitro gives me the opportunity to build incrementally
with just the structure I want.)"

Again, Nitro just meshed with my brain better - just a
personal opinion, and I respect others who may feel
differently.


Regards,

Bill

(P.S. if anyone can find the Nitro screencast showing
the evolution from simple Hello World "one liner" to a
gradually more complex app, I'd appreciate a link, as I
seem to have lost it. Thx.)

 

[khaines]

Nitro is an efficient, yet simple engine for developing professional Web
Applications using the Ruby language.

Guess it is a rails wannabe.

Nitro and Rails are similar in age, and similar in origins, as both were
extracted from work on a real world project. Both are web development
frameworks. And that's where the similarity ends.

They take different, but, IMHO, equally effective approaches to the
problem of making web development more efficient, as do each of several
other Ruby web development frameworks, none of which are Rails wannabes.


Kirk Haines

 

[Bill Kelly]

Is this the screencast you meant?

http://www.nitroproject.org/videos/nitro.html

Yes!! Thanks, that was it.

$ cat demo.rb
require 'nitro'

class Hello
def index
'hello world'
end
end

Nitro.start Hello


.......That was something I could really latch onto, because
the complexity builds from there. But what a nice starting
point. Elegant.



Regards,

Bill

 

[George Moschovitis]

Let me present another more elegant example of Nitro:

require 'nitro_and_og'

class Content
attr_accessor :title, :body, String
attr_accessor :hits, Fixnum

def initialize(title)
@title = title
end
end

class Category < Content
attr_accessor :wow, String
has_many osts
end

class Post < Content
belongs_to :category
end

class Demo
def categories(oid)
category = Category[oid]
print "<ul>"
for post in category.posts
print "<li>{post}</li>"
end
print "</ul>
end

def init_db
c1 = Category.create('Hello')
c2 = Categroy.create('World')
post = Post.new('Hello world')
post.category = c1
post.save
end
end

Og.start
Nitro.start Demo

hit http://localhost:9999/init_db to put dummy data in the database
(sqlite used by default)
hit http://localhost:9999/categories/1 to view the posts in category 1.

Notice how nitro automatically handles nice urls. Also note that you
could (and should) use a separate xhtml template (view) to handle the
page rendering instead of using print statements (or the programmatic
builder).

But you really have to experiment with Nitro, there are so many
features/options.


regards,
George.

 

[Jeff Pritchard]

I personally have not used Nitro, and I have no idea how many hours the
Nitro team has spent working on the project, however, I am pretty sure
that the amount of work put into Nitro warrants that it deserves to be
referred to as something more than "a Rails wannabe".

I don't mean to come across as critical of your statement; I just felt
like this should be said.

Jamey Cribbs

Mea Culpa. My appologies to the Nitro team. Poor choice of words on my
part.

best,
jp

 

[anne001]

I was impressed with nitro and dislike rails for that exact reason:
Just one file and I got a redirect in nitro, whereas rails has millions
of files.

Unfortunately, nitro does not get the attention rails got, and so there
may not be
the code streamlining, code cleaning, that may come when many look at a
same code, and there are no books out there on how to use it.

 

[Benjohn Barnes]

Is this the screencast you meant?

http://www.nitroproject.org/videos/nitro.html

I'm just running through this now (having installed Nitro through
Gems - I love it!).

I'm liking things so far. In my copying parrot style though, I was
restarting the server each time I made a change (which doesn't
actually happen in this screen cast). I just forgot to do that, and
after making a change to my source, went directly over to my browser
and hit refresh... And the page changed! How does that work then?!
That's not normal Ruby behaviour, that's not. But I like it a lot

 

[Phil Tomson]

Let me present another more elegant example of Nitro:

require 'nitro_and_og'

class Content
attr_accessor :title, :body, String

I get the following error message when I try to run this:
nitro_demo.rb:5:in `attr_accessor': String is not a symbol (TypeError)
from nitro_demo.rb:5

...and it does seem to make sense, String is not a symbol...


Phil

attr_accessor :hits, Fixnum

def initialize(title)
@title = title
end
end

class Category < Content
attr_accessor :wow, String
has_many osts
end

class Post < Content
belongs_to :category
end

class Demo
def categories(oid)
category = Category[oid]
print "<ul>"
for post in category.posts
print "<li>{post}</li>"
end
print "</ul>
end

def init_db
c1 = Category.create('Hello')
c2 = Categroy.create('World')
post = Post.new('Hello world')
post.category = c1
post.save
end
end

Og.start
Nitro.start Demo

hit http://localhost:9999/init_db to put dummy data in the database
(sqlite used by default)
hit http://localhost:9999/categories/1 to view the posts in category 1.

Notice how nitro automatically handles nice urls. Also note that you
could (and should) use a separate xhtml template (view) to handle the
page rendering instead of using print statements (or the programmatic
builder).

But you really have to experiment with Nitro, there are so many
features/options.


regards,
George.

 

[James Britt]

I get the following error message when I try to run this:
nitro_demo.rb:5:in `attr_accessor': String is not a symbol (TypeError)
from nitro_demo.rb:5

...and it does seem to make sense, String is not a symbol...

George may be using the Nitro Glycerin code base, not the current
released version.

 

[George Moschovitis]

...and it does seem to make sense, String is not a symbol...

Sorry, I forgot to mention that this example works with the repository
version (nitro/og 0.40.0). To make this work with the released
version, replace attr_accessor with property.
ie,

class Content
property :title, String
end

using attr_accessor is one of the many cool changes of the new version ;-)

regards,
George.

PS: please notice that og automatically generates the schema for you,
you dont have to initialize the database with sql code.

 

[George Moschovitis]

George may be using the Nitro Glycerin code base, not the current

released version.

indeed, I am using the repository version.

-g.

 

[gabriele renzi]

Benjohn Barnes ha scritto:

I'm just running through this now (having installed Nitro through Gems
- I love it!).

I'm liking things so far. In my copying parrot style though, I was
restarting the server each time I made a change (which doesn't actually
happen in this screen cast). I just forgot to do that, and after making
a change to my source, went directly over to my browser and hit
refresh... And the page changed! How does that work then?! That's not
normal Ruby behaviour, that's not. But I like it a lot

That's somthing you can find in facets, the method Kernel#autoreload
http://facets.rubyforge.org/api/core/classes/Kernel.html#M000450

 

[George Moschovitis]

Would be nice to see a Rails version of Nitro, with the directories already

there for you, with the auto-loaders present for things such as Models.
...
load path. I am under the impression nothing like this exists in Nitro?

some 'conventions' also exist in nitro. In a future version we plan to
add more conventions to allow the engine to automatically require
models, mount controllers at the correct path and stuff like that.
This is extremely easy to do, we are simply not 100% sure which are
the best 'conventions' at the moment.

I would suggest that you register with nitroproject.org and especially
the mailing list to stay up-to-date with this project which is
improving every single day.


regards,
George.

 

[Daniel DeLorme]

Let me present another more elegant example of Nitro:

require 'nitro_and_og'

class Content
attr_accessor :title, :body, String
attr_accessor :hits, Fixnum [snip]
class Demo [snip]

Og.start
Nitro.start Demo

That's a cute example, but it leaves me with one big question:
how the hell does Og know that Content maps to the database and
that Demo does not?

Daniel

 

[James Britt]

After looking at the Nitro video, the structure is very loose, which I
appreciate and somewhat dislike at the same time. Having default
organization is nice, but at the same having useless organization is just
that - pointless.

Would be nice to see a Rails version of Nitro, with the directories already
there for you, with the auto-loaders present for things such as Models.

On that same note, I noticed during the screencast, you had to directly
require the Model. In Rails it has the auto-loading mechanism which will
attempt to locate the model in specific directories which are based on the
load path. I am under the impression nothing like this exists in Nitro?

It's a mixed blessing. If you know that all of your applications are
going to follow a certain file layout then it helps to just have that
handled automagically. But the code to do that is trivial, so rather
than have to accept the layout and code bundling presented by the
framework, you can pick your own. You still get auto-requiring while
not having to adopt a forced layout or wade through a dozen files and
directories you may not have any use for. YAGNI, and so on.

But there are benefits when developers are following the same
conventions. For example, people can reasonably expect that any random
Rails app will have certain files in certain locations. You can use
engines and plugins and helper tools (such as AutoTest, which is quite
slick) written by other people, and they Just Work.



--
James Britt

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com - Playing with Better Toys
http://www.30secondrule.com - Building Better Tools