[Nitro] Og update

James Britt james_b at neurogami.com
Fri Apr 22 18:15:27 EDT 2005

craig duncan wrote:
> James Britt wrote:
>> I didn't want to turn this into Yet Another Rails List, but this may 
>> be of interest to George as a way of perhaps explaining some behavior.
> <snip>
>> obj_set = ObjectSet.get( "select t.name as name from tags t,
>>                p.url as url from posts p
>>                where p.id = t.post_id" )
>> # obj_set  should now have objects with properties 'name' and 'url'
> Very cool!  How can so many people be working on Rails and have been 
> able to live without having (more or less) worked out this problem?  
> Oh... i forget... Rails hasn't hit 1.0 yet.  :-)

Well, I believe this sort of thing *can* be done inside Rails (though 
not quite the way I would prefer); my experience with the Rails mailing 
list is that most people there know very little Ruby, and build apps 
only by following Rails tutorials or examples.  I don't think many 
people actually look at the source code.

> Anyways, thanks James, you have given me my direction for how to (try 
> to) make this
> work without having to change my db schema or resort to other kludginess.

>> There have been some recent threads on ruby-talk about dynamically 
>> adding attributes, or one could first dynamically construct a class 
>> def based on the field names in the result set, then create an 
>> instance of this for each row.
> I haven't been keeping up on ruby-talk.  But i thought this was already 
> "easy" to do.  ?  i.e. no real innovation required (just exercising 
> Ruby's existing metaprogramming abilities).

It is easy to do.  But maybe not obvious.  (I keep toying with the idea 
of writing a Ruby tutorial, one that would focus on the Lispy 
metaprgramming aspects that are either ignored or buried in other Ruby 
books and how-tos.)

>> Rails can be overkill.  AR may be overkill.
> Something to ponder and, although i don't yet know enough, those 
> conclusions have certainly crossed my mind.  Or both overkill and 
> underkill at the same time.  :-)

Well, I like Rails for certain types of applications, but the Nitro 
approach seems a better fit for much of what I do.

Rails, though, seems to be approaching a shotgun/kitchen-sink framework, 
what with  the increasing number of built-in libraries and code 
generators.    One is strongly encouraged to do things the Rails way, 
not the Ruby way, which may lead to brittle or highly-coupled code.

Doing the simple thing can get hard, then, unless you know the specific 
Rails API call.

>> I started writing my Nitro tutorial as a way to help me learn how to 
>> use it.  I basically tried to start off with the simplest case, see 
>> how to do something, then gradually add features based on likely use 
>> cases.
> Well, in all seriousness, i started with Rails and haven't really 
> touched Nitro yet.  But if you want some eyes on what you've produced so 
> far, i'd love to take a look.  I could probably give you some good 
> feedback.

Thanks.  I have to review and revise what I have already written, seeing 
how Nitro keeps changing (Damn you, George!).  I'll send you a copy when 
the revisions are done.


More information about the Nitro-general mailing list