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.
...
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.
···
--
Nathaniel Brown wrote:
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
Ruby Code & Style - 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
Daniel DeLorme ha scritto:
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)
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?
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.
regards,
George.
···
--
George may be using the Nitro Glycerin code base, not the current
released version.
indeed, I am using the repository version.
-g.
···
--