Re: css image url's and :img problem
Can you access the image at (localhost:3301)/static/img01.gif through your browser? On 11/18/07, pedro mg [EMAIL PROTECTED] wrote: On Sat, 2007-11-17 at 21:43 -0800, John Beppu wrote: On Nov 17, 2007 8:10 PM, pedro mg [EMAIL PROTECTED] wrote: background: #33 url(img01.gif) repeat-x; url(/static/img01.gif) oh, sorry for the 2nd post. Ty John, but i tried that, and even the whole path to the images, and still no results. -- pedro mg ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Sample Code, quick simple openid auth
Cookies can be stealt. I'm protecting you against yourself :-P 2008/5/20, Bluebie, Jenna [EMAIL PROTECTED]: Sure, but if you're building an app that keeps secrets about me from me, I'd rather not use it, thank you. On 20/05/2008, at 6:01 PM, Magnus Holm wrote: Everyone can read their session, though. I can post an example which encrypts everything (don't expect it to be super-fast). On Tue, May 20, 2008 at 7:30 AM, Bluebie, Jenna [EMAIL PROTECTED] wrote: Also, here's a simple way to stop XSS dead! http://code.whytheluckystiff.net/camping/wiki/XssBeGoneWithSessions — Jenna is hoping all this will earn here some oats! Fox ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Rack, Camping 2.0++
So should I just merge/rebase everything to my master, so _why can merge it into his? Some more notes: * camping/db.rb - camping/ar.rb * camping/session.rb - camping/ar/session.rb * CookieSession - camping/session.rb The documentation and the names (Camping::Session, Camping::ARSession?) needs some fixing. I'll let the leader decide :-) On Fri, May 23, 2008 at 11:18 PM, zimbatm [EMAIL PROTECTED] wrote: 2008/5/22 _why [EMAIL PROTECTED]: Splendid! If we can say Camping, the 3K Microframework, then I think we will really have a reason to bump the big number. I'll wait for a reaction from zimbatm, but I am euphoric about these changes. Wasn't the one who codes who leads ? :) ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Rack, Camping 2.0++
I don't want to be the leader. I just want to contribute to one of the sweetest framework that exists in the Rubyverse! I'm going to contribute with what I can, and I suck at writing documentation and I have no intention to learn RDoc (ATM, maybe another day). (I still think that _why is the true leader of Camping.) On Sat, May 24, 2008 at 1:28 AM, zimbatm [EMAIL PROTECTED] wrote: 2008/5/23 Magnus Holm [EMAIL PROTECTED]: So should I just merge/rebase everything to my master, so _why can merge it into his? Some more notes: * camping/db.rb - camping/ar.rb * camping/session.rb - camping/ar/session.rb * CookieSession - camping/session.rb The documentation and the names (Camping::Session, Camping::ARSession?) needs some fixing. I'll let the leader decide :-) You are the leader now :) If I where you, I'd take some time checking the documentation generates well. Last time I checked, it was a mess. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Camping 2.0 - What's left?
I've just sent a pull-request to _why with my changes[1] and here is some things that I think needs to be done before a (possible) release: * The cookie session is named Camping::Session and is placed in camping/session.rb. Maybe this should be called Camping::CookieSession or??? * The ActiveRecord session is named Camping::ARSession and is placed in camping/ar/session.rb. Maybe it should be called Camping::AR::Session or??? * The documentation of cookie sessions is just utterly wrong. Can someone clean it up? * The documentation in camping-unabridged.rb and README are almost duplicates. camping-unabridged.rb should only contain about the differences between camping.rb and camping-unabrdiged.rb, while README should be all about Camping (IMO). We must also add that apps should be run using Rack, and The Camping Server is only for development. * The flipbook-template produces some weird output once in a while. See [2]. Anyone knows RDoc-templates? We should also include all the methods in a list, since they're spread between Base, Helpers and Controllers. And Controllers won't be documented since it has a X = in front of it (doc-ability vs size?). * Some investigating of how to use Camping with DataMapper, Sequel and Og, and if they require any glue. Should the other ORMs also have tables prefixed with the app name? * What about a little guide of how to make your app Camping 2.0 compatible? * Cleaning up the wiki to be 2.0 only? * insert your wish I'm not saying I won't do any of these things, I just want to push this code so other can contribute too. (I suck at docs + decisions). Oh, and I've included `rake ruby_diff` which will use Ruby2Ruby to translate camping.rb camping-unabridged.rb to proper Ruby and show a diff. Really useful when synchronizing the two files. camping.rb is now at 3171 bytes (77% of 4kB)! (I realize that we don't need to target all of these issues for 2.0, we must have something left for 2.1 :-) [1] http://github.com/judofyr/camping [2] http://camping.rubyforge.org/classes/Camping/H.html vs http://camping.rubyforge.org/classes/WEBrick.html --- Magnus We're missing _why in #camping Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 2.0 - What's left?
On Sun, May 25, 2008 at 4:25 PM, Julian Tarkhanov [EMAIL PROTECTED] wrote: On 25 mei 2008, at 00:25, Magnus Holm wrote: * insert your wish * Are deeply nested query arguments and tricky bits like checkbox arrays/param arrays handled properly (and in a Camping-compatible manner, AFAIK in Camping the first parameter wins as opposed to Rails) by Rack? Rack doesn't do anything special with queries ending in [] and [key], so we're cleaning it up in Base#initialize. It works with arrays and hashes, but not perfectly when they're nested. Could you write some examples of how they should be handled? Here's a helper to see what Camping does today: http://pastie.caboo.se/private/53towf4gox3di0k6c8zhw I think we could use almost the same code if we just move it out to a helper and do some recursive magic. What happens with file uploads? No idea! Maybe Christian Neukirchen can answer what Rack::Request does with it? There isn't any file-upload specific code in Camping now. * I loved Camping::H too much, don't see a big deal in wrappint the request/env hashes into it (also to avoid substantial code scavenging) It would be easier to remove Camping::H for good, but I like #method_missing for getting out the values... Unless we want to get it under the 3kB-mark, I don't think it's worth to remove it. We're far away from 4kB! ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Getting rid of the route maker
R isn't gone! Feel free to use both (and if you use R, it would not add more routes: module Camping::Controllers class Index;end class Advanced R '/(some regex';end # /advanced will NOT route to Advanced end On Tue, Jun 24, 2008 at 3:09 PM, Julik Tarkhanov [EMAIL PROTECTED] wrote: Does that mean we are losing the possinility for multiple routes per controller and such? Or should I return something magic from self.urls to make controllers function the pre-2.0 way? On Jun 24, 2008, at 1:05 PM, Magnus Holm wrote: Alright! What about releasing 2.0? I've closed a lot of tickets on the tracker, and I don't think we need more for a 2.0. There is no point of waiting anymore, IMO! ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Getting rid of the route maker
Nice! You should also go through the documentation, it's pretty bad at the moment... On Tue, Jun 24, 2008 at 5:07 PM, _why [EMAIL PROTECTED] wrote: On Tue, Jun 24, 2008 at 01:05:54PM +0200, Magnus Holm wrote: Man, that's way better than removing 135 bytes! I *love* the implementation! I have always wanted to use Method#to_proc in Camping. Alright! What about releasing 2.0? I've closed a lot of tickets on the tracker, and I don't think we need more for a 2.0. There is no point of waiting anymore, IMO! I have two things left: I need to figure out if I want to merge zimbatm's Markaby patch. And I'd like to go through Rack a bit more myself and see if I can cut down the work we're doing. Hopefully today or tomorrow, though! _why ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Troubleshooting: Camping 2.0 on CGI on a shared host
What about dropping the idea of config.ru and just create a dispatch.cgi like this? #!/usr/bin/env ruby require 'app' Rack::Handler::CGI.run(App) On Fri, Jul 11, 2008 at 7:33 AM, Eric Mill [EMAIL PROTECTED] wrote: Some progress: I put most of the code from dispatch.cgi into a config.ru, and dispatch.cgi now uses backticks to literally call '/usr/bin/env rackup'. This works, yet now calls to / redirect to /dispatch.cgi/ (this is truly the path in my browser location bar), and it messes with my routing. config.ru == Dir.chdir '/path/to/app' require 'app' App::Models::Base.establish_connection :adapter = 'sqlite3', :database = 'app.db' App.create run App dispatch.cgi #!/usr/bin/ruby ENV['GEM_PATH'] = '/path/to/gems' ENV['GEM_HOME'] = '/path/to/gems' puts `/usr/bin/env rackup` And now I am definitely giving up for the night and sleeping. Any ideas? Thanks, Eric On Fri, Jul 11, 2008 at 1:06 AM, Eric Mill [EMAIL PROTECTED] wrote: Specifically, Dreamhost. I'm trying to figure out how to get this to work the standard dispatch.cgi or dispatch.fcgi setup. I've been using the instructions that Magnus sent out when he first announced his plan for Camping 2.0, but they either no longer apply, or I'm an edge case. I've been pushing at it for a while, just to get it working on CGI, and the problem seems to be that dispatch.cgi doesn't end in .ru! Rack tries to require 'dispatch.cgi', which is no good. Here's my dispatch.cgi, with names changed to protect the innocent: == #!/usr/bin/env rackup ENV['GEM_PATH'] = '/path/to/local/gems' ENV['GEM_HOME'] = '/path/to/local/gems' ENV['FORCE_ROOT']=1.to_s Dir.chdir '/path/to/app' require 'app' App::Models::Base.establish_connection :adapter = 'sqlite3', :database = 'app.db' App.create run App = And the error trace, as reported through apache's error logs: /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require': no such file to load -- dispatch.cgi (LoadError) from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' from /usr/lib/ruby/gems/1.8/gems/rack-0.3.0/bin/rackup:92 from /usr/bin/rackup:19:in `load' from /usr/bin/rackup:19 Premature end of script headers: dispatch.cgi I'm still trying to get my head around the new Rack setup, the problem might be some simple naivete on my part. Anyone have any ideas how I can push forward? Thanks, Eric ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Troubleshooting: Camping 2.0 on CGI on a shared host
This bug is actually Apache's fault. The problem occurs when you use mod_rewrite to hide that you're using dispatch.cgi. When you use RewriteRule ^(.*)$ dispatch.cgi the following happens: * SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script which gets ran) * REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before * PATH_INFO is emptied I've also tested this on 1.5 and it has the same problem. However, if you use server/fastcgi.rb (not Rack as I've been testing with) you can set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and PATH_INFO using REQUEST_URI, which will (partly) solve the problem. Right now, we have no FORCE_ROOT in Rack, but here's a simple fix: * Change .htaccess to RewriteRule ^(.*)$ dispatch.cgi/$1 (You might need to drop to slash). * Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME (http://pastie.org/235062) This isn't really our problem, but rather Apache (which should be able to alias CGI-scripts with the correct headers). It probably won't happen, so I guess we have to add some nasty hacks into Rack. I haven't tried this on any other servers (LightTPD/Nginx), but as long as there is no URL-rewriting (I know LightTPD can do it with FastCGI) it's probably no problem (maybe not even with, if it's smart enough). Here is a simple app which shows @env (and works on both 1.5 and 2.0): http://pastie.org/235078. It would be great if you could test it on different setups and see which requires special treatment. Check out the Rack-spec for how the variables should be set: http://rack.rubyforge.org/doc/files/SPEC.html On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill [EMAIL PROTECTED] wrote: Bluebie -- I tried doing this with FastCGI with the same settings (changed .htaccess to point to dispatch.fcgi, changed dispatch file to use Rack::Handler::FastCGI.run, got the exact same results. FastCGI will also suffer from these bugs. -- Eric On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna [EMAIL PROTECTED] wrote: We are talking about cgi here, not fast cgi. Specifically CGI's interactions with mod_rewrite in apache. ___ 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 -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Troubleshooting: Camping 2.0 on CGI on a shared host
Simply replace Testing with TestingFixed in dispatch.cgi:11 and dispatch.fcgi:13 to see the diffenrence :-) On Wed, Jul 16, 2008 at 11:28 PM, Eric Mill [EMAIL PROTECTED] wrote: Magnus, this is terrific information, thank you for looking into this. I'm trying to follow your example - you use ApacheFixer to make a TestingFixed class, but never use that class anywhere else. Do you mean for the lines in dispatch.* to use TestingFixed instead of Testing? I'm trying to use this to resolve my problems as we speak, Eric On Wed, Jul 16, 2008 at 5:08 PM, Magnus Holm [EMAIL PROTECTED] wrote: This bug is actually Apache's fault. The problem occurs when you use mod_rewrite to hide that you're using dispatch.cgi. When you use RewriteRule ^(.*)$ dispatch.cgi the following happens: * SCRIPT_NAME is set to /dispatch.cgi (since that's the actual script which gets ran) * REDIRECT_SCRIPT_NAME is set to whatever SCRIPT_NAME was before * PATH_INFO is emptied I've also tested this on 1.5 and it has the same problem. However, if you use server/fastcgi.rb (not Rack as I've been testing with) you can set the ENV['FORCE_ROOT'] to 1 and it will re-set SCRIPT_NAME and PATH_INFO using REQUEST_URI, which will (partly) solve the problem. Right now, we have no FORCE_ROOT in Rack, but here's a simple fix: * Change .htaccess to RewriteRule ^(.*)$ dispatch.cgi/$1 (You might need to drop to slash). * Add a middleware which sets SCRIPT_NAME to REDIRECT_SCRIPT_NAME (http://pastie.org/235062) This isn't really our problem, but rather Apache (which should be able to alias CGI-scripts with the correct headers). It probably won't happen, so I guess we have to add some nasty hacks into Rack. I haven't tried this on any other servers (LightTPD/Nginx), but as long as there is no URL-rewriting (I know LightTPD can do it with FastCGI) it's probably no problem (maybe not even with, if it's smart enough). Here is a simple app which shows @env (and works on both 1.5 and 2.0): http://pastie.org/235078. It would be great if you could test it on different setups and see which requires special treatment. Check out the Rack-spec for how the variables should be set: http://rack.rubyforge.org/doc/files/SPEC.html On Wed, Jul 16, 2008 at 5:07 PM, Eric Mill [EMAIL PROTECTED] wrote: Bluebie -- I tried doing this with FastCGI with the same settings (changed .htaccess to point to dispatch.fcgi, changed dispatch file to use Rack::Handler::FastCGI.run, got the exact same results. FastCGI will also suffer from these bugs. -- Eric On Mon, Jul 14, 2008 at 7:40 PM, Bluebie, Jenna [EMAIL PROTECTED] wrote: We are talking about cgi here, not fast cgi. Specifically CGI's interactions with mod_rewrite in apache. ___ 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 -- 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 -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: File uploads
I'm playing with Mash (http://mash-hash.rubyforge.org/) which has some really nifty stuff. Here's the branch: http://github.com/judofyr/camping/tree/mash. It requires 0.0.6 (which is only on GitHUb), but will work with 0.0.3 if you drop the latest patch. I don't know if it's worth another dependency; maybe zimbatm's patch is better. On Tue, Jul 22, 2008 at 4:40 AM, Bluebie, Jenna [EMAIL PROTECTED] wrote: NoMethodError undefined method `tempfile' for # That sure is odd... I guess in Camping 2.0, uploads are not a Camping::H. Can we please change Camping::H to output ::H's instead of the original value when the original value is_a?(::H) That be good. Recursive yumminess. Doesn't solve hashes in arrays, but is nice for this and some other things like playing with JSON. :) Looks like to do that, we'd need to override Hash#fetch, and maybe Hash#[] and stuff... complex, maybe beyond camping scope. Still, I really think for consistency file upload hashes in the @input should be ::H's. Maybe not put the functionality in ::H, maybe some processing specific to @input. Coming right down to it, I'm thinking about putting the functionality in the actual Hash class why don't we do that normally? does it cause problems with some libraries? ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: File uploads
They havent't changed the method. They probabely should. When you run Mash.new it transforms all keys to strings (and turns Hash'es to Mash'es), Mash[] doesn't do anything like that. And it isn't Mash[:test = 1, :cool = 2] which raises errors, it's when you call #inspect on it (it tries to sort all the keys). On Wed, Jul 23, 2008 at 4:49 PM, zimbatm [EMAIL PROTECTED] wrote: This is curious... why would they change that behavior ? 2008/7/23 Magnus Holm [EMAIL PROTECTED]: Mash[] doesn't work exactly as wanted (if you give it symbols): Mash[:test = 1] #= Mash test=nil Mash[:test = 1, :cool = 2] #= Raises error So we have to alias self[] to self.new... On Wed, Jul 23, 2008 at 10:10 AM, zimbatm [EMAIL PROTECTED] wrote: Yum. Did you try just setting YourApp::H = Mash ? If it works like this out of the box then we can keep the simpler solution and provide a recipe to work with mash ? 2008/7/23 Magnus Holm [EMAIL PROTECTED]: I'm playing with Mash (http://mash-hash.rubyforge.org/) which has some really nifty stuff. Here's the branch: http://github.com/judofyr/camping/tree/mash. It requires 0.0.6 (which is only on GitHUb), but will work with 0.0.3 if you drop the latest patch. I don't know if it's worth another dependency; maybe zimbatm's patch is better. On Tue, Jul 22, 2008 at 4:40 AM, Bluebie, Jenna [EMAIL PROTECTED] wrote: NoMethodError undefined method `tempfile' for # That sure is odd... I guess in Camping 2.0, uploads are not a Camping::H. Can we please change Camping::H to output ::H's instead of the original value when the original value is_a?(::H) That be good. Recursive yumminess. Doesn't solve hashes in arrays, but is nice for this and some other things like playing with JSON. :) Looks like to do that, we'd need to override Hash#fetch, and maybe Hash#[] and stuff... complex, maybe beyond camping scope. Still, I really think for consistency file upload hashes in the @input should be ::H's. Maybe not put the functionality in ::H, maybe some processing specific to @input. Coming right down to it, I'm thinking about putting the functionality in the actual Hash class why don't we do that normally? does it cause problems with some libraries? ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- 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 -- 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 -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: @state not being saved
For some reason, AR 1.2 can't save serialized data. At least in the
tests I have done with Camping's Session model.
For now we have to stick with 2.0.2, but I know the problem has been reported.
2008/7/29, Eric Mill [EMAIL PROTECTED]:
Is it that AR 2.1 only has problems in conjunction with Camping? Or
is table-based session support totally broken in Rails 2.1 right now?
-- Eric
On Tue, Jul 29, 2008 at 1:10 AM, Alpha Chen [EMAIL PROTECTED] wrote:
This happened to me... I saw an email on this list earlier about AR
2.1.0 having problems, and reverting back to 2.0.2 got session support
working again.
On the command line:
$ gem install --version '=2.0.2' activerecord
In Camping:
gem 'activerecord', '=2.0.2'
Alpha
On Mon, Jul 28, 2008 at 9:15 PM, Eric Mill [EMAIL PROTECTED] wrote:
Is this with Camping 1.5 or Camping 2.0?
-- Eric
On Mon, Jul 28, 2008 at 6:05 PM, Fred Phillips
[EMAIL PROTECTED] wrote:
I have a sqlite3 database with the sessions table and schema set up
correctly. Sessions are created fine and put in the table, the cookie
is set with the correct hash and the hash is found again but when
using @state the values aren't updated in the table.
I know that Session::service is called and the contents of the record
are put into session like so:
#Camping::Models::Session id: 1, hashid:
iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4, created_at: 2008-07-24 17:11:43,
ivars: {}
I do @state.user = 5, then it then gets as far as making session look
like this:
#Camping::Models::Session id: 1, hashid:
iSCMSIzV7ITsRTr0UMA8Gko3LEnY3bw4, created_at: 2008-07-24 17:11:43,
ivars: {TLCMS={user=5}}
But then session.save doesn't write to the table, and doesn't throw an
error (session.save! doesn't either). Can anyone see what is going
wrong?
FWIW I'm using FastCGI
--
Fred O. Phillips
http://fophillips.org
BBC7 7572 755F 83E0 3209 504A E4F7 874F 1545 9D41
___
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
___
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
--
Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Camping::Apps returns!
Camping::Apps is back! I don't know the *exact* reason it was being removed,
but now it's a monkey-patched array which at least doesn't leak memory when
using together with the reloader (were there more problems with this?).
I really think we need this, since there's no guaranty that only
Camping-apps will have a class-method called #goes and
Object.constants.map{|c|Object.const_get(c)} also caused a really weird
error on Rubinus a while ago (I haven't checked if this still applies).
Anyway, I think it's worth the bytes.
I've pushed it to my experimental-branch[1] together with some other,
semi-experimental (see [2]) and byte-saving patches.
Can anyone who knows why it got pulled out, see if this version is safe?
[1] http://bit.ly/judofyr-excamping
[2] Getting rid of the old #meta_def and instead using modules:
http://bit.ly/extend-not-define-on-metaclass
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping::Apps returns!
That's why I have monkey-patched it:
Apps = [].instance_eval do
def (i)
delete_if { |f| f.to_s == i.to_s}
super
end
self
end
Ex1 = Class.new
Apps Ex1 # = [Ex1]
Object.send(:remove_const, :Ex1)
Ex1 = Class.new
Apps Ex1 # = [Ex1] # the old one has been deleted.
Yes, I realize we could make some changes in camping/reloader.rb,
but I think this is more intuitive and do got lot's of spare bytes...
On Fri, Aug 29, 2008 at 2:28 AM, zimbatm [EMAIL PROTECTED] wrote:
Now I remember, there is a quirk. Make sure to remove the old app in
the array when reloading the app in the Camping::Reloader.
Cheers,
zimbatm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
--
Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Let's get this done, please :-)
Okey. Today I cherry-picked some commits from zimbatm, Bluebie and my experimental-branch so we can get a bit closer to 2.0: - Making Camping::ARSession work with AR 2.1 - d1db4f3c50815c93e370b696fb5b6c814bd1a7c4http://github.com/judofyr/camping/commit/d1db4f3c50815c93e370b696fb5b6c814bd1a7c4 - Removing Tempfile from require (zimbatm) - 26cd51545fcca05c67e952f09076a360cb7f554bhttp://github.com/judofyr/camping/commit/26cd51545fcca05c67e952f09076a360cb7f554b - Improving Markaby-speed (zimbatm) - 30b066e233b4777c63c29dde4d32420239abc9a4http://github.com/judofyr/camping/commit/30b066e233b4777c63c29dde4d32420239abc9a4 - Refactoring of Camping::Session (Bluebie) - 0373aa306979d9c962d74f5ddc4fbf8c5b68eb30http://github.com/judofyr/camping/commit/0373aa306979d9c962d74f5ddc4fbf8c5b68eb30 and bb5e3bf6f0211ac688d03b5b1afb50439e2baa81http://github.com/judofyr/camping/commit/bb5e3bf6f0211ac688d03b5b1afb50439e2baa81 - Switching to HMAC - 6acd33768bc57b5aa6522c69ec95eff9624d1307http://github.com/judofyr/camping/commit/6acd33768bc57b5aa6522c69ec95eff9624d1307 and http://en.wikipedia.org/wiki/HMAC#Design_Principles - Earning some bytes - c380870c464d041d54085d6d8c2addadaa9a060chttp://github.com/judofyr/camping/commit/c380870c464d041d54085d6d8c2addadaa9a060c - Cleaning up reloader.rb - 214fbe6613608f17b92aac0754a45bd4c2aed2b1http://github.com/judofyr/camping/commit/214fbe6613608f17b92aac0754a45bd4c2aed2b1 - Camping::Apps returns - a4074fa6af5e0ba5889bda6bb33128e195e61361http://github.com/judofyr/camping/commit/a4074fa6af5e0ba5889bda6bb33128e195e61361 and eb759146527903578c914e46cc949acd22da4a4chttp://github.com/judofyr/camping/commit/eb759146527903578c914e46cc949acd22da4a4c - Don't make sessions depend on USER_AGENT - 205983ad09d255233590a1c9c6c9e7997d384a61http://github.com/judofyr/camping/commit/205983ad09d255233590a1c9c6c9e7997d384a61 I think all of these are pretty important, but I'm sure there are many other commits on other repos which should be included too! Shout out if there's something you really need for 2.0 :-) Documentation is probably what's missing for a release. Both cleaning up some part in the current docs and write some sort of how-to-switch-to-2.0. And the wiki needs some work too! And _why: we're actually waiting for you. I know you've given this project to the community, but you can't just disappear like that :-( -- Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Hum... What's wrong with me ?
Huh? I just pasted that code, ran camping test.rb and it worked just like expected: Camping say Hello World!... -- Magnus Holm On Wed, Nov 12, 2008 at 6:29 PM, Eric Mill [EMAIL PROTECTED] wrote: You want def get render :index, :hello = Hello World! end in your view. Unlike Rails, instance variables aren't magically carried along from Controller to View. -- Eric On Wed, Nov 12, 2008 at 12:03 PM, Gregoire LEJEUNE [EMAIL PROTECTED] wrote: Hi Campers, i just download and install the last version from http://github.com/why/camping/tree/master Then, when i test with this piece of code : require 'camping' Camping.goes :Test module Test::Controllers class Index R '/' def get @hello = Hello World! render :index end end end module Test::Views def layout html do body do self yield end end end def index p Camping say [EMAIL PROTECTED] end end I just see Camping say not Camping say Hello World!... So what's wrong ? ___ 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 ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Mosquito for bug-free Camping now works with v.2
Awesome! I've already thought of doing it myself, but I'm way to lazy! Very nice, indeed! Magnus Holm On Sun, Nov 16, 2008 at 20:56, julik [EMAIL PROTECTED] wrote: Hello everyone! Just a quick heads-up - ppplz willing to use Mosquito for testing Camping 2 can track my Mosquito trunk on github. I hope for a rubyforge release soon. Camping 1.5 compat stays the same. http://github.com/julik/mosquito/tree/master ___ 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: My Camping clone has broken the 4K barrier. ;-)
Well done, but I thought Perl would do better... //Magnus On 4. des.. 2008, at 10.37, John Beppu [EMAIL PROTECTED] wrote: Behold! http://gist.github.com/31363 4004 bytes! The non-obfuscated version can be found at: http://github.com/beppu/squatting/tree/master --beppu PS: I'm not going to try for 3K. I'm happy that I was even able to reach 4K, and that satisfaction is enough. ___ 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
H with indifferent access
Camping::H hasn't longer indiffenrent access:
h = Camping::H.new
h.title = Sweet!
h[:title] != h[title]
Should we (1) don't make it indifferent at all, but rather say you should
always use method_missing (2) add indifferent access?
Here is one such implementation in 86 bytes, in case we want it:
class H Hash
i='def []!(k,v)Symbol===k ?self[k.to_s]!v:super end;'
eval i.tr('!','=')+i.tr('!,v','')
end
//Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Getting ready for release
Okay, boys and girls: Let's get ready for the release! First of all, in case you missed it: I now have full access to the RubyForge project and why's repo at GitHub. I guess this makes me some sort of a project leader, but don't worry: The community will still maintain Camping. I will continue pushing to my own repo and will ask the mailing list before merging any big changes. Everything will still be maintained through this mailing list. I'm not going to work on any new features (not many, but I still have some ideas left); just preparing for this release. This means (in no specific order): * Update the documentation * Update the GitHub wiki * Update the changelog * Clean up the examples * Choose a bug tracker * Write an announcement * Fix any bugs discovered while we're cleaning up I'm working on the documentation at the moment. I'm also going to take some of the essential stuff that was on the old wiki and put it right into the RDoc. The RDoc tempate (flipbook) is currently on hold until Eric Hodel finishes his awesome refactoring of RDoc. Then I'll convert it to the new template system and probably add search. When it comes to bug tracking, I really like ditz (http://ditz.rubyforge.org) + sheila (written in Camping; example: http://masanjin.net:9000/). What do you think? 2.0 will then be release, 2.0.x for minor fixes, 2.0.x.REV for bleeding edge (from my gem server) and 2.1 for completely new featues. Any comments or thoughts? Anyone else who want to do some of these things? Remember, I'm not _why ;-) //Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Rack::Lint::LintError with latest camping and rack
Well, this issue is actually solved in the latest master :-) Maybe it's time to release this thing... I'm way to lazy :/ //Magnus Holm On Sun, Mar 29, 2009 at 20:45, Julik Tarkhanov julian.tarkha...@gmail.comwrote: On 29 Mar 2009, at 07:06, Garret Buell wrote: Would we gain anything by making the switch? Everybody would gain. Content-length is a requirement of the latest Rack spec, presumaby to allow for easier caching, and you have to set it _unless_ you send out chunked - but then you have to state it in the headers. -- Julik Tarkhanov m...@julik.nl ___ 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: camping-test error: undefined method `fixtures'
I've pushed out a fix now. Could you verify it? //Magnus Holm On Sat, May 2, 2009 at 22:04, Mikkel Refsgaard Bech mik...@refsgaardbech.dk wrote: Hi Trying to use camping-test with my camping app but I get an error: undefined method `fixtures' The error can be reproduced by using this empty app (your_app.rb): require 'camping' Camping.goes :YourApp module Steps module Models end module Controllers end module Views end end And running the test from camping-test: http://github.com/judofyr/camping-test/tree/master I just run: # ruby test_your_app.rb test_your_app.rb:7: undefined method `fixtures' for YourApp::Tests::TestSomeBasicStuff:Class (NoMethodError) camping-1.9.300 activesupport-2.3.2 activerecord-2.3.2 camping-test Is anyone using this successfully? Regards, Mikkel ___ 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: camping-test error: undefined method `fixtures'
That sounds like a good idea. I've figured out one way to do cookies, but still need to find a way to handle sessions. Pushing later when I've come up with something :-) //Magnus Holm On Wed, May 6, 2009 at 22:28, Mikkel Refsgaard Bech mik...@refsgaardbech.dk wrote: On 05/05/2009, at 22.49, Magnus Holm wrote: Oh crap. Did that get commited? I was just testing if the memory-database had anything to do with it and forgot to change it back later. Pushing a fix tomorrow :-) Sweet. One other thing, I can't figure out how to input some @state before I call get/post/etc... I need to test my app while I'm logged in, which just means that some user ID is set in @state, is that possible? E.g.: test i can get my secret page when I am logged id do @state.user_id = 1 get '/secretpage' assert_response :ok end Thanks, Mikkel //Magnus Holm On Tue, May 5, 2009 at 22:40, Mikkel Refsgaard Bech mik...@refsgaardbech.dk wrote: On 03/05/2009, at 21.34, Magnus Holm wrote: I've pushed out a fix now. Could you verify it? Works fine, thank you. Any reason for not using the :memory: database any longer? Regards, Mikkel ___ 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 ___ 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: sqlite3 connection problem
In order to create the necessary tables you'll have to run Blogtiny::Models.create_schema. The prefered way is define a create-method like this: def Blogtiny.create Blogtiny::Models.create_schema end All servers or setups using Camping should then call Blogtiny.create on startup after the app is loaded (so yes, you still have to call this yourself). //Magnus Holm On Mon, May 18, 2009 at 16:35, Dave Everitt dever...@innotts.co.uk wrote: Many attempts (3 days now) to get even a single sqlite3 example running... I've got a little further by creating the database file from the sqlite3 shell. Now the app connects to an empty db and I get: ActiveRecord::StatementInvalid SQLite3::SQLException: no such table: blogtiny_posts: SELECT * FROM blogtiny_posts : I am I right to expect that Camping will create the necessary tables when run as CGI? Weird. I've used sqlite3 on the SQLite which follows with 10.4 earlier. Could you paste the code you use to connect to the database? //Magnus Holm I'm running it as a cgi app (no problem with Camping itself, just any apps that need sqlite3) under Apache, OS X 10.4.11... sqlite 3.1.3 (the one that comes with the system and OS X uses)? Dave Everitt ___ 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: using ActiveRecord::Validations::ClassMethods
I'm a little rusty on AR at the moment, but I think it looks something like this: In the controller: if @user.valid? # everything is fine else # ops! @user.errors contains the errors end //Magnus Holm On Wed, May 20, 2009 at 19:43, David Susco dsu...@gmail.com wrote: Can ActiveRecord::Validations::ClassMethods be used to provide feedback to the user? I noticed the tepee example uses validates_uniqueness_of . If the title isn't unique however nothing is written and the user is never notified. Does anyone have an example or two of how I could go about informing the user that the title they entered was not unique and they need to enter another? -- Dave ___ 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: Camping tutorials for education?
2. Stable version The current version is 1.5 and is available from RubyForge. This is however a *really* old release, and there have been plenty of bug fixes in the repo. There's a 1.5.180 from _why's gem server which fixes some of them. The 1.9-version I have at gems.judofyr.net is just a rake gem ran from the latest why/camping (once in a while). This should be stable enough. In fact, as soon as I finish this little cleanup of the documentation (and get some more feedback from you guys) I will most probably release it as 2.0. (1.9 is the preview release of 2.0) 3. Rack Camping started depending on Rack when the work on 2.0 started. Right now, Camping uses Rack::Utils so it's currently not possible to run Camping without Rack. This should hopefully not cause any problems. 4. Servers At the moment I think the easiest solution is Phusion Passenger, which is an Apache or Nginx modules which can serve any Rack app. 5. Documentation Yes, we really need some documentation! This is actually what's blocking the 2.0 release. I have some suggestions (will try to post these as soon as possible, aka few hours). I'm not very god writing documentation, so if you want to help out we can agree on how to organize it. 6. Picnic While I haven't been to take a proper look at it, I think it's a very cool idea. Keep up the good work :-) //Magnus Holm On Tue, Jun 9, 2009 at 12:35, Dave Everitt dever...@innotts.co.uk wrote: I'm planning to use Camping to teach the basics of frameworks, and encourage new arrivals from web design to take up Ruby instead of (say) defaulting to PHP. To do this, I need a foolproof set of instructions for both the technicians (who have to install on all the studio machines) and the students. To go further, I'd like to get an opinion on the following: 1. SQLIte/ActiveRecord I've had some trouble getting Camping to write to an SQLite database as it should (post 'sqlite3 connection problem' has the details). To prepare instructions, I need to understand exactly why this is happening (in case it happens on a student's machine), so I'll persist and get it solved, somehow. 2. Obtaining the definitive current stable version What's the consensus on the definitive stable version? And where is it? The bleeding edge download from http://gems.judofyr.net/ is at 1.9.316, yet Picnic includes Camping 2.0 (which I thought didn't exist yet), but if I 'gem update' my 1.5 version, Camping remains at 1.5? I hope you can understand the confusion (on behalf of my future students) here. 3. Rack At which version (see [2]) did Camping start depending on Rack (as stated at: http://github.com/why/camping/tree/master)? Just out of interest, is it still possible to run a Camping app without it? 4. Comparing servers Is there any consensus on running Camping with: Apache, Mongrel, fast_cgi, plain old CGI, etc.? Which is the most efficient, future-proof, quickest/easiest to set up, and is there any information that charts the methods and differences? In a production environment, the URLs are obviously an issue here, so some mod_rewrite (or -like) examples would also be good. With all this I also want to lower the entry bar to Camping for new users by attempting some nice, simple documentation just to get people going, which is the thing I've been struggling to do myself. Dave ___ 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
The D-word
Oh, yes. Let's (once again) try to clean the documentation up a bit :-) I have no facts behind me, but I assume there would be two kinds of people who would like to browse camping.rubyforge.org: 1. Beginners who want to know what it's all about, how to get started and how to get help. 2. Campers who don't quite remember which method to use, or where the mailing-list was located, or how you did X etc. So here's a little proposal: What if we split the documentation into three parts? - README.txt should be the first you see and should contain basic info and links. - API-reference. A one-page reference to the whole Camping API which gives you short descriptions/explanations and might also give a link to the book (see below) for more detailed thoughts. - A book or tutorial which guides the user from A-Z, starting with installation and how to use The Camping Server, through basic MVC and HTTP/REST to how to use service-overrides or middlewares. It would be really nice if this could be a clean, short and concise guide to both Ruby and web development. What'd you think? What do you miss most from the current (almost non-existing) documentation? //Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: The D-word
Oh, that would be very nice! Right now there is an example at camping.rubyforge.org showing a blog skeleton (with controllers, models and views). It might be better to rather have a tiny, fully functional one (to get the feel of Camping), and a link to blog.rb (which should be simplified even more, and actually work). The book could then take it from there and slightly expand into the blog.rb (or maybe even totally different; we should at least end up with something) You know, I remember stumbling on Camping after trying out Rails, and it was a horrible feeling ending up at page 3 of the tutorial (on the old wiki) where a giant TODO screamed at me. I think many newcomers would have a look at alternatives to Rails, and it would be great if we could guide them not only through Camping, but also on the way you have to think when you're developing on the web. Without boring them too much. At the same time, there will probably be some Rubyists/webdevs who just want to learn about Camping too. What if we start easy with lots of code and introduce them to Camping, then (if we bother to) more in-depth about the web, HTTP, GET/POST/PUT/DELETE, limitations? You could follow the book right through and will end up with basic understanding of the web, or just skip after the quickstart (and three months later, after you've experimented a bit, you take the trouble to trouble to read the rest). Maybe book is the wrong word for this too. A book is so formal and strict. This should be light, simple and something you just can dive right into whenever you want. Let's keep it simple and precise, yet informal! The API as a cheat is a great idea too, let's not forget that :-) When it comes to the dependency on Rack, I'm not that worried. You almost can't do any webdev in Ruby today without meeting on Rack. And you only need to have the Rack-library somewhere where Camping can find it (just download and unzip it to vendor/rack for instance), even though using the gem is preferred. Anyone else want to chime in? (Yes, you do!) I currently have some RDoc templates which renders the book/readme/api. It definitely needs to be cleaned up a lot, but I guess I can push it out at a branch when I get back to my computer. //Magnus Holm On Tue, Jun 9, 2009 at 19:30, Dave Everitt dever...@innotts.co.uk wrote: I'm quite good at clear an understandable English (and editing the work of others) so would be glad to help make the documentation as usable as possible. I reckon we need two starting examples somewhere (a download link in the README?): 1. 'It worked - you are now Camping!' (without a DB); 2. a foolproof version of the minimal blog. I think you're dead right about the two kinds of users and three parts of documentation. As for the book (WebDev with Ruby, using Camping as an example?), it would be good to follow the spirit of Camping and keep it under... well, not 4k, but you get the point. The Camping philosophy needs to pervade the docs too - there's cultural capital in it, which could become a real attraction. I also suggest putting up the '1-page API' on 'cheat'. I have one slight concern for those on shared hosting: that it's 'not possible to run Camping without Rack'. It might take some thinking about how best to do this without root (or how to ask your provider to add the necessary). Many prospective Campers won't change servers just to try something out. Not necessarily an obstacle, but it needs some thought (a cleaned up pre-rack version? Camping 'classic'?). DaveE Oh, yes. Let's (once again) try to clean the documentation up a bit :-) I have no facts behind me, but I assume there would be two kinds of people who would like to browse camping.rubyforge.org: 1. Beginners who want to know what it's all about, how to get started and how to get help. 2. Campers who don't quite remember which method to use, or where the mailing-list was located, or how you did X etc. So here's a little proposal: What if we split the documentation into three parts? - README.txt should be the first you see and should contain basic info and links. - API-reference. A one-page reference to the whole Camping API which gives you short descriptions/explanations and might also give a link to the book (see below) for more detailed thoughts. - A book or tutorial which guides the user from A-Z, starting with installation and how to use The Camping Server, through basic MVC and HTTP/REST to how to use service-overrides or middlewares. It would be really nice if this could be a clean, short and concise guide to both Ruby and web development. What'd you think? What do you miss most from the current (almost non-existing) documentation? ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list ___ Camping-list mailing list Camping-list@rubyforge.org http
Re: Release?
Oh, sorry. I totally forgot about this. Are we absolutely sure that 1.5.180 is stable enough to be pushed out to Rubyforge? //Magnus Holm On Tue, Feb 10, 2009 at 19:24, Julik Tarkhanov julian.tarkha...@gmail.comwrote: On Feb 10, 2009, at 8:41 AM, Magnus Holm wrote: Yes, we should release 2.0 soon... Meanwhile you can always download 2.0 using my repo: gem install camping --source http://gems.judofyr.net/ I can, but people who might need my apps can't and won't look for non-official gem servers.Is there a possibility for someone to push the solidified, old-school 1.5.180 to Rubyforge? Before 2.0 is released? It's 2 minutes work, seriously... -- Julik Tarkhanov m...@julik.nl ___ 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: Release?
Totally right :-) It's released now... //Magnus Holm On Thu, Jun 11, 2009 at 01:12, Julik Tarkhanov julian.tarkha...@gmail.comwrote: On 10 Jun 2009, at 23:49, Magnus Holm wrote: Oh, sorry. I totally forgot about this. Are we absolutely sure that 1.5.180 is stable enough to be pushed out to Rubyforge? For about a year I think, and if not it can be followed by 1.5.181 right? -- Julik Tarkhanov m...@julik.nl ___ 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: Camping sessions issue (and fix?) when mounting multiple apps
Wow, great catch! This is definitely a bug. I guess this should go to
GitHub issues, yes.
This is actually an issue where Camping and Rack::Session::Cookie fight:
At the first request, sessions.state is set in ::Cookie after Camping
has done its magic.
At the second request, Camping loads @state from @env['rack.state'],
the app changes the session, but @cookie['sessions.state'] stays
intact. Camping's #to_a then sets the cookies again in the response:
@cookies.each do |k, v|
v = {:value = v, :path = self / /} if String === v
r.set_cookie(k, v)
end
Which means that it sets a sessions.state-cookie at /sessions/. Then
::Cookies kicks in and figures out that the sessions have changed and
sets a new cookie, but this time at /. (This also has the effect that
Camping copies all the cookies at / into /sessions/)
At the third request, Rack chooses cookies such that those with more
specific Path attributes precede those with less specific, and the
cookie at /sessions/ wins.
Your fix won't unfornately work because @root is only available inside
a request/controller.
I think we need to do two things:
* Make sure Camping only sets cookies when they've changed.
* Figure out a way to set :path to SCRIPT_NAME. If so, this should
only be an option, as you might also want to mount two apps and have
them share the sessions (aka :path = '/').
I'm not quite sure how we should add that option, though. We could
switch Camping::Session to be a middleware, but this means all apps
will have to change include Camping::Session to use
Camping::Session. It's maybe not such a big deal? We should at least
do these kind of changes *before* the release of 2.0.
Some examples:
# Middleware
use Camping::Session, :secret = foo, :shared = true
# Subclass
include Camping::Session::Shared
secret foo
# New method
include Camping::Session
secret foo
shared_cookie!
# Merge #secret and #shared_cookie! together
include Camping::Session
session_options :secret = foo, :shared = true
I think I actually prefer the middleware-version. It's short and
concise and can be extended with more options if needed.
What do you think?
//Magnus Holm
On Sun, Oct 18, 2009 at 19:59, Jonathan Hickford
jonathan.hickford+camp...@gmail.com wrote:
Hi all,
Not sure where best to raise this (github issues?) but I'm seeing an
issue with the cookie sessions in camping 2.0 using rack. If I mount
an app such as the example blog or the sessions test app at any url
that is not the root session information is lost in some cases. Same
thing happens if I use the built in Camping server.
For example if I mount the blog app using rackup at '/blog' I'm unable
to log in. If I mount the sessions test app the information added on
the second page is lost when it reaches page three. Looking at the
cookies in the browser I can see two state cookies set with the paths
'/' and '/blog/'.
I'm guessing this is to do with Rack::Session::Cookie in session.rb,
which will default to use :path = '/' in all cases. If I explicitly
add :path = '/blog/' there it starts working as expected. Some more
detailed outputs here (this will run from /test)
http://pastebin.com/m6c13a4aa
Is that me doing something crazy there (I'm not expert!) or is that a
bug? If that's an issue I think the below change to session.rb fixes
it, passing in the apps @root into the path Rack's session cookie
middleware. I can push that somewhere if we reckon that's a fix?
- app.use Rack::Session::Cookie, :key = key, :secret = secret
+ app.use Rack::Session::Cookie, :key = key, :secret = secret, :path =
@root
Regards,
Jon
___
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: Camping book
Thanks for bringing this up again! I've pushed out what I have so far, but not your latest suggestions (you had some more in an earlier mail, right?) If you have a Github account I can give you (and anyone else who wants to contribute) push-access. I'm a little busy at the moment, but I'll try to fix it as soon as possible. //Magnus Holm On Mon, Nov 2, 2009 at 01:22, Dave Everitt dever...@innotts.co.uk wrote: I added some basic material to the GitHub Camping Wiki (new pages): http://wiki.github.com/camping/camping ...because I'm starting with a vanilla OS X Leopard install (new MacBook) and - finally - Camping 1.9, and I thought it would be a good test run to go through the setup and tutorial process in the 'Camping book': http://stuff.judofyr.net/camping-docs/book/02_getting_started.html to find any gotchas. Only one (in my setup) - on 'Wrapping it up', in the Controllers: class Pages needs the explicit class Pages R '/' to show the pages... anyone not have the same issue? Thinking about existing stuff, some time ago Magnus wrote: As for the documentation ideas, I've already implemented the templates in RDoc, so rake docs builds all the three parts (the book is simply files in the book directory). I still need to make a way to link book chapters from the reference, but at least it's working. A Camping app can be useful when you want to edit it, so you don't need to run the rake task all the time. The book dir on GitHub doesn't have all the current content found at: http://stuff.judofyr.net/camping-docs/book/ or in the Camping install (unless I'm daft, which is possible) so where can the current book files be obtained? I guess we could also implement it as a wiki, which might be better. Then we can't have it on camping.rubyforge.org (unless we can change the DNS-settings) though since it only allows static files. What do you think? I prefer having everything in files, and I think those who really want to contribute to the book wouldn't mind a git clone... I don't think there was a response at the time Magnus wrote this, so (given whywentcamping.com, which would be a separate exercise): ideas, opinions, anyone? Be really good to have camping.rubyforge.org updated, and I'm ready to pitch in, but how to start? Dave Everitt ___ 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: is there a way to configure line breaks in markaby output?
I think this should do it: Camping.goes :Nuts Nuts::Mab.set(:indent, 2) You should probably only use it in development, because I think it's pretty slow. //Magnus Holm On Mon, Nov 2, 2009 at 18:57, David Susco dsu...@gmail.com wrote: Hi all, Instead of having the following: def index h1 'My Site' p 'Welcome to my site!' end output this: h1My Site/h1pWelcome to my site!/p Is there anyway that I can configure Markaby to add line breaks between block elements so I'd get something like this: h1My Site/h1 pWelcome to my site!/p Obviously it makes no difference to the browser, it would just make it easier on me when debugging and testing. -- Dave ___ 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: Camping book
You're now added as a contributor. Feel free to push/commit at will, but if it involves any larger refactorings/changes, I think it's better if you fork off so we can discuss it a bit. If you're not quite sure where to push though, just push it to camping/camping. We can always revert it later if needed :-) //Magnus Holm On Thu, Nov 5, 2009 at 17:50, Dave Everitt dever...@innotts.co.uk wrote: Okay. After 3-4 intensive days I now know Git well enough to go. Today I cloned the camping repo and grepped for the issues I spotted before but it seems they're fixed. So only corrected a minor typo in README :-) Will push (with anything else I notice) when access granted - Dave E. Magnus - I did make some earlier suggestions/edits and would be happy to implement them. I'm a sad and rather newbie (still working through the O'Reilly Git book) GitHub lurker (with no repos yet: http://github.com/DaveEveritt) so let me know when you're ready and I'll start work - Dave E. Thanks for bringing this up again! I've pushed out what I have so far, but not your latest suggestions (you had some more in an earlier mail, right?) If you have a Github account I can give you (and anyone else who wants to contribute) push-access. I'm a little busy at the moment, but I'll try to fix it as soon as possible. ___ 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: Created a small instrumentation NewRelic plugin for Camping controllers
Excellent, I'll definitely check it out when I come home (writing this on a crappy Sony Ericsson while it's -20C outside). Yes, there are more cool things about Camping then the 4k (or 3k at the moment). Hit me up at #camping @ irc.freenode.net if there still is something that's unclear. I think I understand the code, but hey, with camping.rb you never know. -- Happy new year to all of you! 2009/12/31, Philippe Monnet r...@monnet-usa.com: After a bit over a day of both looking at the way NewRelic implemented their plugin for Rack and Sinatra, as well as digging deep in the core Camping code of the service and M methods, I managed to get something working. See http://github.com/techarch/rpm/blob/master/lib/new_relic/agent/instrumentation/camping.rb It took me many tests to understand that the M method actually include some of the Camping modules in the controller classes. I have been reading the entire framework back to back a bunch of times and I keep being amazed at the overall design. There are so many Rubyisms to be learned from the code. Let me know if you end up using the plugin and if there are ways to improve it. If you are using Heroku you should definitely give NewRelic a try since the Bronze edition comes for free. Philippe -- //Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Created a small instrumentation NewRelic plugin for Camping controllers
Wouldn't it be possible to simply use http://pastie.textmate.org/private/8bnszgdfkkgdlorzncgnww? //Magnus Holm On Thu, Dec 31, 2009 at 03:32, Philippe Monnet r...@monnet-usa.com wrote: After a bit over a day of both looking at the way NewRelic implemented their plugin for Rack and Sinatra, as well as digging deep in the core Camping code of the service and M methods, I managed to get something working. See http://github.com/techarch/rpm/blob/master/lib/new_relic/agent/instrumentation/camping.rb It took me many tests to understand that the M method actually include some of the Camping modules in the controller classes. I have been reading the entire framework back to back a bunch of times and I keep being amazed at the overall design. There are so many Rubyisms to be learned from the code. Let me know if you end up using the plugin and if there are ways to improve it. If you are using Heroku you should definitely give NewRelic a try since the Bronze edition comes for free. Philippe ___ 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: Broken Camping (on Dreamhost)
That's weird… First of all, could you update Rack to 1.1 and try with that version? If it's still broken, I think this monkey-patch should do it: class Rack::Request def params self.GET.update(self.POST) rescue EOFError, Errno::ESPIPE = e self.GET end end // Magnus Holm On Thu, Jan 21, 2010 at 06:19, Garret Buell terr...@gmail.com wrote: Hello all, I'm running Camping 1.9.300 on DreamHost. Everything has been working great for quite some time, then recently, visiting the Camping app gives a 500 Internal Server Error. It seems as if something at DreamHost was upgraded and now everything is broken. Even the basic example Camping apps do not work so I suspect there is some incompatibility with Camping and the current setup. I'm hoping someone can help me figure out what is wrong. Here is the relevant error log data: [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/request.rb:150:in `rewind': Illegal seek (Errno::ESPIPE) [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/request.rb:150:in `POST' [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/request.rb:160:in `params' [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom (eval):30:in `initialize' [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom (eval):50:in `new' [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom (eval):50:in `call' [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom dispatch.cgi:16 [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/content_length.rb:13:in `call' [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/content_length.rb:13:in `call' [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/handler/cgi.rb:33:in `serve' [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom /usr/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/handler/cgi.rb:7:in `run' [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] \tfrom dispatch.cgi:19 [Wed Jan 20 18:08:06 2010] [error] [client ***.***.***.***] Premature end of script headers: dispatch.cgi My dispatch.cgi worked previously and nothing has been modified but here it is: #!/usr/bin/ruby ENV['GEM_PATH'] = '/home/garret/.gems:/usr/lib/ruby/gems/1.8' ENV['GEM_HOME'] = '/home/garret/.gems' Dir.chdir '/home/garret/admin.*.com' require 'admin' app = Admin fixed = lambda do |env| r = env[REQUEST_URI][0..(env[REQUEST_URI].index(?)||0)-1] d = r.length - (env[PATH_INFO]||'/').length env[SCRIPT_NAME] = r[0...d] env[PATH_INFO] = r[d..-1] app.call(env) end Rack::Handler::CGI.run(fixed) The require 'admin' app = Admin can be replaced with any of the sample apps I've found with the same effect. Help? Thanks, Garret Buell ___ 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: gems.judofyr.net 404
And it's back up again! I'll try to get stuff.judofyr.net/camping-docs working too… // Magnus Holm On Sat, Jan 23, 2010 at 21:12, Dave Everitt dever...@innotts.co.uk wrote: I noticed today that this: gem install camping --source http://gems.judofyr.net has broken, so wanted to update the wiki at Github so visitors can get the latest version via gem? Dave Everitt ___ 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: sending data/overriding response headers?
Sure, just make sure to enable X-Sendfile in Apache/Nginx, and then set it yourself: def get @headers['X-Sendfile'] = /full/path/to/file @headers['Content-Type'] = text/plain; charset=utf-8 end Or if you want Rack to figure out which Content-Type to send: file = /full/path/to/file @headers['X-Sendfile'] = file @headers['Content-Type'] = Rack::Mime.mime_type(File.extname(file)) + ; charset=utf-8 If you ever need to send custom headers, just use the @headers hash. // Magnus Holm On Wed, Mar 3, 2010 at 16:43, David Susco dsu...@gmail.com wrote: Hey guys, A user would like to download a table dump as a CSV, what's the best way to do this? ActionController has send_data: http://api.rubyonrails.org/classes/ActionController/Streaming.html Is there something similar built into Camping? If not, is there a way to override the response headers of a controller to declare the response as something other than HTML (so the csv isn't displayed in the browser)? -- Dave ___ 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: sending data/overriding response headers?
In Camping 2 you can return an object which responds to #each and the server will then stream it to the client. If you want the file to trigger a download-box on the user, you'll have to send Content-Disposition as Julik mentioned. Something like this should work, although I'm not 100% sure: @headers['Content-Disposition'] = 'attachment; filename=table.csv' // Magnus Holm On Wed, Mar 3, 2010 at 17:04, Julik Tarkhanov julian.tarkha...@gmail.comwrote: On 3 mrt 2010, at 16:43, David Susco wrote: Is there something similar built into Camping? Before it was so that you could return an IO object from your action and it would just work. Dunno if Camping 2 still supports this. A Content-Disposition header would be in order so that your clients download a proper filename. -- Julik Tarkhanov m...@julik.nl ___ 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: Are there existing sitemap generators for Camping?
Cool. We'll have to find a place on the wiki for these things :-) Couldn't you also figure out SITE_BASE_URL in GoogleSiteMap? @request.url.gsub(/sitemap.xml, ) or something? // Magnus Holm On Sat, Mar 13, 2010 at 18:21, Philippe Monnet r...@monnet-usa.com wrote: Since I could not find one, I wrote a simple (and crude) Google sitemap generator - see http://gist.github.com/330973 After pasting the code in your app controllers module, you just need to customize 2 things: 1) the base url of your site: SITE_BASE_URL = http://www.myapp.com; 2) list the controllers you want to expose on the sitemap (since you may not want to expose all controllers): def self.sitemap_candidates [ :Test1, :Test2 ] end Have fun. Philippe On 3/8/2010 9:36 PM, Philippe Monnet wrote: When searching I have found a few Rails-specific sitemap generators but I was wondering if anyone new of a Camping-specific implementation? Philippe (techarch) ___ 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: restful camping with reststop
I find extending Camping apps to be quite easy, since it's all classes and
modules, but I can understand that extending Camping itself can be
difficult/weird. That said, I think a lot can be solved by defining
#included and #extended. It would be great if you could tell us a bit
exactly the problems you faced. We still have 1k left.
Don't hurry, though. Let's get 2.0 out first.
// Magnus Holm
On Tue, Mar 23, 2010 at 16:07, Matt Zukowski m...@roughest.net wrote:
I actually have a reststop app up and running fine with Camping 2.0 (check
out Taskr at http://github.com/zuk/taskr). Tthe catch is that it's a
version of 2.0 that I forked about this time last year, and looking at the
github graph, Magnus has committed a whole slew of changes since then. So
whatever broke Reststop must have been committed in the last 10 months or
so.
To be honest over the last year I've mostly switched form Camping to
Sinatra (and lately to Node.js, which is really really cool by the way). The
problem with Camping, for me, is that trying to extend it is a nightmare. I
learned this the hard way while writing Reststop and Picnic.
Anyway I have a bit of time right now, so since there seems to be some
interest, I'll pull down the latest version of Camping and see if I can make
it work with Reststop. I should also move Reststop to github while I'm at
it.
On Mon, Mar 22, 2010 at 11:32 PM, Philippe Monnet r...@monnet-usa.comwrote:
Hi David,
I had played with RESTstop on the old Camping maybe six months ago.
I have now started to take a look at what the issues are about.
So far I have found a few things like:
In reststop.rb:
- the service method needs to retrieve the REQUEST_METHOD using
@env['REQUEST_METHOD']
-the condition on the if statement on the last m.capture line of the
render method needs to be adjusted (not sure what a[0] should be replaced
with. So far I have temporarily replaced the line by:
s = m.capture{send(:layout){s}} if m.respond_to?(:layout)
In the blog.rb example
- the version number for camping needs to be updated
- require 'camping/db' should be removed since now obsolete
- require 'markaby' needs to be added
So far I can bring up the app in a browser, login, add a post.
But if I use Restr I can only do a GET. The PUT currently fails with a
401. I will continue to try figuring it out over the next week or so.
It would be great if the initial author could help us out.
Philippe
On 3/12/2010 8:04 AM, David Susco wrote:
Has anyone managed to get camping to work with reststop using 1.9.354?
___
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
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: What now?
Indeed, but for now I think http://stuff.judofyr.net/camping-docs/ (or, the URL would actually be camping.rubyforge.org when released) would be enough. I think we're pretty much ready for a release. If you'd like, I could mark HEAD as 2.0.rc1 and push it out to Gemcutter. Then you guys who have 2.0 apps could do a gem install camping --pre and make sure everything works. If everything seems fine we can release it :) // Magnus Holm On Tue, Mar 23, 2010 at 04:16, Philippe Monnet r...@monnet-usa.com wrote: I like the idea of the site being built on Camping and combining mini-apps and static content all integrated with jQuery for example. I am currently running two Camping 2.0 apps on Heroku and they work great. Hosting on Heroku would be also be convenient because of the ability to add Git contributors and because of the ease of deployment. On 3/21/2010 3:58 PM, Dave Everitt wrote: Hi Philippe I am one of those Camping friends (although I've been too busy with clients just lately to do much). Although I just posted links to your Camping 'add-ons' to the wiki :-) I agree about Sinatra - from curiosity I've even dabbled with it myself (shame!), although it is nice that Camping still has a small community feel. Perhaps some _why-type cartoons (along the lines you suggest) might be the right way forward for a 'This is Camping' website. Or just keep things clean and minimal. As for content, that was covered in another post to the list some time ago, as was a domain name. Magnus has the substance (tutorial, examples, etc.) and a nice CSS style for the blog example. Maybe start with a developed version of the Camping blog on Heroku (free) so we can each add Camping-related posts to keep things fresh? It's just making enough time to put it all together... I'd be happy to chip in, but what's the best way to build a whole site that uses Camping - a collection of apps and generated static pages? I once used Camping 1.5 (running as CGI) as an easy way to make a simple multipage wireframe mockup, but... Dave I was wondering how we can help with next steps? I keep seeing all the attention going to the Sinatra framework (and Rails of course) and would love to help more with promoting Camping. It would be great if one of our web designer / Camping friend could help create a catchy visual for the site. How about a night time view of a camp fire with a tent and maybe a small projector with a big silver screen where we could display rotating content / slides? Any other crazy concepts? Philippe ___ 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 ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: restful camping with reststop
@env['REQUEST_METHOD'] is the HTTP method send by the client, @method is the
method (in lowercase) Camping is going to run (r404 for 404 etc.)
// Magnus Holm
On Tue, Mar 23, 2010 at 17:01, Matt Zukowski m...@roughest.net wrote:
Hey Magnus, while we have your attention, in 2.0 how do I get access to
e['REQUEST_METHOD'] inside the 'service' method? Trying to figure this out
as we speak...
On Tue, Mar 23, 2010 at 11:50 AM, Magnus Holm judo...@gmail.com wrote:
I find extending Camping apps to be quite easy, since it's all classes and
modules, but I can understand that extending Camping itself can be
difficult/weird. That said, I think a lot can be solved by defining
#included and #extended. It would be great if you could tell us a bit
exactly the problems you faced. We still have 1k left.
Don't hurry, though. Let's get 2.0 out first.
// Magnus Holm
On Tue, Mar 23, 2010 at 16:07, Matt Zukowski m...@roughest.net wrote:
I actually have a reststop app up and running fine with Camping 2.0
(check out Taskr at http://github.com/zuk/taskr). Tthe catch is that
it's a version of 2.0 that I forked about this time last year, and looking
at the github graph, Magnus has committed a whole slew of changes since
then. So whatever broke Reststop must have been committed in the last 10
months or so.
To be honest over the last year I've mostly switched form Camping to
Sinatra (and lately to Node.js, which is really really cool by the way). The
problem with Camping, for me, is that trying to extend it is a nightmare. I
learned this the hard way while writing Reststop and Picnic.
Anyway I have a bit of time right now, so since there seems to be some
interest, I'll pull down the latest version of Camping and see if I can make
it work with Reststop. I should also move Reststop to github while I'm at
it.
On Mon, Mar 22, 2010 at 11:32 PM, Philippe Monnet
r...@monnet-usa.comwrote:
Hi David,
I had played with RESTstop on the old Camping maybe six months ago.
I have now started to take a look at what the issues are about.
So far I have found a few things like:
In reststop.rb:
- the service method needs to retrieve the REQUEST_METHOD using
@env['REQUEST_METHOD']
-the condition on the if statement on the last m.capture line of the
render method needs to be adjusted (not sure what a[0] should be replaced
with. So far I have temporarily replaced the line by:
s = m.capture{send(:layout){s}} if m.respond_to?(:layout)
In the blog.rb example
- the version number for camping needs to be updated
- require 'camping/db' should be removed since now obsolete
- require 'markaby' needs to be added
So far I can bring up the app in a browser, login, add a post.
But if I use Restr I can only do a GET. The PUT currently fails with a
401. I will continue to try figuring it out over the next week or so.
It would be great if the initial author could help us out.
Philippe
On 3/12/2010 8:04 AM, David Susco wrote:
Has anyone managed to get camping to work with reststop using 1.9.354?
___
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
___
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
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 2.0.RC0
Oh, I totally forgot about that! Yes, I agree that this would be nice to have at github.com/camping. Should I fork Matt's repo or create a new one? // Magnus Holm On Wed, Apr 7, 2010 at 19:18, Matt Zukowski m...@roughest.net wrote: Hey Philippe, thanks for that. I've gone ahead and created a github repo for reststop at https://github.com/zuk/reststop Your changes have been pushed up. I've also added you as a collaborator so you can freely commit to my copy of the repo. Next step is to create a gemspec for this and push it up to gemcutter/rubyforge. Matt. On Wed, Apr 7, 2010 at 9:02 AM, Philippe Monnet r...@monnet-usa.com wrote: Successfully tested the updated RESTstop restful blog too. Started to test my own app (mySkillsMap.com) locally but will need to continue tonight. On 4/7/2010 5:33 AM, Philippe Monnet wrote: I tested 2 new apps I wrote to test OAuth so far with success. I sill have to test my main web app and the recent RESTstop blog app I had updated. On Sat, Apr 3, 2010 at 4:23 PM, Magnus Holm judo...@gmail.com wrote: Ladies and gentlemen: gem install camping --prerelease (Look, no --source!) I'm not a big fan of betas/RCs, but this is a rather big change and I want to make sure we release something that actually works. I don't have any apps that runs on Camping (neither 1.5 nor 1.9/2.0), so I was hoping if some of you could verify that it works as expected? I'll give it a week or so, and if everything seems fine I'll… * Copy the documentation at http://stuff.judofyr.net/camping-docs/ to http://camping.rubyforge.org/ * Make sure all the links in the wiki points to the right place * Release the gem as 2.0 at rubygems.org * Write an announcement which I'll post to ruby-core, rack-devel and camping-list * Submit the announcement to Rubyflow and ruby.reddit * Write a patch which removes Rack::Adapters::Camping from Rack * (Possibly write a little blog post comparing Camping and Sinatra from an objective point of view) * Start hacking on Camping 2.1! Puh. What'd ya think? Oh, and busbey has been playing a bit with the code: http://github.com/busbey/camping. Some awesome migrations ideas in there. Looking forward to merge them into 2.1! // 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 ___ 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 ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Camping 2.1: Tests
Wanted to highlight some of the issues we know have on github and get some discussion going. First up: Tests - http://github.com/camping/camping/issues#issue/15 Currently Camping doesn't have any automated tests. At all. Now, I'm not a testing freak, but I'm not _why either, so I believe we'll have to have *some* tests. I'm not talking about 100% unit-test coverage, but just something which lets us commit with confidence and makes it easier to make sure everything works on both 1.8 and 1.9. One idea I had: Use what we have in test/apps/ now and write WebRat-steps to make sure everything works as expected. The apps should be ran through Camping::Server, and the tests should use Net::HTTP so we test the whole stack. Anyone wants to give it a try, or have any other ideas? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Camping 2.1: Rackification
Rackification - http://github.com/camping/camping/issues#issue/3 I want to make Camping even more Rack-ish. Some ideas: 1. Make Camping::Server use Rack::Server 2. The dispatcher shouldn't care about the method Previously the dispatcher (Controllers.D) has taken a path and a method, and returns an array with the controller and the method: D(/, get) # = [Index, 'get'] D(/, post) # = [I, 'r501'] # no post-method in Index D(/not_found, get) # = [I, 'r404'] I want to make it such that the dispatcher only cares about the path, and then the controllers are responsible for calling the right method. I feel that is more HTTP-ish: First look up the resource, then try to call the method. 3. When the method isn't found, call #method_missing Okay, this one is kinda dangerous, but it would be cool if Camping would call #method_missing if the method doesn't exist. That way, Camping almost becomes the Ruby-version of HTTP. Too dangerous (aka. it would swallow regular NoMethorError) or possible? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Camping 2.1: Easier to extend
http://github.com/camping/camping/issues#issue/10 It's currently very hard to extend Camping, so I've been thinking of ways to make it easier without taking too many bytes. Here's a very simple approach: https://gist.github.com/75ecb81a3ae98b097f8a When you write `Camping.plugin :Foo` it stores the code in the file, and when you later call `App.needs :Foo` it fetches the file again and replaces Camping with App. Not perfect, but at least it's something. I'll have to try to get RESTstop using this technique to see how it works... Any other ideas? Comments? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Camping 2.1: Making migrations less sucky
http://github.com/camping/camping/issues#issue/12 This is probably the most exciting issue: Making migrations less sucky. The fact that you'll have to do this to get started sucks: module Nuts::Models class Page Base end class BasicFields V 1.0 def self.up create_table Page.table_name do |t| t.string :title t.text :content # This gives us created_at and updated_at t.timestamps end end def self.down drop_table Page.table_name end end end It should really just be something like this: module Nuts::Models class Page Base t.string :title t.text :content t.timestamps end end But we still want to support regular migrations (in some way at least). See the issue for more examples/comments. // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 2.1: Tests
Mosquito tests the app from within the same process. I think it'd make more sense to have the tests run over HTTP. // Magnus Holm On Tue, Apr 13, 2010 at 02:00, Philippe Monnet r...@monnet-usa.com wrote: Did not know about WebRat but it seems pretty compelling. I had meant to look at Mosquito (http://mosquito.rubyforge.org/) but if WebRat has a greater adoption in the Ruby community that might make more sense. On 4/12/2010 8:18 AM, Magnus Holm wrote: Wanted to highlight some of the issues we know have on github and get some discussion going. First up: Tests - http://github.com/camping/camping/issues#issue/15 Currently Camping doesn't have any automated tests. At all. Now, I'm not a testing freak, but I'm not _why either, so I believe we'll have to have *some* tests. I'm not talking about 100% unit-test coverage, but just something which lets us commit with confidence and makes it easier to make sure everything works on both 1.8 and 1.9. One idea I had: Use what we have in test/apps/ now and write WebRat-steps to make sure everything works as expected. The apps should be ran through Camping::Server, and the tests should use Net::HTTP so we test the whole stack. Anyone wants to give it a try, or have any other ideas? // 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 ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Try Camping!
Here's my proposal for Ruby Summer of Code: http://github.com/judofyr/try-camping // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Changing render semantics?
I'm trying to integrate Tilt (for providing Haml etc. support), but
are having some problems supporting both the previous `render` and
this new `render`.
Previous render:
- loads Markaby when needed
- Always wraps the layout
- render :index # = Calls index() within Markaby
- render :index, 1, 2 # = Calls index(1, 2) within Markaby
What I want from the new render:
- loads Markaby when needed
- loads Tilt when needed
- render :index, :layout = false # = Don't wraps the layout
- render :foo # = Will check #{VIEW_PATH}/foo.* and render that file
(falling back on the Markaby methid)
- render :foo, :locals = { :bar = 123 } # = Same as above, but with
local variables set
- render :index, :locals = { :foo = 123 } # = :locals is ignored if
it's a Markaby method
I guess the question is: Does anybody actually use `render` with
multiple arguments (render :index, 1, 2)? If not, I guess we can
easily switch to this new `render` without breaking code.
// Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
Aprilfest
http://github.com/camping/camping/compare/4539baf...6347baf Latest changes in Camping: 1. There is now a Camping.options 2. Session now uses the Camping.options above 3. Fast Tilt integration (ERB/Haml support!) 4. Various changes gem install camping --source http://gems.judofyr.net/ Any comments or improvements? Have I done anything stupid? I think I'll rather go for the commit-to-master-and-revert-if-theres-something-wrong, than the commit-to-branch-or-fork-and-merge-when-ready. -- 1. There is now a Camping.options Useful (mostly for plugins) when you need to set different options: module App set :hello, foo end App.options[:hello] == foo -- 2. Session now uses the Camping.options above I want every setting to use Camping.options, so here's the new way: module App set :secret, KEEP IT SECRET include Camping::Session end -- 3. Fast Tilt integration module App set :views, File.dirname(__FILE__) + '/views' module Controllers class Index def get render :index end end end end If you now create a file called views/index.haml, `render` will now render that file (instead of looking for a Markaby method). You can also create views/layout.haml and it will wrap it (`yield` will return the inner template). You can of course also use views/index.erb or any other template engine which Tilt supports (see http://github.com/rtomayko/tilt) -- 4. Various changes * require 'camping-unabridged' now marks itself as 'camping' was required, and nothing happesn if you do require 'camping' later (great for development!) * Camping::Server now uses Rack::Server is a lot more cleaner. * The session is now stored as a Hash, and not a App::H. This caused me some weird bugs. * Use Class#method_defined? instead of Class#instance_method rescue nil * Fix bug in rake diff // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping on Ruby 1.9.1 on Win32
Hey Dave, Yeah, Camping should work on both 1.9.1 and Windows, but I haven't tested it in a while. Try it out, and please let us know if there's something that doesn't work :) // Magnus Holm On Thu, May 20, 2010 at 02:47, David Ray djr@gmail.com wrote: Hi all, Can I go camping with ruby 1.9.1 on win32? Many thanks, Dave. ___ 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: First time and first error
Hey Raimon, Try a `sudo gem update --system` first to upgrade to the latest RubyGems // Magnus Holm On Tue, Jun 8, 2010 at 10:59, Raimon Fernandez co...@montx.com wrote: On 8jun, 2010, at 09:18 , Raimon Fernandez wrote: Hi again, I'm trying to install Camping on my OS X but I'm getting some errors: MacBook-ProII-2:~ montx$ gem -v 1.3.5 MacBook-ProII-2:~ montx$ sudo gem install camping WARNING: RubyGems 1.2+ index not found for: http://gems.rubyforge.org/ RubyGems will revert to legacy indexes degrading performance. Bulk updating Gem source index for: http://gems.rubyforge.org/ ERROR: While executing gem ... (Gem::RemoteSourceException) Error fetching remote gem cache: SocketError: getaddrinfo: nodename nor servname provided, or not known (http://gems.rubyforge.org/yaml) What are the minimums ? I'm using in my developer machine Ruby On Rails and Ruby without any problems, with some gems. I want to add that I'm not behind any proxy or firewall, and that I could successfully download/and install some other gems in this machine without any problems, but no, no, I can't install nothing from gem. It seems like a time-out problem: I have this remote sources: - REMOTE SOURCES: - http://gems.rubyforge.org/ - http://gems.github.com MacBook-ProII-2:~ montx$ mmm, a ping to http://gems.rubyforge.org/ = cannot resolve http://gems.rubyforge.org/: Unknown host MacBook-ProII-2:~ montx$ sudo gem sources -r http://gems.rubyforge.org/ http://gems.rubyforge.org/ removed from sources now I have only - http://gems.github.com MacBook-ProII-2:~ montx$ sudo gem install camping ERROR: could not find gem camping locally or in a repository MacBook-ProII-2:~ montx$ any idea ? thanks, r. thanks, regards, r. ___ 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 ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: First time and first error
I believe Rack::Server was introduced in one of the later Rack versions. Looks like I forgot to update the version dependency. Are you able to install the latest rack (gem install rack), or is rubygems.org fully down? // Magnus Holm On Tue, Jun 8, 2010 at 12:25, Raimon Fernandez co...@montx.com wrote: On 8jun, 2010, at 11:52 , Dave Everitt wrote: Otherwise, get the bleeding edge version: sudo gem install camping --source http://gems.judofyr.net/ ok, I want to focus on Camping so I've installed the edge version without any problems :-) the problem is when I try to execute some example: acBook-ProII-2:Camping montx$ camping homepage.rb /Library/Ruby/Gems/1.8/gems/camping-2.0.392/bin/../lib/camping/server.rb:27: uninitialized constant Rack::Server (NameError) from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require' from /Library/Ruby/Gems/1.8/gems/camping-2.0.392/bin/camping:6 from /usr/bin/camping:19:in `load' from /usr/bin/camping:19 I've installed Rack as I use it with some of my Ruby On Rails and Thin projects ... Maybe the Rack::Server is not the same ? Should I install more dependencies ? thanks, r. ___ 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: First time on Camping
Hey Raimon, I see that you've been experimenting with Camping and Reststop lately, and just thought I should chime in a bit. You definitely don't *need* Reststop in order to achieve what you want, so it might be a good idea to just leave Reststop until it gets a little more robust. Let's see how we can tackle your problem with Camping only: For serving XML, you can use Builder (http://builder.rubyforge.org/). Here's a little helper for you: require 'camping' require 'builder' Camping.goes :App module App # We include the Views module so we can call them as methods. include Views module Helpers def xml(name) # We'll need to send this as text/xml @headers[Content-Type] = text/xml result = String.new # The builder takes a `target` where the XML will end up builder = Builder::XmlMarkup.new(:target = result, :indent = 2) # Generates a ?xml version=1.0 encoding=UTF-8 ? builder.instruct! # Calls the method you sent in, passing in the builder as an argument send(name, builder) # Return the restult result end end end If you for instance want to generate this XML: posts post title=Post titleContent of post/post /posts You would have the following view: module App::Views def posts(xml) xml.posts do @posts.each do |post| xml.post(post.content, :title = post.title) end end end end And if you want this XML: ?xml version=1.0 encoding=UTF-8? posts post titleHiya/title contentHey/content /post /posts You have this view: module App::Views def posts(xml) xml.posts do @posts.each do |post| xml.post do xml.title(post.title) xml.content(post.content) end end end end end - You render the XML in the controller like this: module App::Controllers class Index def get # The view has access to this variable @posts = Post.all # Calls the helper, which in turn calls the view xml :posts end end end That's (hopefully) the simplest way to generate XML with Camping. You still need to create a model to store/retrieve the data. Before we can help you here, we need to know a few things: Is it going to fetch data from a specific place, or should it create its own database (from scratch)? Any specific database you want to use? Here's a Pastie with all the code: http://pastie.org/1008983 (Should work on any version of Camping). // Magnus Holm On Tue, Jun 8, 2010 at 08:25, Raimon Fernandez co...@montx.com wrote: hi list, This is my first time here, my first time reading seriously something about Camping. I need to create a very simple web server for serving only .xml files, extracted from a sqlite database with some queries. I'm quite comfortable with Ruby on Rails, but it would be too much for this project, so I've decided to take a look at Camping or Sinatra, not sure what's the best option. There would be only 5 tables, 100 rows per table, and the idea is fetch data from a device like iPad/iPhone/iPod, update it and persist the changes in the server. The data transfer would be in plain .xml files, no html or css. Any helpful directions would be great :-) thanks, r. ___ 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: First time on Camping
Yeah, people always get a little confused because you don't need to define your database when you're using bin/camping (it has a default SQLite database at ~/.camping.db). I also see that there's some old, database code here; we definitely need to update our documentation (yes, I'm working on it!) First of all, the table name should be list_people (since people is the plural to person and the table names are always in lowercase), but you should rather do `create_table Person.table_name` and `drop_table Person.table_name` because then you don't need to think about it at all :-) Secondly, you only need this in order to create the database: def List.create List::Models.create_schema end Then it will use a SQLite database at ~/.camping.db (as long as you start it with `camping list.rb`). This is perfect for just testing things out (you can also run `camping -C list.rb` to get an IRB console). Please note that if you only run `camping list.rb`, you'll have to load the page in the browser before the migrations run. If you want to use a specific database, you can add this: def List.create List::Models::Base.establish_connection( :adapter = postgresql, :username = root, :password = toor, :database = list ) List::Models.create_schema end Or you might want to add the information in a database.yml file: --- adapter: postgresql username: root password: toor database: list And then rather do: require 'yaml' def List.create List::Models::Base.establish_connection(YAML.load(File.read(database.yml))) List::Models.create_schema end Please note that if you connect to a database which already has the tables, DON'T run `List::Models.create_schema` as this will probably delete the whole database. General rule: you only need migrations to setup the database. -- And thirdly: Yes, we are aware of that the migration support isn't very nice. In the future we hope to have something like: module List::Models class Person t.string :name end end def List.create List::Models.setup! end Until then, you'll have to stick with the current solution :-) // Magnus Holm On Fri, Jun 18, 2010 at 11:09, Raimon Fernandez co...@montx.com wrote: On 17jun, 2010, at 21:04 , Magnus Holm wrote: That's (hopefully) the simplest way to generate XML with Camping. You still need to create a model to store/retrieve the data. Before we can help you here, we need to know a few things: Is it going to fetch data from a specific place, or should it create its own database (from scratch)? Any specific database you want to use? Here's a Pastie with all the code: http://pastie.org/1008983 (Should work on any version of Camping). I'm trying to adapt your pastie to use a sqlite databse, but I'm having some errors that I can't see ... Here's a Pastie with all code: http://pastie.org/1009797 I'm just trying to create with code a simple table called Persons with some fields but ... :-) Also, I can't find where is creating the database ... thanks, regards, r. ___ 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: First time on Camping
Excellent!
Camping uses Rack, so it should be very simple to get it running on
any Ruby web server. Just create a config.ru like this:
require 'list'
List.create if List.respond_to?(:create) # call List.create if it exists
run List # and run the app!
Then you can start it with: `thin start` (when you're in the app directory)
One thing you'll have to remember is that any exceptions which are
raised, won't be rescued inside Camping, but rather be raised all the
way up. Thin (hopefully) catches it somewhere, but you should probably
handle it yourself:
module List
def r500(klass, method, exception)
# Do some funky things
There was an exception in #{klass}.#{method}: #{exception}
end
end
You could also use something like http://hoptoadapp.com/ (they have
free plans) which gives you a nice dashboard and sends you an email
every time an exception is raised. Just create an account, run `gem
install toadhopper` and add this to your app:
require 'toadhopper'
module List
ExceptionHandler = Toadhopper.new(YOUR API KEY)
def r500(klass, method, exception)
# Send the exception to Hoptoad:
ExceptionHandler.post!(exception)
# Render something for the user. You would probably want to render some XML
# so the client knows something went wrong.
There was an exception in #{klass}.#{method}: #{exception}
end
end
// Magnus Holm
On Fri, Jun 18, 2010 at 13:23, Raimon Fernandez co...@montx.com wrote:
buf, now I'm lost ...
:-))
no, really, thanks for that info, now I have working as I want ...
:-)
I've tested and created a new databse, and is working also.
I've created a new sqlite3 from terminal and filled-up with some data and now
I can use this databse from Camping, cool!
And, caping is serving the data with .xml format and I can get it from my
devices, cool!
I'm going to play more with thise, sure I'll come back with more questions ...
:-)
ah, I always use Thin with Nginx for my RoR instead of Mongrel, I suppose
there would be no problem with camping ?
and speed: normally it's all very fast, but sometimes, it takes a little bit
(3 or more seconds) to respond camping, and I'm not doing nothing serious at
all, just the example from pastie.
is because I'm using the development mode instead of production, like in RoR ?
thanks again !
regards,
r.
On 18jun, 2010, at 12:33 , Magnus Holm wrote:
Yeah, people always get a little confused because you don't need to
define your database when you're using bin/camping (it has a default
SQLite database at ~/.camping.db).
I also see that there's some old, database code here; we definitely
need to update our documentation (yes, I'm working on it!)
First of all, the table name should be list_people (since people
is the plural to person and the table names are always in
lowercase), but you should rather do `create_table Person.table_name`
and `drop_table Person.table_name` because then you don't need to
think about it at all :-)
Secondly, you only need this in order to create the database:
def List.create
List::Models.create_schema
end
Then it will use a SQLite database at ~/.camping.db (as long as you
start it with `camping list.rb`). This is perfect for just testing
things out (you can also run `camping -C list.rb` to get an IRB
console). Please note that if you only run `camping list.rb`, you'll
have to load the page in the browser before the migrations run.
If you want to use a specific database, you can add this:
def List.create
List::Models::Base.establish_connection(
:adapter = postgresql,
:username = root,
:password = toor,
:database = list
)
List::Models.create_schema
end
Or you might want to add the information in a database.yml file:
---
adapter: postgresql
username: root
password: toor
database: list
And then rather do:
require 'yaml'
def List.create
List::Models::Base.establish_connection(YAML.load(File.read(database.yml)))
List::Models.create_schema
end
Please note that if you connect to a database which already has the
tables, DON'T run `List::Models.create_schema` as this will probably
delete the whole database. General rule: you only need migrations to
setup the database.
--
And thirdly: Yes, we are aware of that the migration support isn't
very nice. In the future we hope to have something like:
module List::Models
class Person
t.string :name
end
end
def List.create
List::Models.setup!
end
Until then, you'll have to stick with the current solution :-)
// Magnus Holm
On Fri, Jun 18, 2010 at 11:09, Raimon Fernandez co...@montx.com wrote:
On 17jun, 2010, at 21:04 , Magnus Holm wrote:
That's (hopefully) the simplest way to generate XML with Camping.
You still need to create a model to store/retrieve the data. Before we
can help you here, we need to know a few things: Is it going to fetch
data from a specific place, or should it create its own database (from
scratch)? Any
Re: First time on Camping
Oh, and I also have the speed issue! That's definitely a bug. I'll have a look at it later... On Friday, June 18, 2010, Raimon Fernandez co...@montx.com wrote: buf, now I'm lost ... :-)) no, really, thanks for that info, now I have working as I want ... :-) I've tested and created a new databse, and is working also. I've created a new sqlite3 from terminal and filled-up with some data and now I can use this databse from Camping, cool! And, caping is serving the data with .xml format and I can get it from my devices, cool! I'm going to play more with thise, sure I'll come back with more questions ... :-) ah, I always use Thin with Nginx for my RoR instead of Mongrel, I suppose there would be no problem with camping ? and speed: normally it's all very fast, but sometimes, it takes a little bit (3 or more seconds) to respond camping, and I'm not doing nothing serious at all, just the example from pastie. is because I'm using the development mode instead of production, like in RoR ? thanks again ! regards, r. On 18jun, 2010, at 12:33 , Magnus Holm wrote: Yeah, people always get a little confused because you don't need to define your database when you're using bin/camping (it has a default SQLite database at ~/.camping.db). I also see that there's some old, database code here; we definitely need to update our documentation (yes, I'm working on it!) First of all, the table name should be list_people (since people is the plural to person and the table names are always in lowercase), but you should rather do `create_table Person.table_name` and `drop_table Person.table_name` because then you don't need to think about it at all :-) Secondly, you only need this in order to create the database: def List.create List::Models.create_schema end Then it will use a SQLite database at ~/.camping.db (as long as you start it with `camping list.rb`). This is perfect for just testing things out (you can also run `camping -C list.rb` to get an IRB console). Please note that if you only run `camping list.rb`, you'll have to load the page in the browser before the migrations run. If you want to use a specific database, you can add this: def List.create List::Models::Base.establish_connection( :adapter = postgresql, :username = root, :password = toor, :database = list ) List::Models.create_schema end Or you might want to add the information in a database.yml file: --- adapter: postgresql username: root password: toor database: list And then rather do: require 'yaml' def List.create List::Models::Base.establish_connection(YAML.load(File.read(database.yml))) List::Models.create_schema end Please note that if you connect to a database which already has the tables, DON'T run `List::Models.create_schema` as this will probably delete the whole database. General rule: you only need migrations to setup the database. -- And thirdly: Yes, we are aware of that the migration support isn't very nice. In the future we hope to have something like: module List::Models class Person t.string :name end end def List.create List::Models.setup! end Until then, you'll have to stick with the current solution :-) // Magnus Holm On Fri, Jun 18, 2010 at 11:09, Raimon Fernandez co...@montx.com wrote: On 17jun, 2010, at 21:04 , Magnus Holm wrote: That's (hopefully) the simplest way to generate XML with Camping. You still need to create a model to store/retrieve the data. Before we can help you here, we need to know a few things: Is it going to fetch data from a specific place, or should it create its own database (from scratch)? Any specific database you want to use? Here's a Pastie with all the code: http://pastie.org/1008983 (Should work on any version of Camping). I'm trying to adapt your pastie to use a sqlite databse, but I'm having some errors that I can't see ... Here's a Pastie with all code: http://pastie.org/1009797 I'm just trying to create with code a simple table called Persons with some fields but ... :-) Also, I can't find where is creating the database ... thanks, regards, r. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: First time on Camping
This shouldn't be a problem, because that's the way to add non-ASCII characters to XML documents. A proper XML parser should handle it... // Magnus Holm (from my phone) On Friday, June 18, 2010, Raimon Fernandez co...@montx.com wrote: Hi again, I know this is more related to builder than to camping, but not sure where to ask for it ... :-) My app receives .xml file from some different sources, and all of them, except the camping one, are formatted like this: ?xml version=1.0 encoding=UTF-8? person nameJim Fernández/name phone555-1234/phone /person but camping is formatting like this: ?xml version=1.0 encoding=UTF-8? person nameJim Fern#225;ndez/name phone555-1234/phone /person The main difference is the encoding for some chars: á = #225; I can't find in builder how to write values without escaping them ... thanks, r. On 17jun, 2010, at 21:04 , Magnus Holm wrote: And if you want this XML: ?xml version=1.0 encoding=UTF-8? posts post titleHiya/title contentHey/content /post /posts You have this view: module App::Views def posts(xml) xml.posts do �...@posts.each do |post| xml.post do xml.title(post.title) xml.content(post.content) end end end end end ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: First time on Camping
I think the problem is that Builder don't know that you're using UTF-8, so it's just doing the safest thing and just escapes everything. But this shouldn't really be a problem, since the parser should handle it and treat every #225; as á. // Magnus Holm On Sat, Jun 19, 2010 at 15:53, Raimon Fernandez co...@montx.com wrote: Hi all, On 18jun, 2010, at 17:51 , Magnus Holm wrote: This shouldn't be a problem, because that's the way to add non-ASCII characters to XML documents. A proper XML parser should handle it... But in this case, it's an ASCII á, well, the extended ASCII, and all .xml files that I've created never added this encoded, always the char itself, like à á ç ñ I'm using the TBMXML parser http://www.tbxml.co.uk/TBXML/TBXML_Free.html And because the xml file has the encoding=UTF-8 I suppose that those chars can be added as they are without encoding. And also I'm using other C libraries in other projects that they do not escape those chars ... Thanks! regards, r. // Magnus Holm (from my phone) On Friday, June 18, 2010, Raimon Fernandez co...@montx.com wrote: Hi again, I know this is more related to builder than to camping, but not sure where to ask for it ... :-) My app receives .xml file from some different sources, and all of them, except the camping one, are formatted like this: ?xml version=1.0 encoding=UTF-8? person nameJim Fernández/name phone555-1234/phone /person but camping is formatting like this: ?xml version=1.0 encoding=UTF-8? person nameJim Fern#225;ndez/name phone555-1234/phone /person The main difference is the encoding for some chars: á = #225; I can't find in builder how to write values without escaping them ... thanks, r. On 17jun, 2010, at 21:04 , Magnus Holm wrote: And if you want this XML: ?xml version=1.0 encoding=UTF-8? posts post titleHiya/title contentHey/content /post /posts You have this view: module App::Views def posts(xml) xml.posts do �...@posts.each do |post| xml.post do xml.title(post.title) xml.content(post.content) end end end end end ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- // 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 ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Speed issue
Okay, I was just wondering since if you run the app with the thin command, you won't get the reloader. So apparently the issue exists only with the reloader+Mongrel... On Monday, June 21, 2010, Raimon Fernandez co...@montx.com wrote: On 21jun, 2010, at 12:56 , Magnus Holm wrote: What if you run Thin with `camping -s thin app.rb`? Do you have the speed issue then? No, with Thin I don't have the speed issue ... thanks, r. Thanks, Magnus On Monday, June 21, 2010, Raimon Fernandez co...@montx.com wrote: On 20jun, 2010, at 23:38 , Raimon Fernandez wrote: On 18jun, 2010, at 15:34 , Magnus Holm wrote: Oh, and I also have the speed issue! That's definitely a bug. I'll have a look at it later... I'm making some progress with Camping and well, it's impressive, really :-) Wich version can I use that has not the bug for speed issue ? I would like to do some demo and I prefer to avoid this bug ... :-) Just observed that when I run camping with Thin I'm not getting the speed issue, only with Mongrel ... thanks, r. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- // 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 -- // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: versioning alternatives
This seems to be the migration that vestal_versions generates: http://github.com/laserlemon/vestal_versions/blob/master/generators/vestal_versions/templates/migration.rb. I assume you can just copy that into your app (just replace ActiveRecord::Migration with V 1.1). // Magnus Holm On Tue, Jun 29, 2010 at 17:56, David Susco dsu...@gmail.com wrote: Has anyone had any experience with vestal_versions, has_versioning, or another similar gem with camping? I'm currently fooling around with vestal_versions ( :P ) trying to figure out how to create the version table. Apparently this is handled via a script/db migration in Rails, and without something similar to the handy create_versioned_table call that's in acts_as_versioned. -- Dave ___ 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
Camping 2.1 and whywentcamping.com
Hey campers! I think it's about time to release Camping 2.1, which features: * Support for other template engines (Haml, ERB, etc) out of the box * No longer depends on ActiveRecord (this was a bug) * Camping.options is now a Hash where you can put all sorts of configuration stuff * Camping::Server now uses Rack::Server (got rid of some code) * See all changes here: http://github.com/camping/camping/compare/2.0...master -- There's still one thing I want to improve before we release 2.1 though, and that is the website. Currently it only redirects to the RDoc, but I believe we can do better. Checkout this: http://whywentcamping.judofyr.net/ (also see the GitHub repo for some more information: http://github.com/camping/whywentcamping.com) Better? Worse? You tell me :-) Have a look at the issues I'm aware of (http://github.com/camping/whywentcamping.com/issues) and please add your own too. // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Access to github.com/camping
Hey, I've converted the camping account into an organization (see http://github.com/blog/674-introducing-organizations), which means that it's a lot easier to manage it. There's currently two teams at the moment: Owners: These have full admin access (can create repos etc.) - Magnus - Philippe Developers: These can push to all the repos at github.com/camping - Magnus - Philippe - busbey - Dave Everitt - zuk - zimbatm I'm *very* open to add more users to the developers team. Just say what you intend to do (on the mailing list), and I'll add you. If you have a Camping related project which you would like to host under github.com/camping, just ask on the mailing list and we'll create a repo for you. (This should be added to the wiki in the near future) // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping 2.1 and whywentcamping.com
Awesome domain name! And as long as you include the image, it probably makes sense for new people too. You know, the password to the camping github account was actually littlewheels :-) // Magnus Holm On Wed, Jun 30, 2010 at 15:03, Sean Busbey s...@manvsbeard.com wrote: kylekyle and I have planned to use http://thelittlewheels.com/ as a showcase for camping stuff. probably even more confusing to new people than whywentcamping On Wed, Jun 30, 2010 at 13:57, Philippe Monnet r...@monnet-usa.com wrote: Thanks Magnus! I love the idea of working on the web site for 2.1. I am still not crazy about the web site name though - as it is not easy for people to remember if they don't know the connection with _why. I personally would have preferred rubycamping.com or something linking Camping to Ruby somehow. But if everyone prefers that name I am fine with that. A couple ideas for the site: Keep the home page simple with all content fitting within 1280 x 1024 Use a catchy design (need some help here) Accentuate that Camping is about Ruby (maybe also include the ruby logo somewhere) Have a brief note about the connection to _why and a link to a page explaining the history of Camping with further links to _why's other sites Encourage people to try it by capitalizing on some of Camping's strengths: Fast to learn - requires only basic Ruby skills Much simpler than Rails but more structure than Sinatra/Padrino Lightning fast and memory efficient allowing fast and efficient sites Can evolve from simple file to organized directory structure Can layer in more features later using persistence and choice of view engines How about using some kind of an animated (auto advancing) slideshow to highlight some of the benefits? See an example at: http://blog.monnet-usa.com/?p=276 How about a page on learning with a link to the book as well as a list of links for other tutorials or short explanations on key topics (e.g. how to do migrations, how to use include/extend, how to use different view engines, etc.)? How about a page about plugins with some brief description of their intent? I would love for us to include _why's cartoons in some of the sub pages ;-) Who would be interested in working together on the site? Could we do a couple graphic mockups of the main page? How should we exchange them? Via the mailing list? I am ready and excited to help with that. I think it would be great to launch the site in time for _Why Day (Aug 19th)! Philippe On 6/30/2010 5:08 AM, Magnus Holm wrote: Hey campers! I think it's about time to release Camping 2.1, which features: * Support for other template engines (Haml, ERB, etc) out of the box * No longer depends on ActiveRecord (this was a bug) * Camping.options is now a Hash where you can put all sorts of configuration stuff * Camping::Server now uses Rack::Server (got rid of some code) * See all changes here: http://github.com/camping/camping/compare/2.0...master -- There's still one thing I want to improve before we release 2.1 though, and that is the website. Currently it only redirects to the RDoc, but I believe we can do better. Checkout this: http://whywentcamping.judofyr.net/ (also see the GitHub repo for some more information: http://github.com/camping/whywentcamping.com) Better? Worse? You tell me :-) Have a look at the issues I'm aware of (http://github.com/camping/whywentcamping.com/issues) and please add your own too. // 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 -- Sean ___ 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
API documentation good enough?
As you might know, I'm not using Camping on a regular basis, so I'm just wondering if the API documentation (http://camping.rubyforge.org/api.html) is good enough? If not, is it something we can improve by simply updating camping-unbridged.rb? If not, do we rather want something like this? http://www.sinatrarb.com/intro.html // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Wiki vs homepage
Hey guys, Philippe had some interesting points about the website: 1. Keep the home page simple with all content fitting within 1280 x 1024 2. Use a catchy design (need some help here) 3. Accentuate that Camping is about Ruby (maybe also include the ruby logo somewhere) 4. Have a brief note about the connection to _why and a link to a page explaining the history of Camping with further links to _why's other sites 5. Encourage people to try it by capitalizing on some of Camping's strengths: - Fast to learn - requires only basic Ruby skills - Much simpler than Rails but more structure than Sinatra/Padrino - Lightning fast and memory efficient allowing fast and efficient sites - Can evolve from simple file to organized directory structure - Can layer in more features later using persistence and choice of view engines 6. How about using some kind of an animated (auto advancing) slideshow to highlight some of the benefits? See an example at: http://blog.monnet-usa.com/?p=276 7. How about a page on learning with a link to the book as well as a list of links for other tutorials or short explanations on key topics (e.g. how to do migrations, how to use include/extend, how to use different view engines, etc.)? 8. How about a page about plugins with some brief description of their intent? 9. I would love for us to include _why's cartoons in some of the sub pages ;-) Now, the more I look at this list (and my own thoughts about the new camping site) I realize that we're talking about two different things: * A site to attract new users * A site to inform regular users It looks like my attempt (http://whywentcamping.judofyr.net/) tries to target the latter, while Philippe targeted the former (http://rubycamping.monnet-usa.com/). Both sites serves a purpose and I believe both are equally important. -- Here's what I propose: We split the site into two parts. We turn what I've created into a wiki. Everyone are welcome to edit and add their own content. Then we take Philippe's ideas/design/site and turn it into ruby-camping.com or whywentcamping.com or whatnot. It probably doesn't need to be more than a single page. What'd ya think? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Camping on StackOverflow
I've asked some of them (even though they are several months olds) and have also subscribed to the camping-tag. I'll try to automatically forward them to the camping-list :-) // Magnus Holm On Sun, Jul 25, 2010 at 12:53, Dave Everitt dever...@innotts.co.uk wrote: Camping has a new user on StackOverflow :-) - I just stumbled across this: http://stackoverflow.com/questions/2618535/camping-return-user-to-recent-entries-but-keep-errors If anyone with a StackOverflow account wants to leap in? Dave Everitt ___ 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
Multiple inserts in ActiveRecord
Hey campers, I'm wondering if any of you know a better solution to skylerrichter's problem: http://github.com/camping/camping/issues#issue/28 The basic idea is that he want to create a Company, and then the first User in that Company: @company = Company.create( :name = @input.name, :sub_domain = @input.subdomain) # Create the first user: @user = User.create( :company_id = @company.id, :first_name = @input.first_name, :last_name = @input.last_name, :email = @input.email, :password = @input.password) Both Company and User has validations, so there's a possibility that they don't actually get saved to the DB, and in that case he don't want *any* of them to be saved (I assume). I was thinking about something like this: begin Company.transaction do @company = Company.create!( :name = @input.name, :sub_domain = @input.subdomain) @user = User.create!( :company_id = @company.id, :first_name = @input.first_name, :last_name = @input.last_name, :email = @input.email, :password = @input.password) end rescue @errors = [...@company, @user].compact.map(:full_messages).flatten render :errors else redirect Login end But I'm wondering if there's a better way to solve this? // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Reloading in a standard config.ru rack app (Camping 2.0)
¡Holá Señor Gómez!
First of all: *Never* use the reloader in production. It's sloow!
And because config.ru is mostly used for production, the reloader
isn't enabled there.
Why do you want to use the reloader in config.ru instead of
bin/camping by the way? If you want custom middlewares, you can always
do it like this:
module App
user Middleware
end
And you can change the server it uses by `camping -s thin`.
Anyway, if you want to use Camping::Reloader, you can do something like this:
require 'camping'
require 'camping/reloader'
reloader = Camping::Reloader.new('hello.rb')
reloader.on_reload do |app|
app.create if app.respond_to?(:create)
end
app = proc do |env|
# Reload (if needed) at every request:
reloader.reload!
# Returns a hash of the apps:
apps = reloader.apps
# Get the first app:
apps.values.first.call(env)
# If you have several apps, you probably want to
# mount them on different paths instead.
end
run app
If you're on *nix you can also use Shotgun (http://github.com/rtomayko/shotgun):
require 'camping'
Shotgun.after_fork do
Camping::Apps.each do |app|
app.create if app.respond_to?(:create)
end
end
require 'hello'
run Hello
And run the app with: `shotgun config.ru`.
Shotgun spawns your app in each own process at *every* request, so
it's like it's automatically starting and stopping a server between
each request. This means that it's slower, but more correct.
Camping::Reloader keeps everything in the same process, and uses some
Ruby magic to automatically remove objects and load files again. It
work 90% of the times, but is faster (it only reloads when needed) and
it also works on Windows.
Good luck!
// Magnus Holm
2010/8/1 Omar Gómez omar.go...@gmail.com:
Dear Camping ninjas,
I've been using Camping via bin/camping and reloading works as expected OK.
What I have not been able to do is to correctly setup a Camping app
with reloading support in a standard config.ru rack app.
Thanks for your attention
--Omar Gómez
--
Follow me at:
Twitter: http://twitter.com/omargomez
Buzz: http://www.google.com/profiles/108165850309051561506#buzz
___
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: two security questions
Great; sorry for the delay, but I've been here in the last days :-)
http://upload.wikimedia.org/wikipedia/commons/b/bd/Preikestolen_Norge.jpg
// Magnus Holm
On Tue, Aug 10, 2010 at 22:50, David Susco dsu...@gmail.com wrote:
Thanks, that did the trick. Got to comb through my templates now though :P.
On Tue, Aug 10, 2010 at 4:01 PM, Magnus Holm judo...@gmail.com wrote:
David,
As far as I remember, this should work:
module App
set :haml, { :escape_html = true }
end
You set options (as specified in
http://github.com/rtomayko/tilt/blob/master/TEMPLATES.md) by:
set :EXTENSION, { :a= true, :b = false }
// Magnus Holm
On Mon, Aug 9, 2010 at 19:08, David Susco dsu...@gmail.com wrote:
Thanks I'll look into the middleware.
I know that's how you escape HTML in Haml, what am asking though is
how you set the :escape_html option when all you have is an instance
of Tilt.
Dave
On Mon, Aug 9, 2010 at 12:22 PM, Ted Kimble t...@tedkimble.com wrote:
For cross-site request forgery protection I've simply used the
Rack::Csrf middleware before (http://github.com/baldowl/rack_csrf).
The github page is pretty self explanatory.
For Haml, you should just be able to set its :escape_html option to
true and then
%p= @something_nasty
will be escaped by default. See:
http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#escape_html-option
for more info.
Best,
Ted
On Mon, Aug 9, 2010 at 9:15 AM, David Susco dsu...@gmail.com wrote:
Hey guys,
What do people do to protect against cross-site request forgery? To
mimic what rails does I was thinking of creating a unique key for each
session, and then in my logged_in? helper checking if the key passed
by the user matches the one I set in the session.
On the second question, I'm using Tilt with Haml templates. Any idea
how I can set Haml's :escape_html option so each template escapes all
HTML within variables?
--
Dave
___
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
--
Dave
___
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
--
Dave
___
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: two security questions
This example worked here: require 'rubygems' require 'rack/csrf' require 'camping' require 'camping/session' Camping.goes :Hello module Hello use Rack::Csrf include Camping::Session end module Hello::Controllers class Index def get Rack::Csrf.csrf_token(@env) end end end Notice that you'll have to reverse the `use`-lines. Maybe we should file that as a bug? Since it works the other way both in Rackup files and Sinatra? // Magnus Holm On Wed, Aug 11, 2010 at 21:33, David Susco dsu...@gmail.com wrote: Ted, Do you use Camping::Session with Rack::Csrf? If so, how did you get it to work? Once I include Camping::Session the csrf_token changes every time I call the method. Can anyone explain what include Camping::Session is actually doing? Dave On Mon, Aug 9, 2010 at 12:22 PM, Ted Kimble t...@tedkimble.com wrote: For cross-site request forgery protection I've simply used the Rack::Csrf middleware before (http://github.com/baldowl/rack_csrf). The github page is pretty self explanatory. For Haml, you should just be able to set its :escape_html option to true and then %p= @something_nasty will be escaped by default. See: http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#escape_html-option for more info. Best, Ted On Mon, Aug 9, 2010 at 9:15 AM, David Susco dsu...@gmail.com wrote: Hey guys, What do people do to protect against cross-site request forgery? To mimic what rails does I was thinking of creating a unique key for each session, and then in my logged_in? helper checking if the key passed by the user matches the one I set in the session. On the second question, I'm using Tilt with Haml templates. Any idea how I can set Haml's :escape_html option so each template escapes all HTML within variables? -- Dave ___ 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 -- Dave ___ 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: FireFox fix for the camping.js file on the http://camping.rubyforge.org/api.html page
http://github.com/camping/camping/blob/master/extras/rdoc/generator/template/flipbook/js/camping.js Feel free to push directly to camping/camping :-) // Magnus Holm On Sun, Aug 22, 2010 at 17:24, Philippe Monnet r...@monnet-usa.com wrote: The API page does not work in terms of display and section collapsing/expanding in FireFox (but works on IE and Chrome). I fixed the Javascript file by moving up the declaration of the m and s functions. Magnus, if you place the camping.js file on GitHub I will patch it for you. Otherwise I will just email the file so that RubyForge can be updated. Philippe (@techarch) ___ 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: making create environmentally aware
Why don't add this? def App.create(env = :development) end And in production, you can call App.create(:production) yourself. // Magnus Holm On Tue, Aug 24, 2010 at 15:36, David Susco dsu...@gmail.com wrote: Not talking about having it recycle (I assume all Camping apps have a small carbon footprint). I'm talking about letting the create method know this is the dev/test/prod environment and have it load the appropriate database connection info etc. Any thoughts on this? Having create take an env arguments seems the simplest to me. -- Dave ___ 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: making create environmentally aware
What about this: def App.create(env = (ENV['CAMPING_ENV'] || :development)) end Then you can simply set ENV['CAMPING_ENV'] = test before loading any tests. // Magnus Holm On Tue, Aug 24, 2010 at 16:21, David Susco dsu...@gmail.com wrote: Ya, that's what I'm doing. Just wondering if there was another way to go about it. I modified your camping-test/base file to call 'create :test' and specified a test db adapter in my config file to get around the problem I e-mailed you about. Dave On Tue, Aug 24, 2010 at 9:44 AM, Magnus Holm judo...@gmail.com wrote: Why don't add this? def App.create(env = :development) end And in production, you can call App.create(:production) yourself. // Magnus Holm On Tue, Aug 24, 2010 at 15:36, David Susco dsu...@gmail.com wrote: Not talking about having it recycle (I assume all Camping apps have a small carbon footprint). I'm talking about letting the create method know this is the dev/test/prod environment and have it load the appropriate database connection info etc. Any thoughts on this? Having create take an env arguments seems the simplest to me. -- Dave ___ 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 -- Dave ___ 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: Oh, whywentcamping.com!
Awesome work, Jenna :-) One issue: The code blocks doesn't show properly on GitHub: http://github.com/camping/camping/wiki/Book:-Getting-Started Not sure what's the best way to handle this. We should at least indent all the code blocks with 4 spaces (so they end up as Markdown pre tags), and somehow tag them as Ruby for whywentcamping.com We should probably update the RDoc template at camping.rubyforge.org, but I'm also open for re-thinking the reference section all-together. Is it really useful in its current form? // Magnus Holm On Tue, Aug 24, 2010 at 15:31, Jenna Fox a...@creativepony.com wrote: I'm feeling pretty happy about the state of the website now! http://whywentcamping.com/ And the blog to go with it http://log.whywentcamping.com/ What's the next thing? work on the api reference? write more content? Is there any other camping stuff which would benefit from my dodgy doodling attentions? — Jenna ___ 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: Forcing a Response Status-Code of 40x
@status = 404 // Magnus Holm On Sun, Oct 3, 2010 at 18:09, Raimon Fernandez co...@montx.com wrote: Hi again, I'm trying to force a different Response Status-Code when some situations occur. Once again, in Rails I just use the :status = 404 and that's all ... Here, I suppose I must use the @headers[] but I'm always getting the 200 Status OK. I'm not sure wich name exactly the header must be, as in Internet there are lots of options and none of them is giving me a 404 or whatever code I use, I'm always getting the 200. If I force a bad url, camping returns the famouse Camping problem with a 404 status code, I want to force this code. How can I do that ? ... @headers[Content-Type] = text/xml # none of them are working ... @headers[HTTP/1.0] = 404 @headers[Status] = 404 @headers[Response] = 404 @headers[Status-Code] = 404 maybe I have to use a different option in camping ? thanks again, regards, r. ___ 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: Forcing a Response Status-Code of 40x
There's some info about the request/response here: http://camping.rubyforge.org/api.html#class-Camping-Controllers // Magnus Holm On Sun, Oct 3, 2010 at 22:47, Raimon Fernandez co...@montx.com wrote: Thanks John Magnus, Where I can find more info about those little magic :-) Also, I was calling from the wrong place, in a helper it is not working, but works if I call from a Controller. thanks again, regards, r. On 3oct, 2010, at 18:22 , John Beppu wrote: @status = 404 On 3oct, 2010, at 18:21 , Magnus Holm wrote: @status = 404 ___ 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: First Contact and a few doubts
Hey Marcos,
1) You can search the mailing list at
http://www.mail-archive.com/camping-list@rubyforge.org/
2) http://whywentcamping.com/ is probably the most official one (since it's
linked to the wiki).
3)
Ah, you've discovered the first magic of Camping!
R is simply a method which returns a class:
https://github.com/camping/camping/blob/cf1dd6162d95f798190b/lib/camping-unabridged.rb#L526-L532
Another example (which you can play with in IRB):
def C(name)
Class.new { defined_method(:name) { name } }
end
class Index C 'my name'
end
Index.new.name # = 'my name'
// Magnus Holm
On Sun, Nov 7, 2010 at 14:16, Marcos Ricardo marc_...@hotmail.com wrote:
Hi Folks,
This is my first contact, and I have a few doubts.
1 - I was looking for a specific subject (see below), but couldn't find a
way to search the list by topic.
Does this list have a search function? How to use it?
2 - I have seen more then one Camping Home Page and I'm not sure which
one is THE ONE.
3 - My specific doubt is about This piece of code:
class Index R'/'
Can some one explain it deeply?
What exactly is the Index class inheriting this way?
Thanks in advance.
--
Marcos Ricardo (www.marcric.com)
(R)mr(R)
View my LinkedIn profile http://www.linkedin.com/in/marcric
___
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: Rubyconf
I'm unfortunately not at RubyConf :-( Maybe next year? // Magnus Holm On Thu, Nov 11, 2010 at 17:12, Dave Everitt dever...@innotts.co.uk wrote: Anyone going to http://rubyconf.org/ wearing a 'Camping' t-shirt? ___ 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: Strange error with no stack trace
Hm…
Like Dave mentioned, could you give us the versions you're using? For
both Camping, Rack, Tilt, Haml and Ruby? Also, you could add this
little snippet to force a backtrace:
class NilClass
def to_sym
puts NilClass#to_sym:
caller.each do |line|
puts #{line}
end
raise
end
end
Maybe that gives you any clues!
// Magnus Holm
On Thu, Jan 20, 2011 at 06:14, adam moore nerdf...@gmail.com wrote:
Hello there!
Been loving getting stuck in creating bits bobs with this
wonderful little framework. Had a go at making a listing of a bunch of
opening events which occur in my current city of residence - Tokyo.
Unfortunately, although the app seemed to be fine running locally (in
production), once pushed to Heroku I began to see intermittent
occurrences of:
!! Unexpected error while processing request: undefined method
`to_sym' for nil:NilClass
just as the app reached rendering the (haml) view.
The problem is, there is no stack trace which is spit out at this
point - and any puts I have added to the view to check things are ok,
are never reached. I have a hunch that this may be to do with haml /
tilt not starting up in time but was wondering if there's a way to
make production camping apps more verbose, or if this is needed at
all.
Thank you all.
--
=^.^=---
___
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: Strange error with no stack trace
On Friday, January 21, 2011, adam moore nerdf...@gmail.com wrote: Wow, thanks Magnus. Adding that certainly made the output more interesting: http://pastebin.com/DSMKWK52 As you can see, the ruby version seems to be 1.8. It can be bumped up to 1.9 I believe if this is preferred? drinking.rb line 127 is simply: render :index The plot thickens... But soon the mystery will unfold itself! Could you list all the filenames in your views-directory? It seems that Camping fails to extract the extension of the index template. I'm just puzzled why it works locally but not on Heroku. Also, try to evaluate this on Heroku's console: filename[/\.(\w+)$/,1] (where filename is the filename of the index template). -- // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Strange error with no stack trace
On Friday, January 21, 2011, adam moore nerdf...@gmail.com wrote: Wow, thanks Magnus. Adding that certainly made the output more interesting: http://pastebin.com/DSMKWK52 As you can see, the ruby version seems to be 1.8. It can be bumped up to 1.9 I believe if this is preferred? drinking.rb line 127 is simply: render :index The plot thickens... But soon the mystery will unfold itself! Could you list all the filenames in your views-directory? It seems that Camping fails to extract the extension of the index template. I'm just puzzled why it works locally but not on Heroku. Also, try to evaluate this on Heroku's console: filename[/\.(\w+)$/,1] where filename is the filename of the index template. -- // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Strange error with no stack trace
We're getting closer! Try this from both locally and on Heroku: Dir[src/views/index.*].first My prediction: it returns index.haml locally and index.haml~ on Heroku. Therefore Camping fails to extract the extension on Heroku. Solution: delete all ~-files (and add *~ to gitignore). I'll also make the extraction code a little leas fragile to files which have weird extensions. On Friday, January 21, 2011, adam moore nerdf...@gmail.com wrote: With burning ears I link to you the git repository : http://github.com/minikomi/tokyoartparties Be gentle haha ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list -- // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: update breaks hello clock?
A better solution is to actually upgrade to 1.8.7 (which is actively maintained)
// Magnus Holm
On Wed, May 18, 2011 at 18:15, Dave Everitt dever...@innotts.co.uk wrote:
Thanks Magnus - downgraded Rack to 1.2.0 after trying Git version.
For the benefit of anyone else reading this:
Tried the 1.8.6 compatibility-fixed version of Rack:
git clone git://github.com/sferik/rack.git
cd rack
rake test
(in /Users/deveritt/src/rack)
bacon -I./lib:./test -w -a -q -t
'^(?!Rack::Adapter|Rack::Session::Memcache|rackup)'
sh: line 1: bacon: command not found
rake aborted!
Command failed with status (127): [bacon -I./lib:./test -w -a -q -t
'^(?!Rack...]
/Users/deveritt/src/rack/Rakefile:74
So (no time to dig further into the above, and most recent Rack was 1.1.0 on
machine in question) just did:
sudo gem install -v 1.2.0 rack
sudo gem uninstall -v 1.2.2 rack
Everybody's Camping happily again :-)
Dave
Seems like Rack 1.2.2 (and 1.2.1) no longer supports 1.8.6. It's fixed
in Git, but I'm not sure when a new version will be released:
https://github.com/rack/rack/pull/145
You can downgrade to 1.2.0 for now.
// Magnus Holm
On Wed, May 18, 2011 at 12:44, Dave Everitt dever...@innotts.co.uk
wrote:
Just did a quick gem update, including Camping 2.1, and ran 'Hello Clock'
(http://camping.rubyforge.org/book/02_getting_started.html) as a quick
test:
deveritt$ camping nuts.rb
/usr/local/lib/ruby/gems/1.8/gems/rack-1.2.2/lib/rack/utils.rb:138:in
`union': can't convert Array into String (TypeError)
from
/usr/local/lib/ruby/gems/1.8/gems/rack-1.2.2/lib/rack/utils.rb:138
from
/usr/local/lib/ruby/gems/1.8/gems/camping-2.1/bin/../lib/camping.rb:3
from
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
`gem_original_require'
from
/usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
`require'
from /usr/local/lib/ruby/gems/1.8/gems/camping-2.1/bin/camping:5
from /usr/local/bin/camping:19:in `load'
from /usr/local/bin/camping:19
Any ideas? Worked fine with 2.0.392 -
Camping.goes :Nuts
module Nuts::Controllers
class Index R '/'
def get
@time = Time.now
render :sundial
end
end
end
module Nuts::Views
def layout
html do
head do
title { Nuts And GORP }
end
body { self yield }
end
end
def sundial
p The current time is: #{@time}
end
end
Dave
___
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
___
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: anyone run into this activerecord error before?
It seems that you need to establish a connection *before* you write your models. Doesn't seem to be a way around it :/ // Magnus Holm On Tue, May 24, 2011 at 19:53, David Susco dsu...@gmail.com wrote: Not really Camping specific, but I've always had better luck asking on this list than any of the rails ones. I'm trying to upgrade from activerecord 2.3.8 to 3.0.7 and I'm getting a ActiveRecord::ConnectionNotEstablished error when the has_and_belongs_to_many association is being used. A simple example is attached, and the stack follows. Has anyone run into this before? !! Error loading /var/www/apps/arg/arg.rb: ActiveRecord::ConnectionNotEstablished: ActiveRecord::ConnectionNotEstablished /usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/connection_adapters/abstract/connection_pool.rb:317:in `retrieve_connection' /usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/connection_adapters/abstract/connection_specification.rb:97:in `retrieve_connection' /usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/connection_adapters/abstract/connection_specification.rb:89:in `connection' /usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/associations.rb:1806:in `create_has_and_belongs_to_many_reflection' /usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/associations.rb:1411:in `has_and_belongs_to_many' /usr/local/lib/ruby/gems/1.9.1/gems/activerecord-3.0.7/lib/active_record/autosave_association.rb:137:in `has_and_belongs_to_many' /var/www/apps/arg/arg.rb:16:in `class:Assembly' /var/www/apps/arg/arg.rb:15:in `module:Models' /var/www/apps/arg/arg.rb:14:in `top (required)' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/reloader.rb:60:in `load' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/reloader.rb:60:in `load_apps' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/reloader.rb:105:in `reload!' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/reloader.rb:180:in `block in reload!' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/reloader.rb:179:in `each' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/reloader.rb:179:in `reload!' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/reloader.rb:158:in `update' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/server.rb:157:in `find_scripts' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/server.rb:161:in `reload!' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/server.rb:169:in `call' /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/lint.rb:48:in `_call' /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/lint.rb:36:in `call' /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/showexceptions.rb:24:in `call' /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/commonlogger.rb:18:in `call' /usr/local/lib/ruby/gems/1.9.1/gems/camping-2.1/lib/camping/server.rb:242:in `call' /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/content_length.rb:13:in `call' /usr/local/lib/ruby/gems/1.9.1/gems/rack-1.2.2/lib/rack/handler/webrick.rb:52:in `service' /usr/local/lib/ruby/1.9.1/webrick/httpserver.rb:111:in `service' /usr/local/lib/ruby/1.9.1/webrick/httpserver.rb:70:in `run' /usr/local/lib/ruby/1.9.1/webrick/server.rb:183:in `block in start_thread' !! Error loading /var/www/apps/arg/arg.rb, see backtrace above 127.0.0.1 - - [24/May/2011 13:45:00] GET / HTTP/1.1 404 45 0.9436 -- Dave ___ 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
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
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?
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: Feature: Inline templates?
On Aug 26, 2011 6:42 PM, Bartosz Dziewoński matma@gmail.com wrote: If this only supports Erb, then we should throw it away as fast as possible ;) I see no reason why would anyone want to use something *that* dinosauric in a new project. If it also supports (or can support), say, Haml, then I see how it could be useful (although nearly all of my Camping projects end up split between many files anyway ;) ). Personally I love Markaby, but for many people it might look weird, and I can understand why. -- Matma Rex It supports everything that Tilt supports. See http://github.com/rtomayko/tilt. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Using CouchDB in Camping - looking for advice
On Mon, Aug 29, 2011 at 05:39, Daniel Bryan danbr...@gmail.com wrote: Woah, that sounds pretty cool. Are you using RubyParser or Ripper? Neither. I'm using sourcify ( http://rubydoc.info/gems/sourcify/0.5.0/frames ) to convert blocks into an S Expression, and then my own library to parse that and spit out equivalent JavaScript syntax. I've made no attempt to deal with Ruby syntax that has no direct JS equivalent (like block arguments to function calls), nor to capture operations that would be illegal in JavaScript - https://github.com/cerales/ShyRubyJS Very interesting! What if you introduce the concept of *contexts*? So all CouchDocument are automatically one context (that only include one type of document), but you can also introduce your own contexts. So you can have a CookingUser-context, which describes a User and what he can do with Receipes. In your controller you can say `CookingUser.new(current_user).untried_recepies`. Or maybe a UserReceipes which has an untried-view. So contexts are just a lightweight class where you can place your views. The developer has to decide what the context should be called and how they should work. The point is that the contexts should mirror the use-cases of the data, and as there might be many ways to look at the same data, you can't have an automatic way of saying where the view belongs. It all depends on the point-of-view. I like this! The way I'm interpreting this is that contexts could be a really light layer on top of the anonymous views. So it'd have your abstract view specification - a map block and a view block - and then a couple of little links specifying, for example, which model classes / kinds it's associated with, for the sake of the developer's sanity. When I started development on this concept, I put a lot of thought into how models would be written, to the point that they became effectively a schema. I realised that that was absurd - anything heavier than the optional needs and suggests concepts is throwing away the agility, convenience and forgiveness of a NoSQL approach. So that's out the window, but there's still a challenge here - model schemas, as well as being a concession to the brutality of SQL and its greedy demands, are a very useful tool for keeping track of and self-documenting your application. It seems there needs to be some kind of tool to replace that if your'e doing something like this. The truth is that there is no such thing as schema-less. There will always be a schema. The question is if it will be enforced in the database, at insert-time in code (each document has a strict schema) or at runtime in code (it works just as a Hash). So what I'm thinking might be useful is some kind of optional admin interface that will look at your Models and your Views and your Contexts, and try to visualise or contextualise them in some way. Like the django admin interface, with all the power of introspection, but somehow groovy. Of course, it's so _easy_ to work with data when it's just JSON documents that there's no reason you couldn't, with a little thought, build a super user-friendly interface where you build your MapReduce views just by being given a graphical view of your document Kinds and dragging and dropping things into the fields for what you want to emit, what you want to filter, etc. It's probably not the best idea philosophically, but for giving people the tools to really easily write a dynamic web app it seems like it could be useful. I've been thinking about the exact same concept, but a more general solution based on relational algebra. My idea was that you defined your schema, relationships and queries in an admin-panel thingie (inspired from Yahoo! Pipes) in a database-agnostic way (relational model), and then later defined the mapping from the database (which could be CouchDB, MongoDB, MySQL, Redis) to the conceptual schema. I'd say your project is more limited, but way more feasible than my big plan. So I think you should definitely go for it and make a kick-ass CouchDB platform :-) ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: What is the Best Way to Install Camping in 2011?
On Wed, Sep 7, 2011 at 16:00, Ed Heil edh...@fastmail.fm wrote: And that turned out to be fixable with a global search and replace of 00:00:00.0Z to in my gemspecs. Rock. :) Great! Feel free to bother us more if you encounter more problems :) ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: failing test
Pretty sure this is related to incompatability with the latest Rack (which suddenly slightly broke the Session-API). It's fixed in latest master. Maybe we should just do a release soon. // Magnus Holm On Sat, Sep 24, 2011 at 22:22, Paul van Tilburg p...@luon.net wrote: Hi! I am in the process of packaging Camping 2.1 for Debian. While renewing the entire packaging structure I wanted to integrate the tests in the build procedure. However, surprisingly, one of the tests (apps) fails (I require test/app*.rb): Started ..F Finished in 0.057194 seconds. 1) Failure: test_session(Sessions::Test) [./test/test_helper.rb:41:in `assert_body' ./test/app_sessions.rb:44:in `test_session']: [42, 56, 99] expected but was [nil, nil, 99]. 15 tests, 17 assertions, 1 failures, 0 errors That result is quite surprising. Redirecting does not preserve state? Or is this a desired change since 2.1 and the test has not been fixed since? Paul -- PhD Student @ Eindhoven | email: p...@luon.net University of Technology, The Netherlands | JID: p...@luon.net Using the Power of Debian GNU/Linux | GnuPG key ID: 0x50064181 ___ 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?
2011/9/24 Bartosz Dziewoński matma@gmail.com: So, are we reverting it? It's still in the latest GitHub commit. I've reverted it. ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Maintenance release of 2.1
I'm thinking of releasing 2.1.458 which includes a few more features (better cookie support, inline templates etc), but mainly to fix some incompatibility issues with Rack. I'm not going to document the new features yet, so consider them experimental in this patch-release. As for the version, it's currently MAJOR.MINOR.REV where REV = number of commits since the beginning. It works pretty well to use REV as a part of the version number because I can then easily throw out experimental releases to my gem server without screwing up the version number. However, from 2.2 I'm thinking of changing REV to number of commits since previous release, simply to avoid some high revision numbers. Thoughts? Okay with a little maintenance release? Okay with some undocumented experimental features? Okay with REV? Okay with decreasing REV a bit= // Magnus Holm ___ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
Re: Feature: Inline templates?
2011/9/24 Bartosz Dziewoński matma@gmail.com:
A comment after some time: I'd appreciate it more if I could just have
one external file with all the templates, and one with the Camping
code, and I could link in the templates to parse using this
mechanism.
This works, although it's kinda hacky:
eval('Camping.goes :Foo', nil, 'templates.rb')
On Fri, Aug 26, 2011 at 16:14, Dave Everitt dever...@innotts.co.uk wrote:
Since no-one has replied, for what it's worth (as a very amateur camper),
I've always been happy with simple regular Markaby views and the v2.1
options for external templates. Also, my modest one-file apps have their CSS
after __END__. In any sizeable app, you'd probably want to have separate
templates for easier maintenance (since - if inline - their code is going to
add more than a few lines and break the one-file advantages), so the
question is: will anyone use/want inline templates? - DaveE
I've committed another patch (8b6fee67). Now you can serve static files too:
__END__
@@ /style.css
* { margin: 0; padding: 0; }
It also sets the correct MIME type.
The only thing I worry about now is that it's taken a lot of bytes.
We're currently at 3976 (97%) bytes.
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list
