On 9 July 2010 12:40, MattB <mtbroo...@gmail.com> wrote:
>
> HI Colin,
>
> What might a model not derived from ActiveRecord look like, and what's
> the advantage of doing that? I'm looking up data from a 3rd party API,
> but somply have the code in the controller, without a model.

It looks exactly like an ActiveRecord model except that it starts
class MyModel
instead of
class MyModel < ActiveRecord::Base
and of course it does not have access to the ActiveRecord methods (find, etc).

The reason for putting the access code in a model rather than in the
controller or controllers is to encapsulate it all in one place and to
provide a nice interface for accessing the data.  The model can then
provide methods for fetching the data for example, and have attributes
for the current values.  The calling code can then use these methods
and attributes without having to worry about how the tftp magic is
done.  This strategy also allows tests to be written to test the model
independent of the controller code.

Colin

>
> Tnx,
> Matt.
>
> On Jul 9, 9:18 am, Colin Law <clan...@googlemail.com> wrote:
>> On 8 July 2010 16:30, Colin Law <clan...@googlemail.com> wrote:
>>
>> > On 8 July 2010 11:39, Adrian Wadey <adri...@ssosystems.com> wrote:
>> >> I'm new to RoR.  Would I need to be looking at the Model code to talk to 
>> >> the
>> >> real-time stuff or would I need to look deeper into ROR?  Just after some
>> >> general pointers at this point.  Need to spend some time working through
>> >> some of the tutorials.
>>
>> > I guess you would likely want to provide a model (not derived from
>> > ActiveRecord) to wrap the real time data access.
>>
>> Further to this, much will depend on what you mean by 'real-time
>> stuff'.  If, when the user updates a page, it needs to display the
>> absolutely up to date data then you may have to fetch it in-line
>> during the rails action (via the wrapping model) and accept the
>> performance hit this will cause.  If, however, it is ok for the data
>> to be at least a reasonable number of seconds old then you have the
>> option of buffering the data locally (since you talk about using tftp
>> I presume it resides on a remote machine).  One option here may be to
>> save it to the database routinely using a background task running at
>> whatever rate is appropriate for your data.  You could either add new
>> records if you want to keep the history, or just update a single
>> record table if not.  The great advantage then is that as far as the
>> rails app is concerned it is just accessing the database and your
>> 'real time' mapping model is just a normal ActiveRecord derived one.
>>
>> I use a variant of this approach for my weather station app.  I have a
>> local PC fetching data from my weather station every minute or two.
>> It puts this into a file and pushes it to my remote hosted website
>> server.  It then uses ssh to run a rake task on the server to update
>> the database, adding new records as I wish to display the history of
>> course.  The rails app then accesses the data without concern for the
>> fact that it is real time.
>>
>> Colin
>>
>> >> -----Original Message-----
>> >> From: rubyonrails-talk@googlegroups.com
>> >> [mailto:rubyonrails-t...@googlegroups.com] On Behalf Of Colin Law
>> >> Sent: 08 July 2010 11:30
>> >> To: rubyonrails-talk@googlegroups.com
>> >> Subject: Re: [Rails] Non Database
>>
>> >> On 8 July 2010 11:21, Adrian Wadey <adri...@ssosystems.com> wrote:
>> >>> Hi,
>>
>> >>> I am looking at using Ruby in an application that, as well as having the
>> >>> usual database will also need to interface to real-time data using tftp.
>>
>> >>> Is it possible to do this within RoR?
>>
>> >> I don't see why not
>>
>> >>> Where do I start?
>>
>> >> What is it that you do not know how to do?
>>
>> >> Colin
>>
>> >> --
>> >> 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-t...@googlegroups.com.
>> >> To unsubscribe from this group, send email to
>> >> rubyonrails-talk+unsubscr...@googlegroups.com.
>> >> For more options, visit this group at
>> >>http://groups.google.com/group/rubyonrails-talk?hl=en.
>>
>> >> --
>> >> 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-t...@googlegroups.com.
>> >> To unsubscribe from this group, send email to 
>> >> rubyonrails-talk+unsubscr...@googlegroups.com.
>> >> For more options, visit this group 
>> >> athttp://groups.google.com/group/rubyonrails-talk?hl=en.
>
> --
> 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-t...@googlegroups.com.
> To unsubscribe from this group, send email to 
> rubyonrails-talk+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>

-- 
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-t...@googlegroups.com.
To unsubscribe from this group, send email to 
rubyonrails-talk+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en.

Reply via email to