Rails - Dec 2006 - I'ts not a (db-)model, not a controller - so is it a lib?

Hi!

I''m starting a test spike for a small Rails project, that
doesn''t have
any database backend. It''s some kind of a (Debian Linux) system
administration utility like webmin, that collects and displays system
informations, modifies config files at different locations and runs
system tasks like the installation of Debian packages.

I''m not sure yet, if Rails is the right tool for this, but
that''s what I
want to figure out. Even if I don''t need any of the ActiveRecord stuff,
ActionController, the rhtml-template''s, rjs and so on seem to be
useful enought to give Rails a try.

At this point I managed to make the unit tests work without a database
and have coded some simple controllers. But as it now becomes a little
bit more complex, a few questions came up:

1. I''m not using a database, so whenever I use some kind of model
class, I simply don''t derive it from ActiveRecord. Such a model e.g. is
"DebianPackage", which holds package information that were retrieved
from
the Debian system. The question now is, does this class still belongs
to app/model/ ? Or should non-DB backed models always go to lib/ ?

2. I have some classes that do stuff like retrieving cpu load info from
the system. These classes are some kind of service objects, not models
or controllers. Should they be put into lib/ or somewhere else?

3. If I put the service object classes in lib/, where should the tests
for it go? Am I free to simply put them into test/ or test/services and
create a rake task for it? Unfortunately this at least seems not to be
supported by ZenTest/autotest out of the box.

bye,

Tobias


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/18/06, Tobias Grimm
<listaccount-ztmIXtBW4J6sTnJN9+BGXg@public.gmane.org> wrote:
Hi,
>
> Hi!
>
> I''m starting a test spike for a small Rails project, that
doesn''t have
> any database backend. It''s some kind of a (Debian Linux) system
> administration utility like webmin, that collects and displays system
> informations, modifies config files at different locations and runs
> system tasks like the installation of Debian packages.
>
> I''m not sure yet, if Rails is the right tool for this, but
that''s what I
> want to figure out. Even if I don''t need any of the ActiveRecord
stuff,
> ActionController, the rhtml-template''s, rjs and so on seem to be
> useful enought to give Rails a try.
>
> At this point I managed to make the unit tests work without a database
> and have coded some simple controllers. But as it now becomes a little
> bit more complex, a few questions came up:
>
> 1. I''m not using a database, so whenever I use some kind of model
> class, I simply don''t derive it from ActiveRecord. Such a model
e.g. is
> "DebianPackage", which holds package information that were
retrieved from
> the Debian system. The question now is, does this class still belongs
> to app/model/ ? Or should non-DB backed models always go to lib/ ?
A model is a model, whether it uses AR or not.  Put it in app/model.
> 2. I have some classes that do stuff like retrieving cpu load info from
> the system. These classes are some kind of service objects, not models
> or controllers. Should they be put into lib/ or somewhere else?
Lib is fine, though you could also have a "model" called CPU that then
has the smarts underneath to do things like grabbing cpu load and the
like.
> 3. If I put the service object classes in lib/, where should the tests
> for it go? Am I free to simply put them into test/ or test/services and
> create a rake task for it? Unfortunately this at least seems not to be
> supported by ZenTest/autotest out of the box.
They can go either in /test/unit or /lib/test - I have a little hack I
use for /lib/test here:

http://www.robsanheim.com/2006/09/16/adding-your-lib-tests-and-plugin-tests-to-autotest/

Note that was an older version of autotest, but it should work in the
latest version w/o too much trouble.

- Rob

-- 
http://www.robsanheim.com
http://www.seekingalpha.com
http://www.ajaxian.com

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi,

Rob Sanheim wrote:
> A model is a model, whether it uses AR or not.  Put it in app/model.
>   
Ok. I was just a little bit confused about this, because here:

http://r4rclub.schtuff.com/rails_cheatsheet_gif?action=binary&ver=3

it says: lib = "... Often non-DB-backed models should be put here."

> Lib is fine, though you could also have a "model" called CPU that
then
> has the smarts underneath to do things like grabbing cpu load and the
> like.
>   
Right, the CPU wasn''t the best example. What I had in mind was more
something like a class "Dpkg" that wraps the Debian package tools and
has methods like get_available_packages() which returns a list of
"DebianPackage". DebianPackage would be the "model" and Dpkg
the service
responsible for providing instances of the model.

> They can go either in /test/unit or /lib/test - I have a little hack I
> use for /lib/test here:
>
http://www.robsanheim.com/2006/09/16/adding-your-lib-tests-and-plugin-tests-to-autotest/
>   
Thanks a lot!

bye,

Tobias

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---