If I'm understanding your question correctly I think judicious use of
the @state instance variable will achieve what you're looking for.
You'll be able to store what you need and be able to access it from
request to request.

Another option would be to use sqlite in memory mode.

App::Models::Base.establish_connection(:adapter=>'sqlite3',
:database=>':memory:')

You'll gain the benefits of a database but you'll be working in memory
only, so nothing's stored when your app is off.

Dave

On Thu, Aug 25, 2011 at 9:25 AM, Anders Schneiderman
<aschneider...@gmail.com> wrote:
> Hi,
>
>
>
> I need a little advice about maintaining state in Camping.
>
>
>
> I use NaturallySpeaking voice recognition software for most of my work -- I
> don't have happy hands -- and I've been creating little Ruby projects to
> make it easier to do some things by voice. I'd like to build a UI for them.
> After some painful experiences with some windows-based UIs, I'd like to try
> using Camping – it looks like fun, and I can use my HTML/CSS skills to make
> something pretty.
>
>
>
> For most of these little Ruby projects, I don't have to store anything in a
> database because the data is already being stored elsewhere. For example,
> I'm managing a team that's building a Microsoft-based data warehouse that
> uses Excel pivot tables as a front-end, and pivot tables are hard to
> manipulate using NaturallySpeaking. On my Camping site, I want to be able to
> display a long list of the available pivot table fields so I can click on
> them by voice.  I also want a text box so I can say, e.g., "show department
> and unit by row, year by column" or "only show fields containing committee."
> So all I need to store is the info I'm using to manipulate the pivot table:
>  the connection to the Excel worksheet and a list of the available fields
> that I grab from the Excel worksheet plus one or two properties about these
> fields. I don't need to save any of this info -- I grab it once at the
> beginning of the session, and I don't want to cache it because, for example,
> the list of fields will change depending on which data warehouse "cube" I'm
> connecting to.  I have other projects where the data is stored on a
> website/application that I'm grabbing/manipulating using Web services/APIs.
> In short, I don't need to permanently store any data, I just need to
> maintain state for a relatively small number of objects.
>
>
>
> What's the easiest way to do this in Camping? Is there a way to cache the
> list of field objects? Or does it make more sense to store them in a
> database and purge & refresh the data in the database each time I start up
> the Camping site?
>
>
>
> Thanks!
>
> Anders
>
>
>
> PS Maybe you're thinking, "using Excel pivot tables as a front-end to a data
> warehouse??" It does sound bizarre, and I was pretty skeptical at first, but
> it actually works pretty well. Microsoft has put a fair amount of work into
> turning Excel pivot tables into a pretty decent data warehouse front end.
> And since you're just using Excel, you get all the goodies are built into
> Excel. Not a good front-end if you are creating straightforward dashboards
> that are totally locked down, but if you have a pretty broad range of fields
> and you're encouraging folks to slice and dice the data themselves, it ends
> up being easier than most of the other tools out there.
>
> _______________________________________________
> Camping-list mailing list
> Camping-list@rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>



-- 
Dave
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Reply via email to