[Nitro] [ANN] Nitro/Og 0.31.0
gabriele renzi
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
Eric Armstrong
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
--
Posted via http://www.ruby-forum.com/.
Jamey Cribbs
> >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.
>
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'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'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.)
kha...@enigo.com
> 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
> On 7/26/06, Bill Kelly <bi...@cts.com> wrote:
>> (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.)
>
>
>
> 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
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 :posts
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
Mea Culpa. My appologies to the Nitro team. Poor choice of words on my
part.
best,
anne001
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
On 26 Jul 2006, at 15:15, Dimitri Aivaliotis wrote:
> 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
James Britt
> On 7/29/06, George Moschovitis <george.mo...@gmail.com> wrote:
>
>> 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
>
George may be using the Nitro Glycerin code base, not the current
released version.
--
James Britt
"Take eloquence and wring its neck."
- Paul Verlaine
George Moschovitis
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
> released version.
indeed, I am using the repository version.
-g.
gabriele renzi
That's somthing you can find in facets, the method Kernel#autoreload
http://facets.rubyforge.org/api/core/classes/Kernel.html#M000450
George Moschovitis
> 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
> 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
gabriele renzi
> 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?
because Demo does not use model objects' methods, such as the enhanced
attr_* or belongs_to.
You have the chance to fine tune this, anyway, in case that Og is not
smart enough to find the classes correctly (it usually works fine, anyway)
Benjohn Barnes
! :) That's very cool. *cough* I've not actually used facets at all.
Okay, I've had a look, and it looks very full of interesting stuff.
Is there some kind of map / table of contents for the collection?
Some kind of rough break down in to areas of functionality?
George Moschovitis
> how the hell does Og know that Content maps to the database and
> that Demo does not?
Og manages classes that define serializable attributes. A serializable
attribute is an attribute with a class annotation. This works great
for 95% of the cases. For the rest, you can use Og features like the
following to customize the behaviour, including:
class XXX
is Unmanageabke
end
or
class XXX
attr_accessor :test, String, :serializable => false
end
etc, etc.