Og Self-Interaction Question

[Matthew_B_Gardner]

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

[Matthew_B_Gardner]

On Dec 12, 1:49 am, Matthew B Gardner [email protected] 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.

[Matthew_B_Gardner]

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.

[Matthew_B_Gardner]

Hello –

On Wednesday 12 December 2007 03:20, George M. 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

[Matthew_B_Gardner]

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

[Matthew_B_Gardner]

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.

[Matthew_B_Gardner]

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