Advice on strategy for maintaining state in Camping
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
Re: Advice on strategy for maintaining state in Camping
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
Re: Advice on strategy for maintaining state in Camping
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
Feature: Simple controllers?
I just pushed a new feature to Camping: Simple controllers.
module App::Controllers
get '/(.*)' do |name|
Hello #{name}
end
end
What do you think? Useful? Or should I revert it? It currently costs
us 87 bytes.
// Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: Feature: Simple controllers?
Personally I probably won't be using it, I like having class names around and being able to link to them with R(). (I change my paths often.) Certainly won't hurt to have it, for really small apps. -- Matma Rex ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Feature: Simple controllers?
If I wanted that notation, I'd just use Sinatra. ;)
Like Bartosz, I like having named controllers so that I can pass them to R()
when generating links.
On Thu, Aug 25, 2011 at 10:20 AM, Magnus Holm judo...@gmail.com wrote:
I just pushed a new feature to Camping: Simple controllers.
module App::Controllers
get '/(.*)' do |name|
Hello #{name}
end
end
What do you think? Useful? Or should I revert it? It currently costs
us 87 bytes.
// Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: Feature: Simple controllers?
On Thu, Aug 25, 2011 at 21:28, David Susco dsu...@gmail.com wrote:
Would you have to write the RE for every declaration?
ie...
module App::Controllers
get '/(.*)' do |name|
Hello #{name}
end
put '/(.*)' do |name|
Hello #{name}
end
end
That wouldn't work. Camping would dispatch all methods to the first
controller (so you'll get a 501 error when you PUT). In that case
you'll have to refactor it into a proper controller. Which I consider
a good thing (DRY etc.)
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: Advice on strategy for maintaining state in Camping
Thank you so much Magnus and David for your speedy advice! Magnus, I think you're right a SQLlight database seems like the best way to go. 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)? It's a bit of both. NaturallySpeaking tries to make their software as Web-friendly as possible, so, for example, if I display the fields I want to be able to choose as a bunch of hyperlinks in a on the page, I can click any of them by voice as I could any link on a webpage. With wxruby, that's not the case. And since I've done a lot of HTML/CSS work in past jobs, I can bang it out a lot faster than learning wxruby or some other UI – and it's a lot easier to build something that has a little style to it. :) Thanks very much! Anders ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Advice on strategy for maintaining state in Camping
Hold up guys. This is a little web app for just you to use? not multiple users? Depending on how you deploy camping you can just stick some stuff in some class variables if you just need them in one controller, or even global variables if you want them in many places. Then all you'd need to do is boot a local copy with The Camping Server and do your things. The objects will just stay in ruby's memory because unlike cgi apps or things like PHP, ruby web apps don't flush their global scope reload on every request. Wouldn't that be the ridiculously easy and straight forward way to solve this? — Jenna On 26/08/2011, at 7:33 AM, Anders Schneiderman wrote: Thank you so much Magnus and David for your speedy advice! Magnus, I think you're right a SQLlight database seems like the best way to go. 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)? It's a bit of both. NaturallySpeaking tries to make their software as Web-friendly as possible, so, for example, if I display the fields I want to be able to choose as a bunch of hyperlinks in a on the page, I can click any of them by voice as I could any link on a webpage. With wxruby, that's not the case. And since I've done a lot of HTML/CSS work in past jobs, I can bang it out a lot faster than learning wxruby or some other UI – and it's a lot easier to build something that has a little style to it. :) Thanks very much! Anders ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Feature: Simple controllers?
I vote revert. This is just sinatra - I feel it's important camping maintains the cleanliness and clarity of functionality given to us by using simple classes. It's something we have which AFAIK no other ruby web framework does - you know exactly how it works, because it's just a class. On 26/08/2011, at 7:21 AM, Magnus Holm wrote: On Aug 25, 2011 10:54 PM, John Beppu john.be...@gmail.com wrote: If I wanted that notation, I'd just use Sinatra. ;) Like Bartosz, I like having named controllers so that I can pass them to R() when generating links. Does it make it better that you can name them too? Index = get / do ... end Sent from my iCampingPhone ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Feature: Simple controllers?
Being able to name controllers definitely makes it more valuable. If I had to criticize Sinatra and its clones, I would criticize their lack of named controllers. It's difficult to write URL generation functions without them. I've only seen one Sinatra clone (Slim in php) that allows controllers to be named. On Thu, Aug 25, 2011 at 2:21 PM, Magnus Holm judo...@gmail.com wrote: On Aug 25, 2011 10:54 PM, John Beppu john.be...@gmail.com wrote: If I wanted that notation, I'd just use Sinatra. ;) Like Bartosz, I like having named controllers so that I can pass them to R() when generating links. Does it make it better that you can name them too? Index = get / do ... end Sent from my iCampingPhone ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Advice on strategy for maintaining state in Camping
a SQLlight database seems like the best way to go given your initial scenario of read-only Excel files, i disagree. why plumb data from Excel into SQLite and from SQLite into a web UI via several layers of Ruby code, themselves distanced from underlying datastores via ORM libraries, when you can specialized .XLS oriented tools oriented to non-coder (or quasi-coder) i dont have anything to do with Cambridge Semantics, but if i had a copy of Excel or Windows i'd check it.. http://www.cambridgesemantics.com/products/anzo_for_excel if massaging the data or filtering it one could try Refine: https://code.google.com/p/google-refine/ if it was me, i usually use xls2txt and an on-the-fly RDF (to JSON/Hash in RAM) conversion and skip the SQL or non-programmer tools which mean well but never do quite what you want (or require excessive gymnastics vs a few lines of Ruby/Haskell) http://gitorious.org/element/element/blobs/master/ruby/W/csv.rb also Camping may be *just* what you are looking for.. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
