[Nitro] 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
_______________________________________________
Nitro-general mailing list
Nitro-...@rubyforge.org
http://rubyforge.org/mailman/listinfo/nitro-general

[George Moschovitis]

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.

--
http://me.gr
http://joy.gr
http://cull.gr
http://nitroproject.org
http://phidz.com
http://joyerz.com

[Trans]

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]

Hello --

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

Thanks again,
Matt

[Matthew B Gardner]

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,

[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

[George Moschovitis]

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.

[Taylor Bob]

It's a nice article where from i gathered a lot of useful information
for myself.
--------------------
Taylor

http://cars.gov-auctions.org
--
Posted via http://www.ruby-forum.com/.