I just found out the hard way that defining a ‘belongs_to’ relation at
the beginning of the model class does not work. Once any managed
attributes are defined it does works.
require “og”
class Word
belongs_to WordList
attr_accessor :definitions, Array
end
gives:
./app/model/word.rb:3: undefined method `belongs_to’ for Word:Class
(NoMethodError)
This:
class Word
attr_accessor :definitions, Array
belongs_to WordList
end
works fine.
Alternatively:
class Word
include Og::RelationDSL
belongs_to WordList
attr_accessor :definitions, Array
end
also works fine.
It’s not clear to me if this is intended or not, has_many seems to work
fine once “og” is required. I haven’t checked the other types of
relations.
G, is this known/intended? If so it should be documented. Robert, you
could perhaps add this to your cheatsheets? Very nice work BTW! I’m
using them all the time now.
This is similar to something I mentioned awhile back. And it has one
particular issue. The documentation does not evolve and get transported
to
users when they do, say… “sudo gem install og --version= 0.40.0” or
however you would type this for a specific version. (don’t feel like
looking
it up) Including og and nitro documentation in rdoc along with the code
accomplishes your goal and it keeps all evolving changes to
documentation
with the pertinent code. Tutorials should be a part of the rdoc
documentation is what I’m saying. Oxyliquit provides a place for users
to
post tutorial ideas and the base ones, like your cheatsheets get
installed
with every gem.
As for the collaborative documentation aspect, I’ll have to think
about
that for a bit. The back of my head is screaming wiki with an automated
export into darcs that only george can kick off. I’ll post back when I
have
some more defined ideas.
I would be willing to post an example of what I propose to this list
for
you guys to consider. I know this doesn’t necessarily associate the
comment
threads like on the php docs site you mentioned, I’d have to put more
thought into that than I have available brain power currently.
Just my 2cents
Chris
Below is the comment I made a while back about documentation called
“Keeping
Documentation and Tutorials up-to-date”
Hi all,
to knock putting them there, it’s actually one of the top locations new
the information a newbie needs to get their feet wet and attempt to get to
to get it working, but they should know what is possible with the class or
RDocs. This has key advantages…
3 - The published RDocs can be available through your website and through
you want to communicate howto ___. I’m all done ranting.
Sorry… I misunderstood the question… I’m up to my eyeballs in
exploring Og right now, and its filtering everything I see. I look at
my wife and kids and visualize the generated foreign key attributes that
join us…
Thanks for the kudos. What I’d like more than my cheatsheets is a
collaborative effort to produce documentation similar to the PHP docs – PHP: Documentation. I see it as a nitro app, with content
in DocBook or something similar. Perhaps Nitro elements could be
created named similarly to DocBook elements, such that the docbook pages
can be served up directly, as-is. The same pages could be used later
to generate a print book – produced by a community(!) with proceeds
going back to the project.
Would someone be willing to host that in a mercurial or darcs archive?
Well this is my first attempt at a patch but here goes.
It’s really just an addition of rdoc information for Og::Model. I’d
like to
make one for Og::Mixin as well, because I need to make quite a few
mixins
for og and I’m not sure how to do it. I’ll see what I can put together
and
post it here as well.
