[Nitro] An implemention of Orbjson in Nitro
james_b at neurogami.com
Sat Mar 26 09:05:21 EST 2005
George Moschovitis wrote:
>>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.
Perhaps; that's what I started with. I forget now what other issues
came up that led me to Needle.
>>It may seem trivial, but I find it odd that in order to write a really
> I think you are asked if you want to install those libraries, when performing
> a gem install.
Yes; I once tried declining to install ActionMailer, and the whole
Rails install failed. I don't know if rubygems allows you to mark an
external gem as "nice to have but not essential", but I think that those
Rails gems are all marked as required. (And each time I install or
upgrade Rails I wish for a way to just say "yes to all", as one has
little choice to keep tapping the 'y' key.)
>>One thing that had me confused was how to add new controllers. After
> 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 ?
Don't call it *Controller ?
That's the issue with auto-registration/auto-exposure sort of stuff;
you want to have the most common use cases handled automatically, but
leave wiggle room for people to override them. So, you can have
no autoregistration of controllers (i.e. assume that people usually do
not want things named *Controller to be automatically exposed via the
URL), requiring manual intervention, or assume that things named
*Controller are so named because they are meant to map to URLs, yet
offer a way for allow people to manually hide classes when desired.
> Moreover, I am not sure how Rails knows how to register the controller
> automatically, just be defining the class.
Some system introspection, I'm guessing. Run through ObjectSpace at
startup and see what has been defined? Ruby has assorted magical
>>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
I looked at those last two rather quickly; I'll take another look to see
how they differ from each other and other Nitro apps.
More information about the Nitro-general