On Thu, Aug 25, 2011 at 15:25, Anders Schneiderman
<aschneider...@gmail.com> wrote:
> Hi,
>
> I need a little advice about maintaining state in Camping.
>
Uh oh. Maintaining complex state is *always* a hassle, regardless of
language and framework…
The general way of maintaing state is using session cookies. It works like this:
require 'camping'
require 'camping/session'
Camping.goes :App
module App
include Camping::Session
end
module App::Controllers
class Index
def get
@state.counter = 0
mab do
p "Session ID = #{@state.session_id}"
p 'Counter = 0'
a 'Increment', :href => R(Increment)
end
end
end
class Increment
def get
@state.counter += 1
"Counter: #{@state.counter}"
end
end
end
Notes:
- See also http://camping.rubyforge.org/api.html#class-Camping-Session
- Note that you can't store more than ~3kB in sessions, so you shouldn't put
- `@state.session_id` is only available in Rack 1.3 (in previous
versions you have to generate it yourself if you need it)
- However, the current Camping release doesn't work well with Rack 1.3
when it comes to session
- That's fixed in the latest development version
I'm probably going to release a new version today or tomorrow. If you
can't wait until then, just run this command:
gem install camping --source http://bob.judofyr.net/gem
> 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.
Cool! Is easier to manage web apps than native apps using
NaturallySpeaking, or is it just the the native window-based UIs are
way too complex? I've never really optimized a web app for
accessibility (which is pretty terrible when I think about it)…
> 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?
I think you're going to save yourself a lot of problems if you can
download as much data and store it in a local database. It's much
faster and easier to just have everything in the database. Then you
can easily query it for whatever you need. See
http://whywentcamping.com/Book:-Getting-Started#Modeling-the-world for
how to use ActiveRecord to set up the database/schema.
You can either download the data in a controller (e.g. when someone
hits the front page) or just at startup. If only you're going to use
the app, it's probably easiest to load it at startup. If you want to
load it at startup, you should probably use a SQLite memory database.
This keeps all the database in memory and you don't have to clear it
everytime you start/stop your app.
Simply define a .create method (which the Camping server will call
when it starts up):
def App.create
App::Models::Base.establish_connection(:adapter => 'sqlite3',
:database => ':memory:')
end
> Thanks!
>
> Anders
Hopefully this should get you somewhat started.
>
> 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.
I'll have to admit that was exactly what I thought… But all that
really matters is that it works :-)
_______________________________________________
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
