[Nitro] An implemention of Orbjson in Nitro

George Moschovitis george.moschovitis at gmail.com
Fri Mar 25 12:50:20 EST 2005

> I had written my own simple object registry to store service objects
> ..
> reuse Needle.  Less code for me to maintain.

I think a simple hash would do the job.

> It may seem trivial, but I find it odd that in order to write a really
> ..
> not.

I think you are asked if you want to install those libraries, when performing
a gem install.

> One thing that had me confused was how to add new controllers.  After
> ..
> http://mysite.com/foo

Is that so, I didn't know that. But what happens if you define a
helper base controller:

class BaseController

class BlogController < BaseController

class UsersController < BaseController

and you don't want to expose BaseController ?

Moreover, I am not sure how Rails knows how to register the controller
automatically, just be defining the class.

> What struck me about this, and where I think this may apply to Nitro, is
> ..
> drove the database, not the other way around.

I think we can pursuit that goal.

> But this approach may mean that you don't get certain things for free,
> simply based on naming or other coding conventions, because the
> philosophy behind the library is that your code should not carry too
> much default behavior . 

Yeah, this is one of the things I don't like about Rails. That too
many coding conventions are forced to the developer. Nitro will
propose naming conventions and development practices without forcing a
solution to the programmer.

> So, when you ask about suggestions on API design, I think I'm a bit
> unclear as to what the driving philosophy behind Nitro is, so I can't
> really say if it is proper to expect, for example, that classes with a
> certain naming convention should automatically acquire certain behavior.

As I said, I would like to have name-depended behaviour optional. The
driving philosophy of Nitro is to put the programmer *off* rails. That
means give the programmer more freedom: If the programmer wants to
create a simple php style application, he can do that without worrying
about MVC and stuff. Later he can extract the business logic in model
objects, and the presentation logic in actions, or he can move the
templates to a separate directory. Then he can enable output caching
etc, etc. Nitro suggest a directory structure but does not force this
structure to the user like Rails. Check out the blog and no_xsl_blog
examples to see different source code layouts. Or you can write Wee
style applications with no templates (check out wee_style and
> Hope this made at least a little sense, and if I've grossly
> misunderstood something please straighten me out.    

This makes sense.

> But it seems that Nitro/Og, and Wee, and perhaps other projects (maybe Orbjson), are or
> could be geared to this "don't commit to an operating environment until
> the last moment" style of development.

Ok I agree. I would like to hear some more concrete suggestions about
how we can achieve this.

> Nitro/Og seems to turn this around, though there is still the
> assumption (I think) that you plan on using a database of some sort and
> presenting on the Web.  

This is not true. Check out the why_wiki example. Moreover there is an
experimental filesystem adapter for Og.

> Suppose you had no idea, or you have existing
> command-line applications that had no data persistence.  Is it, or
> should it be, a purpose of Og/Nitro to make it easy to layer on Web
> presentation and a database back end?

This is a nice goal. I am open to suggestions about achieving this.



More information about the Nitro-general mailing list