Forum: Nitro Where to define Og relations

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.

http://robmela.com/cheatsheets

(ab)

--
Arne Brasseur
http://www.arnebrasseur.net
arne@arnebrasseur.net

>
> 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.


This is known/intended. Are you sure that has_many works without 
defining a
serializable attribute first?
This is what I use:

class Word
  is Og::Model
  belongs_to :user
end


the shortcut is that calling attr_accessor :filed, Type automatically
includes Og::Model.


I hope this helps
-g.

Some of the relation declarations are for the benefit of Og in schema
generation.

Others are for the benefit of Forms in generating form elements to bind
relations ( see the views in nitro/part/admin/og )

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 --
   http://www.php.net/docs.php.   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?

thx.

Rob,

  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.
>
> Criticism always welcome,
>
> Chris Scheper
>

>
>   I would be willing to post an example of what I propose to this list for
> you guys to consider.
>

please do so.

-g.

Ok, probably won't get it done till Sunday.

Chris

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.

Chris

thank you :)

-g.