Ruby Forum Nitro > Og Self-Interaction Question

Hello --
  I'm writing a game which uses Og with MySQL, and I want my website to 
be
able to interact with that data as well. I'm wondering about solutions 
to
this problem:

Game...

class HelpFile
  property :name, String
  property :body, String
  property :viewed, Integer
end

Web...

class HelpFile
  attr_accessor :name, String
  attr_accessor :body, String, :control => :textarea
end

The web class doesn't need the viewed attribute, but I'm assuming it'll 
drop
that attribute from the database if it isn't declared. Likewise, I'm 
sure
there will be web-data that I won't need in the game. I know I could 
disable
full evolution, but I'd like to not have to do that...especially since I
think that's one of the best reasons to use Og with my project (changing 
to
add might not be too terrible). Maybe using two different declarations 
of
essentially the same class isn't even good practice, but the game class
having access to web-based methods and vise-versa seems problematic to 
me
(not to mention the classes are in two different places).

Does anyone have some insight on this? Implementation solutions?

Thanks for any help -- please let me know if further clarification is 
needed,
Matt

On Dec 12, 1:49 am, Matthew B Gardner <weat...@speakeasy.net> wrote:
>         property :viewed, Integer
> that attribute from the database if it isn't declared. Likewise, I'm sure
> there will be web-data that I won't need in the game. I know I could disable
> full evolution, but I'd like to not have to do that...especially since I
> think that's one of the best reasons to use Og with my project (changing to
> add might not be too terrible). Maybe using two different declarations of
> essentially the same class isn't even good practice, but the game class
> having access to web-based methods and vise-versa seems problematic to me
> (not to mention the classes are in two different places).
>
> Does anyone have some insight on this? Implementation solutions?

Seems reasonable that you could define a single base class for the
table then two subclasses that act as "views". If sub-classing does
not provided a means for  avoiding the evolution then just delegate --
which certainly will work.

T.

One question.

why do you use property for the Game class and attr_accessor for the Web
class?

from what I understand you keep 2 different codebases and a single 
database.
This looks like duplication of effort to me (and I can think of
synchronization problems, etc..) I can see no easy solution to your 
problem
(apart from changing to :add evolution)

-g.

Hello --

On Wednesday 12 December 2007 05:56, Trans wrote:
> >         property :body, String
> > The web class doesn't need the viewed attribute, but I'm assuming it'll
> > Does anyone have some insight on this? Implementation solutions?
>
> Seems reasonable that you could define a single base class for the
> table then two subclasses that act as "views". If sub-classing does
> not provided a means for  avoiding the evolution then just delegate --
> which certainly will work.
>
> T.

Thanks for the ideas -- could you expand on what you mean by delegate 
though?

Thanks again,
Matt

Hello --

On Wednesday 12 December 2007 03:20, George Moschovitis wrote:
> One question.
>
> why do you use property for the Game class and attr_accessor for the Web
> class?
>

That was unintentional...I learned Og through tutorials that used 
property
instead of the generic accessors. I'm assuming I can use the accessors
everywhere now, or is there a valid reason to keep using property?

> from what I understand you keep 2 different codebases and a single
> database. This looks like duplication of effort to me (and I can think of
> synchronization problems, etc..) I can see no easy solution to your problem
> (apart from changing to :add evolution)
>
> -g.

It's just one codebase (the game), but I want to use the web aspect for
editing things that would otherwise be much more tedious and less
user-friendly inside the game. For example, writing and editing 
helpfiles for
things inside a browser would be much easier and dynamic than it would 
be
inside the game. I guess I misspoke in my initial post...the two classes
aren't the same, they just share the same data and need to share class 
name
to do so (to access the same db table). I think switching to add 
evolution
may be the most natural solution for me, but I'm going to look into 
Trans's
ideas too.

Thanks for your help,
Matt

Hello --
  Sorry to reply to myself, but I had some more thoughts...I apologize 
if I
wander outside the scope of Nitro/Og at all. I was thinking that I could
declare the attributes for each class shared by the game and the web
interface outside of the class declarations that include game or web 
specific
methods. I'm not concerned with them being the same class, I'm just 
concerned
about one declaration dropping a table it shouldn't. Also, declaring the 
same
attributes for the same class twice doesn't seem very Ruby-ish.

I was thinking, then, that I could just do something like...

class Helpfile # in a file called shared
  attributes...
end

Game...

require 'shared'
class Helpfile
  game methods...
end

Web...

require 'shared'
class Helpfile
  web methods...
end

Now, the game and the web interface wouldn't have access to each other's
methods, which I think would be a problem otherwise. I'm not sure if 
this is
good application/web design, but it makes sense to me, anyway.

I know Og stands by itself, but just to make sure...would this cause any
problems on the game side, which only includes Og? --

attr_accessor :body, String, :control => :textarea

I'd need that for the web-side, of course.

Thanks again for any help/answers,
Matt

>
>
> I know Og stands by itself, but just to make sure...would this cause any
> problems on the game side, which only includes Og? --
>
> attr_accessor :body, String, :control => :textarea
>

no problem whatsoever. :control is just an annotation. it will be just
ignored ;-)

-g.