How about moving part/lib/* to nitro/lib or raw/lib?

Unless the parts will be a seperate project/package this seems
reasonable. That way a require “part/admin” always works where a require
“nitro” works.

(ab)


Arne B.
http://www.arnebrasseur.net
http://www.zhongwiki.com
http://www.bankske.org
[email protected]

On Dec 6, 9:56 pm, Arne B. [email protected] wrote:

Unless the parts will be a seperate project/package this seems
reasonable. That way a require “part/admin” always works where a require
“nitro” works.

Funny thing that. George wanted to use require ‘part/…’. And I
explained that would mean “part” basically becomes library unto itself
– then I obliged him by doing exactly that.

So the question is, should “parts” be it’s own package?

But lets take this a step further, b/c ever since Raw cam into
existence I’ve been a bit confused. Can Raw be used w/o Nitro? If not,
what’s the point of the split? There’s hardly anything in the Nitro
package actually. I figured the idea was that Raw represents the web-
side of Nitro independent of Og, so if one really wanted they could
tie Raw with another ORM system. Is that reasonable?

The Nitro package, on the other hand, marries Raw and Og together –
and parts generally effect both. So yes, if nowhere else, parts
belongs in nitro. However if we can, I think it would be beneficial to
pursue tighter SOC, and actually makes “parts” a separate package. In
this way Nitro becomes a collection of libs that come together to form
the complete framework, rather then being a portion of it too.

However “parts” is probably too generic a name --we would need
something to go along with Raw and Og.

T.

In the begining I thought that parts should be in

nitro/lib/part

but Tom has convinced me to go for a separate package. I think parts is
a
greate name lets stick to this.

-g.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs