Re: css image url's and :img problem

2007-11-18 Thread Magnus Holm
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

2008-05-20 Thread Magnus Holm
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++

2008-05-22 Thread Magnus Holm
 If you're going to build cookie sessions in to the core, it should either do
 the rails thing of using multiple cookies when one is not enough for the
 data, or raise a descriptive exception explaining why there's a problem and
 how switching to the database sessions thingo will solve that.

Cookie Sessions: I think we should simply raise an error when the data is
larger than 4kB. Something is wrong when the cookie is larger than the
framework you're using.

 I totally agree with ditching the compressed version so long as there are
 new guidelines put in place as to how much camping is too much camping. We
 still need to fit it in our backpacks.

 It would also be good if you continue to maintain some easy way to do the
 compression, so people who do care about size can get a smaller version.
 Someone might want to take camping with them everywhere they go in the form
 of a 3D barcode, loadable via the camera's on mobile phones and many
 computers, or maybe they've been running their website on a server they can
 only reach via TCP over Carrier Pigeon and it's important to them that they
 can upload camping.rb with the fewest pigeons possible.

Perlvert that I am, I respected the 4KB obfuscation.  (Maybe that's just me.  
;-)

It's alright for me to keep the compressed version, but can it live under
camping-compressed.rb (or something like that) and have the real version
under camping.rb?

 Does Rack::Utils give us nice short easy escaping? Can we include in to
 camping in a way that they are just nice short methods?

Rack::Utils gives us nice short easy escaping through Rack::Utils.escape and
Rack::Utils.unescape. Creating helper-methods will just cost bytes...

 As long as you organize the code such that it's easy to switch between
 session storage schemes, I think this is fine.

I've created a branch (orm_agnostic) where I've moved db.rb - ar.rb and
session.rb - ar/session.rb so you can plug in whatever you want.

--
Right now I have spread the code around three branches (rack, cookie_session
and orm_agnostic). Just tell me which we need, and I'll merge/rebase them to
the master for easy merging with why's repo (so you guys can continue to hack
with it).

Oh, and the documentation of session needs some cleanup, but I suck at
documentation so I'll leave it to you :-)
-- 
Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Rack, Camping 2.0++

2008-05-22 Thread Magnus Holm
I must agree that the obfuscation is really impressive (specially in a
presentation
where you can include the full source on one slide). I just don't like
to touch it.
And unfortunately it doesn't evolve by itself.

I'm just tired of renaming camping-unabridged.rb to camping.rb in order to test
the apps, and then back again when I commit stuff.

I'll be perfectly fine if someone else creates the obfuscated version :-)

On Thu, May 22, 2008 at 5:50 PM, _why [EMAIL PROTECTED] wrote:
 On Fri, May 23, 2008 at 07:27:18AM +1930, Aníbal Rojas wrote:
  ===
  4. Renaming camping-unabridged.rb to camping.rb?
  ===
 
  I haven't touched camping.rb at all, do we really need to prove that it's a
  micro-framework? It just makes development/releasing harder. Let's just 
  forget
  about the abridged version and rename camping-unabridged.rb to camping.rb!

 Keeping Camping away from the bloat goes far beyond an arbitrary weight 
 limit.
 It is a nice way to promote Camping. It is catchy saying In Less then
 4K, period.

 Instead of saying the obfuscation just makes development/releasing harder,
 try saying obfuscation just makes flippancy/esotericism easier.

 _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: obfuscation Re: Rack, Camping 2.0++

2008-05-23 Thread Magnus Holm
The problem is that almost all app require 'camping' and when bin/camping
require 'camping-unabridged' things gets pretty messy.

(I just realized that bin/camping could monkey-patch require such that when
the --unabridged-flag is set it require 'camping-unabridged' instead of
'camping'. But that's *really* dirty!)

On Fri, May 23, 2008 at 12:07 PM, zimbatm [EMAIL PROTECTED] wrote:
 2008/5/22 Ernest Prabhakar [EMAIL PROTECTED]:
 So, it sounds like there's a few options:

 a) Automate the creation of the obfuscated version from the unabridged
 version

 Last time I checked, Ruby2Ruby didn't recognize all camping constructs
 but it might be better now.

 b) Tweak the system to run from camping-unabridged.rb (or a short name
 thereof, e.g. campsrc)

 bin/camping could easily be tweaked to add a --unabridged command-line flag

 c) Make the obfusc version camping4k, and make camping-unabridged.rb the
 default camping.rb

 Ugh !
 ___
 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: An issue for consideration

2008-05-23 Thread Magnus Holm
Good find!

1. If you run that on a real HTTP server (Apache, Nginx etc.) it will
just ignore it.
  Remember that  Mongrel/Thin should be served behind a proxy and are lazy
  about checking valid request.

2. A cool thing with the Rack-rewrite is that you can use Rack::Lint to validate
  the request/response according to the Rack-spec. So that will just raise:

Rack::Lint::LintError: REQUEST_METHOD unknown: FOO

3. I'm adding Rack::Lint as a middleware in bin/camping such that it's safe in
  development. If you're running Mongrel/Thin without proxy (madness!), you
  should also use Rack::Lint.

Do you think we should add a protection inside Camping too?

On Fri, May 23, 2008 at 6:46 AM, Bluebie, Jenna
[EMAIL PROTECTED] wrote:
 We've just come across an issue for consideration. I am avoiding some words
 which would allow people to find this message in an internet search who have
 questionable intentions, but wish to communicate a strong sense of caution.
 Consider someone who adds extra methods to their controller which they use
 in their main get/post methods to do things or to get secret data. Consider
 now, this http request:

 FOO / HTTP/1.1

 And consider that camping allows methods to return a string and have that
 returned as a body. This could make for a lovely convenient form of RPC, but
 to those unaware, it seems there could be negative results. Aria has
 discovered with some testing that it is also possible to access helper
 methods remotely in this way, which is especially worth consideration as
 some of us use helper methods to do important things, and do not expect them
 to be directly accessible to the outside world.
 In my own app, I will be using a service to filter all requests which don't
 use a standard http method. I'd like to suggest that in the next release of
 camping, we could do something like return unless ['GET', 'POST', 'DELETE',
 'HEAD'].include?(request_method), perhaps in the run method of camping. Or
 maybe we could raise an error. I'd also appreciate it if this update were
 deployed to rubygems servers without haste. I'll be sure to post the service
 I write to work around this issue just as soon as I'm done writing it.

 —
 Thoughtful Pony
 ___
 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++

2008-05-23 Thread Magnus Holm
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++

2008-05-24 Thread Magnus Holm
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?

2008-05-24 Thread Magnus Holm
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?

2008-05-25 Thread Magnus Holm
You're absolutely right. Not anymore, though. I fixed in my cs-branch.
Now it will save the data in three cookies: camping_blob, camping_hash
and camping_time. The secure_blob_hasher includes the remote IP and
the user agent, and it has also a timeout on 15 minutes (which can be overridden
with @@state_timeout).

http://github.com/judofyr/camping/commits/cs

On Sun, May 25, 2008 at 5:43 AM, _why [EMAIL PROTECTED] wrote:
 On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:
 * The cookie session is named Camping::Session and is placed in
 camping/session.rb. Maybe this should be called Camping::CookieSession or???

 You know, these cookie sessions seem like they could be a problem.
 A lot of sessions would contain just the hash and the user name.
 So, spoof the user name and you're in, you know?

 _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: Camping 2.0 - What's left?

2008-05-25 Thread Magnus Holm
So there isn't really any way to be safe against XSS and at the same
time support
all users? Then ignore my patch, and we should just make it clear
that the data
is in clear-text within the cookie and you must be very careful with
validating the
input.

On Sun, May 25, 2008 at 3:04 PM, Bluebie, Jenna
[EMAIL PROTECTED] wrote:
 That's no good, a significant amount of ISP's do not route requests from one
 user to one web host via the same routes on each request, and when they use
 proxy servers, as AOL does, that means every request comes from a different
 IP address, even though it's the same user. Worse still, the IP addresses of
 the proxy server's are located all around the world, so even geolocation
 fails.

 Ditch the remote IP check or it wont work at all for a lot of users. I also
 feel 15 minutes is dodgy. I like session cookies, not timed cookies. The
 user closes the browser and the cookie dies, nice and simple. If you want to
 use a timeout, how about something that wont have any real downsides like a
 day or two?

 The user agent is probably safe, but some plugins add text to the user
 agent, so if the user upgrades flash for instance, the session is instantly
 voided and unusable as flash's version number will change.

 The only one of these which limits usefulness of cookie stealing to
 attackers is the IP check which is totally unusable in the real world
 internet. Timeouts are just annoying and I don't think extremely high
 security apps which would suit 15 minute timeouts are really the target
 audience of Camping.


 —
 Jenna

 On 25/05/2008, at 10:45 PM, Magnus Holm wrote:

 You're absolutely right. Not anymore, though. I fixed in my cs-branch.
 Now it will save the data in three cookies: camping_blob, camping_hash
 and camping_time. The secure_blob_hasher includes the remote IP and
 the user agent, and it has also a timeout on 15 minutes (which can be
 overridden
 with @@state_timeout).

 http://github.com/judofyr/camping/commits/cs

 On Sun, May 25, 2008 at 5:43 AM, _why [EMAIL PROTECTED] wrote:

 On Sun, May 25, 2008 at 12:25:08AM +0200, Magnus Holm wrote:

 * The cookie session is named Camping::Session and is placed in
 camping/session.rb. Maybe this should be called Camping::CookieSession
 or???

 You know, these cookie sessions seem like they could be a problem.
 A lot of sessions would contain just the hash and the user name.
 So, spoof the user name and you're in, you know?

 _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

 ___
 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: Camping 2.0 - What's left?

2008-05-25 Thread Magnus Holm
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


Messy Cookies

2008-06-06 Thread Magnus Holm
It looks like everyone has tried to fix the cookies lately, and no-one managed
to get it 100% correctly.

The current implementation doesn't set the path correctly, and you can't use
@cookies in a #service-overload.

Qwzybug's patch fixed only the sessions.

Jenna's patch won't allow to set complex cookies (@cookies.key = {:path =
/path, :value = value, :expires = Time.now + 900}) and won't work
properly when you use #method_missing (which allows you to do
Blog.get(:Controller)).

So I took Bluebie's code and rewrote it a bit. I moved some logic (which
currently is in #service) from #call to Base#to_a. So even if you're not using
Rack, you need to call #to_a in order to clean things up.

The code is available in the proper_cookie-branch:
http://github.com/judofyr/camping/commits/proper_cookies

I've tested it with Firefox + LiveHTTPHeaders and it seems to work fine. If
anyone spots a bug, please comment on a commit (or scream out on IRC)!

Oh, and _why has to decide if we should make the session-system completely
XSS-proof, or be a little more relaxed. It doesn't have to be XSS-proof as
long as you keep the cookies secret (aka, escapes all Javascript).

--
Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Getting rid of the route maker

2008-06-22 Thread Magnus Holm
The route maker's job is basically two things:
- Make sure that all controllers includes the right mixins
- If any controllers doesn't respond to urls (aka. haven't been inherited
  from R) define urls as ClassName.downcase

The first point can be accomplished within R, but not the latter. But it
should be noted that the latter also can cause some troubles. It's assuming
all constants under Controllers are class and all should be publicly
accessible:

module Camping::Controllers
  LIMIT = 6
  # Ops! Crashing time!

  class HiddenStuff;end
  # Ops! Hacking time!
end

By removing the route maker you must explicitly define controllers by
inherited it from R:

module Camping::Controllers
  class Posts
  end
  # No longer working!
  # Stick with this:
  class Posts  R '/posts'
  end
end

What do you think? (It's also 135 bytes smaller). Code available here:
http://github.com/judofyr/camping/tree/no_route_maker

--
Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Getting rid of the route maker

2008-06-24 Thread Magnus Holm
Man, that's way better than removing 135 bytes! I *love* the implementation!

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!

On Tue, Jun 24, 2008 at 12:14 AM, _why [EMAIL PROTECTED] wrote:
 On Mon, Jun 23, 2008 at 12:16:35AM +0200, Magnus Holm wrote:
 The route maker's job is basically two things:
 - Make sure that all controllers includes the right mixins
 - If any controllers doesn't respond to urls (aka. haven't been inherited
   from R) define urls as ClassName.downcase

 The first point can be accomplished within R, but not the latter. But it
 should be noted that the latter also can cause some troubles.

 Or, maybe, instead of getting rid of #2 we could make it go a bit
 beyond just downcasing to help steer us away from regexps.

  module Blog::Controllers
class Index # automatically '/'
  def get; end
end

class ViewN # automatically '/view/(\d+)'
  def get id; end
end

class ViewX # automatically '/view/(\w+)'
  def get name; end
end

class ViewYMD # automatically '/view/(\d+)/(\d+)/(\d+)'
  def get time; end
end
  end

 _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: Getting rid of the route maker

2008-06-24 Thread Magnus Holm
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

2008-06-24 Thread Magnus Holm
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

2008-07-14 Thread Magnus Holm
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

2008-07-16 Thread Magnus Holm
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

2008-07-16 Thread Magnus Holm
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: Troubleshooting: Camping 2.0 on CGI on a shared host

2008-07-18 Thread Magnus Holm
1. It doesn't work well when you try to mount it on a sub-directory
2. SCRIPT_NAME should be empty when it's mounted on root (even though
Camping can handle it).
3. REQUEST_URI contains query string too. What about
env['REQUEST_URI'].gsub(/\?.*/,'')?

It's not really a portable solution, so I don't think we should
publish this all over the internet, but it's good to hear that it's
working for you :-)

--

It seems that (almost) everything I said earlier was wrong: Now
PATH_INFO is suddenly / (I could have swear that it was gone!) And the
reason I got REDIRECT_SCRIPT_NAME was because I had a SetEnv
SCRIPT_NAME /sub in my .htaceess...

It also looks like it's impossible to auto magically detect what the
proper SCRIPT_NAME should be. I guess the hack should be put into
dispatch.cgi. What about this? http://pastie.org/236889

On Thu, Jul 17, 2008 at 2:08 AM, Eric Mill [EMAIL PROTECTED] wrote:
 OK, I am good to go, working CGI and FastCGI .htaccess and dispatch.*
 files written.  I changed REDIRECT_URI to REQUEST_URI.

 For CGI:
 * dispatch.cgi: http://pastie.org/235313
 * .htaccess for CGI: http://pastie.org/235315

 For FastCGI, based on the above:
 * in dispatch.cgi, change Rack::Handler::CGI.run to be
 Rack::Handler::FastCGI.run
 * in .htaccess change dispatch.cgi to be dispatch.fcgi

 Awesome.  Thanks for everyone's help.  Especially Magnus and Jenna,
 you two rule.

 This seems like a good candidate for the github Camping wiki -- do
 people even know that thing exists, is it worth it?  Or should I just
 add it to the Camping wiki on why's site?

 -- Eric

 On Wed, Jul 16, 2008 at 6:13 PM, Eric Mill [EMAIL PROTECTED] wrote:
 The 500-handling I'm used to appears to be gone.  What's the best approach 
 here?

 -- Eric

 On Wed, Jul 16, 2008 at 6:08 PM, Eric Mill [EMAIL PROTECTED] wrote:
 I think I've got it working, with this as the 'fixer' call:

  def call(env)
env['SCRIPT_NAME'] = '/'
env['PATH_INFO'] = env['REDIRECT_URL']
@app.call(env)
  end

 I think you might have meant REDIRECT_URL and not REDIRECT_SCRIPT_NAME?

 Thank you Magnus!

 -- Eric

 On Wed, Jul 16, 2008 at 5:51 PM, Eric Mill [EMAIL PROTECTED] wrote:
 Also worth noting is that PATH_INFO isn't emptied - it's set to / or
 /login, the correct request path.

 -- Eric

 On Wed, Jul 16, 2008 at 5:40 PM, Eric Mill [EMAIL PROTECTED] wrote:
 Unfortunately this isn't working.  I'm checking my ENV and
 REDIRECT_SCRIPT_NAME isn't set to anything.  I'm using the Rack spec
 to try to figure out an alternative.

 Right now, requests to / go to a Camping error page which says
 /index.html not found!  and requests to /login (which should go to
 a different controller) says /login.html not found!.  PATH_INFO has
 been set to /login.html in this case.

 I also tried setting SCRIPT_NAME to be whatever REQUEST_URI is, but
 this has the same effect as using the REDIRECT_SCRIPT_NAME approach.

 Continuing to investigate,
 Eric

 On Wed, Jul 16, 2008 at 5:31 PM, Magnus Holm [EMAIL PROTECTED] wrote:
 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

Re: AR Sessions

2008-07-19 Thread Magnus Holm
It looks like a bug in 2.1.0. For now, you should stick 'gem
activerecord, =2.0.2' at the top of your app :-)

On Thu, Jul 10, 2008 at 5:01 PM, Joshua Miller [EMAIL PROTECTED] wrote:
 Hi all,

 I have a little camping micro-blog that's working well with the cookie
 session store, but falls over when I try to use the AR session store.
 The changes I made were:

 require 'camping/session' becomes require 'camping/ar/session'

 module Blog; include Camping::Session; end becomes module Blog;
 include Camping::ARSession; end

 and I did the create_schema in Blog.create.

 It set up the session table correctly, it adds a new row with a
 session id and sets a cookie on the browser correctly, but it never
 saves anything to the session state hash.  Do I need to do something
 differently to make @state save itself?  Using the cookie session
 store, changes are saved anytime I do something to @state, which is
 how I would expect it to work.

 I'm using the latest version from why's git repo with the default sqlite 
 setup.

 Thanks!
 Josh
 ___
 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


Preview: Camping Explained

2008-07-20 Thread Magnus Holm
I'm going to start a new series on the cool stuff behind Camping, and would
like some feedback from the campers. Are everything understandable? Any
grammar/spelling errors? And please don't spread the link, I'll publish a
spreadable link later :-)

http://judofyr.net/drafts/camping-explained:the-beginning.html

-- 
Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Re: Backwards compatibility broken with URL()... for the better?

2008-07-21 Thread Magnus Holm
I have no problem with breaking backwards compatibility. After all, Camping
2.0 is a major upgrade.

About session.rb, even though it was I who wrote the code, _why merged it
(despite your warnings) and he's the to remove it :-)

On Mon, Jul 21, 2008 at 2:46 AM, Bluebie, Jenna
[EMAIL PROTECTED] wrote:
 In 1.5, to get a full url to ones camping app, you had to do:

 this_url = 'http:' + URL('/some_action').to_s

 Useful, for instance, in my openid consumer sample code, to give the openid
 doodad a return address

 But in camping 1.9 off jud's gems, URL now returns actual url's with http:
 and everything at their fronts, which is rather snazzy... but breaking.
 Iunno, I kinda like this new fancy URL method that returns real URL's O_o

 Jud's gem's session.rb still is including the IP address in the session
 hashing. I don't think we should recommend anyone use those gems till it's
 updated, I can only imagine how painfully frustrating it must be for user's
 in ISP's using AOL style load balanced transparent proxies who no matter
 what they do, can't get cookie session support to work in camping, with no
 errors or explanations.
 ___
 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: Preview: Camping Explained

2008-07-21 Thread Magnus Holm
Both R and #service will be covered!

Here's the published url:
http://judofyr.net/posts/camping-explained:the-beginning.html :-)

On Mon, Jul 21, 2008 at 12:48 AM, Eric Mill [EMAIL PROTECTED] wrote:
 I get that R is a method which returns the class; but it also uses a
 lesser-known Ruby callback called Class#inherited
 (http://www.ruby-doc.org/core/classes/Class.html#M000454) that blows
 my mind and could use talking about.

 The reason talking about #service would be cool is because it's not an
 obvious function to decipher, yet is key to any developers getting
 into Camping who might want to expand it like you and Magnus did.

 -- Eric

 On Sun, Jul 20, 2008 at 6:13 PM, Bluebie, Jenna
 [EMAIL PROTECTED] wrote:
 Neat! I like it ^_^

 As for those queries, Eric, I believe the answer is that R is a method which
 returns a class.

 Overriding services for middleware works because it's the job of 'service'
 to call the get, post, type methods in the Controllers. By overriding it, we
 can use 'super' to call the original service method which runs the app
 controller, but we can add code above and below that call to 'super'. :)
 ___
 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: Backwards compatibility broken with URL()... for the better?

2008-07-22 Thread Magnus Holm
Yes and no. The gems are based on my tree, but I'll always try to keep my
tree equal to _why's. If there's some commits I'm not sure if he will merge, I
put them in a branch (so I don't mess up the master).

On Tue, Jul 22, 2008 at 4:33 AM, Bluebie, Jenna
[EMAIL PROTECTED] wrote:
 I thought your gems were based on your tree, not _why's? My mistake?
 ___
 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

2008-07-22 Thread Magnus Holm
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

2008-07-23 Thread Magnus Holm
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


Re: File uploads

2008-07-26 Thread Magnus Holm
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

2008-07-29 Thread Magnus Holm
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!

2008-08-28 Thread Magnus Holm
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!

2008-08-28 Thread Magnus Holm
Well, it's being used in mab.rb and ar.rb:

Old way:
Object.constants.map{|c|Object.const_get(c)}.each do |c|
  c::Models.module_eval $AR_EXTRAS if c.respond_to?(:goes)
end

New way:
Camping::Apps.each do |c|
  c::Models.module_eval $AR_EXTRAS
end

Which may break if you got another class/module with #goes...

On Thu, Aug 28, 2008 at 9:54 PM, zimbatm [EMAIL PROTECTED] wrote:

 Hi Magnus,

 If I remember well, I am the one who introduced AND removed
 Camping::Apps. I'm not sure anymore but I think it wasn't really used
 and that solutions never really satisfied me. Do you have any use for
 it ?

 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

Re: Camping::Apps returns!

2008-08-29 Thread Magnus Holm
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 :-)

2008-10-27 Thread Magnus Holm
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 ?

2008-11-12 Thread Magnus Holm
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

2008-11-23 Thread Magnus Holm
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. ;-)

2008-12-04 Thread Magnus Holm

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

I CAN HAZ 3K FRAIMWURK?

2009-01-23 Thread Magnus Holm
Hey, campers! I've been messin' with camping.rb again :-)
* http://github.com/judofyr/camping/commit/cbbfe41
I've ported the flipbook template to RDoc 2 (RDoc 1 has always had problems
with building the docs at my computer)

* http://github.com/judofyr/camping/commit/9dc2233
Since we save all the applications in Camping::Apps we can easily figure out
which apps are defined when a file is loaded. I've refactored
Camping::Server and Camping::Reloader (truly a refactoring - mostly just
moved the bytes around) and now we no longer need to name our file the same
as the app. You can also define multiple apps in one file and
Camping::Reloader will work just as expected.

* http://github.com/judofyr/camping/commit/c8da0f7
The @response object was never really used, so now we're creating it
on-demand in #to_a. Save quite a few bytes.

* http://github.com/judofyr/camping/commit/c04a6c7
It has always annoyed me that if you overwrite r404, r500 or r501 you also
need to set the @status. Now we're doing a @status = @method =~ /r(\d+)/ ?
$1.to_i : 200, so the default status will be set to 404, 500 or 501 in those
methods. We also had a sexy r500 even though we sent all the errors to
Rack::ShowExceptions (again, many bytes saved by removing that).

I've also replaced Camping.method_missing to use Rack::MockRequest which is
shorter and more solid.

* http://github.com/judofyr/camping/commit/5739bb0
Camping now supports nested params (post[title]=Hellopost[body]=World).
See http://judofyr.net/posts/when-in-doubt.html for more information.

* http://github.com/judofyr/camping/commit/582d94b
Before, class PostX would route to /post/(\w+), just to be sure to catch
everything I replaced it with /post/([^/]+) (everything until next slash)
which makes more sense IMO

* http://github.com/judofyr/camping/commit/c55001f
After synchronizing camping.rb and camping-unabridged.rb, camping.rb ended
up at 2947 and we have now passed the 3k limit :D

Any thoughts? There's still missing a lot of documentation and I guess we
should add some tests too.

//Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

H with indifferent access

2009-01-24 Thread Magnus Holm
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

Do we still need to be alert when on SQLite3?

2009-01-24 Thread Magnus Holm
Anyone knows if we still need to follow the instructions at
http://web.archive.org/web/20080113055731/code.whytheluckystiff.net/camping/wiki/BeAlertWhenOnSqlite3,
or if the stable release is good enough?

//Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list

Re: H with indifferent access

2009-01-24 Thread Magnus Holm
Doh, the snippet I wrote was actually really stupid. Forgot we can safely
call super without thinking of recursive calls. What do you guys think? Is
it worth it?
Method access won't go away, and Mash was just an experiement; I don't want
to add another dependency on Camping.
//Magnus Holm


On Sat, Jan 24, 2009 at 21:12, Jenna Fox bluebe...@creativepony.com wrote:

 Yes, I want my method access too!..

 Perhaps it'd be extra worthy of the '2.0' if you also did something akin
 to:

 def [](k);super(k.to_s);end
 def []=(k,v);super(k.to_s,v);end

 it's some bytes, but I think it's worth it!

 What ever happened to Mash?



 On 25/01/2009, at 1:50 AM, Aria Stewart wrote:

  On Jan 24, 2009, at 7:24, zimbatm zimb...@oree.ch wrote:

  Hi Magnus,

 I prefer using method_missing, with string access for fallback when
 key names are not compatible with ruby method names.


 And I prefer symbols, but it's a total edge case to me. Strings are great
 too, and it'd bug me less than indifference.

 Aria
 ___
 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: Release?

2009-02-10 Thread Magnus Holm
Hm... I've always thought 1.5 == 1.5.180... Well, only _why has access to
the project, so there's not so much we can do :-(

//Magnus Holm


On Tue, Feb 10, 2009 at 18: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?

2009-02-12 Thread Magnus Holm
Okay, let's roll!
I did some testing with `git checkout` and `diff -r` and figured out that
the 1.5.180 gem is revision 173 in the Git repo... Weird stuff...

However, let's focus on the future! First of all, we need some plan on how
we should name the releases. What about keeping the rev-number in the
version number and make it some sort of patchlevel? So 2.0 becomes
2.0.308, and any bugfixes which doesn't change the external API can we
release as 2.0.xxx. Should make it simpler to release plain bugfixes without
bumping the version number too high. 2.1 would then contain some more new
stuff. Should also blend nicely into pre-releases since they can keep the
same structure.

Documentation is also needed, and we should migrate the old wiki (
http://web.archive.org/web/20080107032918/http://code.whytheluckystiff.net/camping)
to
the github wiki (http://wiki.github.com/why/camping). Maybe some of the
wiki-docs should be in the camping-unabridged.rb too...

And, we need some place where people can report bugs now when the Trac is
gone. Ditz is pretty cool. I could probably set up Sheila too (camping
makeup for ditz). Or we could turn this mailing-list into a bugtracker. What
do you guys think?

Yeah, and I'm going to write a changelog with all the new cool stuff :-)

//Magnus Holm


On Thu, Feb 12, 2009 at 07:00, Jenna Fox bluebe...@creativepony.com wrote:

 Yay little wheels!

 Okay, first task! Whatever Magnus has right now, lets call it 2.0 and
 release it everywhere! We can bugfix later if we have to. :)



 On 12/02/2009, at 1:35 PM, _why wrote:

  On Tue, Feb 10, 2009 at 08:11:46PM +0100, Magnus Holm wrote:

 Hm... I've always thought 1.5 == 1.5.180... Well, only _why has access to
 the project, so there's not so much we can do :-(


 I'm sorry everyone, let's get this all worked out, okay?

 Magnus, I've added you as an admin on both Rubyforge and Github.
 And, of course, you are free to add whoever else you like that will
 help you get your work done.

 Now, go. Show them Camping is still the little wheels!

 _why
 ___
 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

Getting ready for release

2009-02-14 Thread Magnus Holm
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: hi all!

2009-03-22 Thread Magnus Holm
Hi!
Camping has switched to Rack (http://rack.rubyforge.org) recently.

This should work:

if __FILE__ == $0
  Conf::Models::Base.establish_connection :adapter = 'sqlite3', :database
= 'conf.db'
  Conf::Models::Base.logger = Logger.new('conf.log')
  Conf.create

  app = Rack::Builder.new do
use Rack::ContentLength
run Conf
  end

  trap('INT') { exit }

  puts ** http://localhost:80/;
  t = Time.now
  @servertime=t
  puts 서버 시작 시간 :
#{t.year}년#{t.month}월#{t.day}일#{t.hour}시#{t.min}분#{t.sec}초
  Rack::Handler::Mongrel.run(app, :Port = 80)
end

There are probably more changes you need to do with your code. Just post
here if you're stuck and we'll figure out :-)

If don't want to upgrade, you can keep using the old version of Camping by
placing this at the top of the file:

require 'rubygems'
gem camping, =1.5.180
require 'camping'


Good luck, and have fun with Camping!

//Magnus Holm


2009/3/22 in-seok hwang his20...@gmail.com

 hi all

 i'm can't speak english well

 i has something problem.

 i used gems list is..
 mongrel-1.1.5
 camping-1.5.180

 and update now..

 camping-1.9.300

 so, My blog looks like an error on the server.

 my old code is ..

 615 if __FILE__ == $0
 616 require 'mongrel/camping'
 617
 618 Conf::Models::Base.establish_connection :adapter = 'sqlite3',
 :database = 'conf.db'
 619 Conf::Models::Base.logger = Logger.new('conf.log')
 620 Conf.create
 621
 622 config = Mongrel::Configurator.new :host = 0.0.0.0 do
 623 listener :port = 80 do
 624 uri /, :handler =
 Mongrel::Camping::CampingHandler.new(Conf)
 625 uri /favicon, :handler =
 Mongrel::Error404Handler.new()
 626 trap(INT) { stop }
 627 run
 628 end
 629 end
 630
 631 puts ** http://localhost:80/;
 632 t = Time.now
 633 @servertime=t
 634 puts 서버 시작 시간 :
 #{t.year}년#{t.month}월#{t.day}일#{t.hour}시#{t.min}분#{t.sec}초
 635 config.join
 636 end

 and error code is,


 h...@info105:~$ sudo ruby conf_mongrel1.9.rb
 ** http://localhost:80/
 서버 시작 시간 : 2009년3월22일13시30분25초
 Sun Mar 22 13:30:31 +0900 2009: Read error: #TypeError:
 #StringIO:0xb72b8c18 is not a symbol
 (eval):53:in `const_get'
 (eval):53:in `method_missing'
 /usr/local/lib/site_ruby/1.8/mongrel/camping.rb:53:in `process'
 /usr/local/lib/site_ruby/1.8/mongrel/camping.rb:52:in `synchronize'
 /usr/local/lib/site_ruby/1.8/mongrel/camping.rb:52:in `process'
 /usr/local/lib/site_ruby/1.8/mongrel.rb:159:in `process_client'
 /usr/local/lib/site_ruby/1.8/mongrel.rb:158:in `each'
 /usr/local/lib/site_ruby/1.8/mongrel.rb:158:in `process_client'
 /usr/local/lib/site_ruby/1.8/mongrel.rb:285:in `run'
 /usr/local/lib/site_ruby/1.8/mongrel.rb:285:in `initialize'
 /usr/local/lib/site_ruby/1.8/mongrel.rb:285:in `new'
 /usr/local/lib/site_ruby/1.8/mongrel.rb:285:in `run'
 /usr/local/lib/site_ruby/1.8/mongrel.rb:268:in `initialize'
 /usr/local/lib/site_ruby/1.8/mongrel.rb:268:in `new'
 /usr/local/lib/site_ruby/1.8/mongrel.rb:268:in `run'
 /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:282:in `run'
 /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:281:in `each'
 /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:281:in `run'
 conf_mongrel1.9.rb:627:in `cloaker_'
 /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:149:in `call'
 /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:149:in `listener'
 conf_mongrel1.9.rb:623:in `cloaker_'
 /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:50:in `call'
 /usr/local/lib/site_ruby/1.8/mongrel/configurator.rb:50:in `initialize'
 conf_mongrel1.9.rb:622:in `new'
 conf_mongrel1.9.rb:622


 plz help..



 ___
 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: Rack::Lint::LintError with latest camping and rack

2009-03-29 Thread Magnus Holm
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'

2009-05-03 Thread Magnus Holm
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'

2009-05-07 Thread Magnus Holm
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

2009-05-19 Thread Magnus Holm
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

2009-05-20 Thread Magnus Holm
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: using redirect with a mongrel server behind apache

2009-05-20 Thread Magnus Holm
It works, but it's a little weird Camping can't detect it itself. Anyway,
the most important thing is that it works :-)

//Magnus Holm


On Wed, May 20, 2009 at 19:53, David Susco dsu...@gmail.com wrote:

 I ended up overwriting the redirect method with this:

 def redirect *a
  r(302, '', 'Location' = 'my_vhost.net/my_app/' + R(*a).to_s)
 end

 Thoughts?

 Dave

 On Tue, May 19, 2009 at 11:05 AM, David Susco dsu...@gmail.com wrote:
  Within an apache vhost I'm rewriting like this:
 
 IfModule mod_rewrite.c
   RewriteEngine On
   RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
   RewriteRule ^/(.*)$ http://127.0.0.1:5000/$1 [P,QSA,L]
 /IfModule
 
  I haven't gotten to deployment yet, so I'm not sure if this is what
  I'm actually going to be doing so suggestions are welcome.
 
  Ideally though (since I'll have multiple camping apps) I'd like to
  have apache forward to many mongrel servers that will be serving up
  the apps.
 
  Dave
 
  On Tue, May 19, 2009 at 10:21 AM, Magnus Holm judo...@gmail.com wrote:
  Camping uses the Host-header to figure out where the app is located, and
  Apache *should* carry forward the header to the Mongrel. How have you
 set
  this up?
  If you're using Camping 1.9 or running this through Rack, you could
 always
  create a middleware which changes the Host-header:
  class Thing
def initialize(app, options = {})
  @app = app
end
 
def call(env)
  @app.call(env.merge({ 'HTTP_HOST' = 'my_vhost.net' }))
end
  end
  app = Thing.new(app)
  ---
  I also believe Apache is able to modify HTTP-headers.
 
  //Magnus Holm
 
 
  On Tue, May 19, 2009 at 15:31, David Susco dsu...@gmail.com wrote:
 
  Not sure if this list is still active but I haven't found another yet,
  here's my setup and question.
 
  * I'm running a camping app using a mongrel server listening at
  127.0.0.1:X.
  * I have a virtual host setup in Apache that is rewriting
  my_vhost.net/my_app/ to 127.0.0.1:X.
  * In one of my controllers I'm trying to redirect to another
  controller like this: redirect Index
  * Instead of being directed to my_vhost.net/my_app/ though the user is
  directed to 127.0.0.1:X.
 
  What's the best/cleanest way to get around this and have the
  controller redirect to my_vhost.net/my_app/?
 
  --
  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
 



 --
 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: using ActiveRecord::Validations::ClassMethods

2009-05-21 Thread Magnus Holm
params is simply Rails' version of @input.
If you name your keys user[id] and user[name] in the HTML, then
@input.user should contain a Hash like { 'id' = ..., 'name' = ... } (maybe
the keys are Symbols; I don't remember at the moment)

//Magnus Holm


On Thu, May 21, 2009 at 15:50, David Susco dsu...@gmail.com wrote:

 Thanks, I've gotten it to work.

 On this part though: @user = User.new params[:user

 Is the closing bracket missing? Is params something from Rails that
 allows you to create the user instance variable all in one line
 instead of doing something like this:

 @user = User.new(
  :id = input.id,
  :name = input.name,
  ...
 )

 Can I use it in a camping app relatively easily?

 Dave

 On Wed, May 20, 2009 at 5:27 PM, Eric Mill kproject...@gmail.com wrote:
  In my create actions, I customarily do like
 
  @user = User.new params[:user
  if @user.save
   ...
  else
   ...
  end
 
  But update_attributes should also return true or false, I believe.
 
  On Wed, May 20, 2009 at 4:42 PM, David Susco dsu...@gmail.com wrote:
  So, in my crud controllers, should I be using calls to save instead of
  create and update_attributes? As those just return the object, and not
  true of false based on my validations.
 
  Dave
 
  On Wed, May 20, 2009 at 4:30 PM, Eric Mill kproject...@gmail.com
 wrote:
  Yeah, but in practice, you'd call @user.save, which internally calls
  #valid?, and returns true or false on whether the object was saved or
  not. If the object wasn't saved, @user.errors is populated with the
  error messages.
 
  -- Eric
 
  On Wed, May 20, 2009 at 4:03 PM, Magnus Holm judo...@gmail.com
 wrote:
  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
 
  ___
  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: Camping tutorials for education?

2009-06-09 Thread Magnus Holm
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

2009-06-09 Thread Magnus Holm
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

2009-06-09 Thread Magnus Holm
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?

2009-06-10 Thread Magnus Holm
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?

2009-06-11 Thread Magnus Holm
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

2009-10-18 Thread Magnus Holm
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: What now?

2009-10-19 Thread Magnus Holm
http://imgur.com/7gpQ4.png

//Magnus Holm



On Mon, Oct 19, 2009 at 22:44, Jenna Fox bluebe...@creativepony.com wrote:
 Yeah, and besides, camping is not a business, it is an open source project
 of much niftiness. We do not need SEO, it does in fact not especially effect
 us how many people use our framework, except that we have this wonderful
 tight knit little community at the moment which would be utterly obliterated
 by fame. See rubyonrails for details about why fame sucks.

 —
 Jenna


 On 20/10/2009, at 7:18 AM, Aria Stewart wrote:


 On Oct 19, 2009, at 6:27 AM, Dave Everitt wrote:

 nice idea with the .ru = Ruby, although still doubtful that 'why' and
 'went' are good for SEO (BTW you did mean 'camping', not 'caping' didn't you
 :-).

 I reckon: 2 domains, one obviously SEO-optimised (containing 'ruby,
 camping, framework'), forwarding to another memorable one we all like from
 the existing list (unless there's a genius new suggestion).


 Or better, get good search engine results without gaming the system, and
 just get people to link to it -- go talk it up, blog it up, and write some
 awesome stuff and post it! I'll certainly be linking to it from my blog.

 Aria Stewart
 aredri...@nbtsc.org



 ___
 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 sessions issue (and fix?) when mounting multiple apps

2009-11-02 Thread Magnus Holm
Okay, I think we're actually fine by setting :path = / by default.
If you want anything different, you should use use
Rack::Session::Cookie yourself.

//Magnus Holm



On Mon, Oct 19, 2009 at 19:14, Jonathan Hickford
jonathan.hickford+camp...@gmail.com wrote:
 Hi,

 I'd be inclined to agree with the middleware approach too, especially
 if it's pre 2.0 release and that change can be made along side other
 1.5 - 2.0 changes

 Jon

 On Sun, Oct 18, 2009 at 9:31 PM, Magnus Holm judo...@gmail.com wrote:
 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

 ___
 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

2009-11-02 Thread Magnus Holm
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?

2009-11-02 Thread Magnus Holm
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

2009-11-05 Thread Magnus Holm
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: Camping on the Ruby Application Archive

2009-11-05 Thread Magnus Holm
Let's wait until 2.0 is released. If we clean up the documentation we
have now, I'm totally in for releasing 2.0 as soon as possible. It
would be a shame if it took more than four years to go from birth
(17th, January 2006) to 2.0. This release has been delayed for way too
long (sorry guys!)

//Magnus Holm



On Tue, Nov 3, 2009 at 13:59, Dave Everitt dever...@innotts.co.uk wrote:
 Camping on the RAA is frozen at 1.4:
 http://raa.ruby-lang.org/project/camping/

 If no-one has access I could contact raa-ad...@ruby-lang.org and send
 updated info, but (at present for the 'To install' part) that could mean
 sending out source http://gems.judofyr.net; (Magnus?)

 - 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: Created a small instrumentation NewRelic plugin for Camping controllers

2010-01-02 Thread Magnus Holm
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

2010-01-03 Thread Magnus Holm
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)

2010-01-20 Thread Magnus Holm
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

2010-01-23 Thread Magnus Holm
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: going into production, a few questions

2010-02-19 Thread Magnus Holm
404 on 1.5:
module App::Controllers
  class NotFound
def get(path)
  Do something with path
end
  end
end

404 on 1.9/2.0:
module App
  def r404(path)
Do something with path
  end
end

There appears to be two solutions:
Call ActiveRecord::Base.verify_active_connections! before every request (I
think this is what Rails does by default):

module VerifyConnection
  def service(*args)
ActiveRecord::Base.verify_active_connections!
  ensure
return super
  end
end

module App
  include VerifyConnection
end

Or, pass reconnect = true to establish_connection.

I'm not quite sure what's best…

// Magnus Holm


On Fri, Feb 19, 2010 at 20:59, David Susco dsu...@gmail.com wrote:

 I have a few camping projects that are about to go into production in
 a few weeks, just picking your brains to see if I can add some
 robustness.

 What's the best way to catch any Camping Problem! /XXX not found
 errors that a user might see if they start typing URLs themselves?
 Ideally I'd just like to redirect them all to some general index
 controller.

 I'm using MySQL for my database. I'm getting a few MySQL server has
 gone away error messages every now and then. I did some searching and
 found if reconnect: true is in the hash I send to
 establish_connection that I should be all set. Can anyone confirm?
 Also, any other MySQL connection best practices that I should be
 following?

 --
 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?

2010-03-03 Thread Magnus Holm
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?

2010-03-03 Thread Magnus Holm
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?

2010-03-13 Thread Magnus Holm
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

2010-03-23 Thread Magnus Holm
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?

2010-03-23 Thread Magnus Holm
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

2010-03-23 Thread Magnus Holm
@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

2010-04-07 Thread Magnus Holm
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

2010-04-12 Thread Magnus Holm
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

2010-04-12 Thread Magnus Holm
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: Tilt integration

2010-04-12 Thread Magnus Holm
Tilt - http://github.com/camping/camping/issues#issue/18

Tilt integration (http://github.com/rtomayko/tilt) is a dead-simple
way to support ERB, Erubis, Haml, Liquid, Builder and other template
engines. It would be nice if require 'camping/templates' would
re-define Base#render to use Tilt IMO.

// Magnus Holm
___
Camping-list mailing list
Camping-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/camping-list


Camping 2.1: Easier to extend

2010-04-12 Thread Magnus Holm
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

2010-04-12 Thread Magnus Holm
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

2010-04-13 Thread Magnus Holm
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!

2010-04-22 Thread Magnus Holm
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?

2010-04-24 Thread Magnus Holm
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

2010-04-29 Thread Magnus Holm
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: Proposal for optional compilation and caching of Tilt templates

2010-05-08 Thread Magnus Holm
Thanks for testing it out ;)

I agree: we can't cache templates in development and you shouldn't need to
set an option for that, however we also want Camping to be speedy
out-of-box.

What about applying your patch, but also make bin/camping set
:dynamic_templates to true if it's not set already?

If you want to force caching (or force not-caching) in your app, you simply
set :dynamic_templates, true/false. And if you don't, it compiles if you
i.e. run it through a configuration.ru, but is dynamic with bin/camping.
Best of both worlds?

On May 9, 2010 12:43 AM, Philippe Monnet r...@monnet-usa.com wrote:

 I gave Magnus' excellent integration of Tilt a whirl today and really love
it.
It's also cool because you can match different types of templates at the
same time (e.g. Markaby + HAML).

I found that while prototyping it would be nice to not have Camping compile
and cache Tilt templates.
So I used the new option capability and defined a :dynamic_templates option.

e.g.:

module TiltTest
set :views, File.dirname(__FILE__) + '/views'
set :dynamic_templates, true

#...
end

I changed the Camping code to check for that option and only compile and
cache if false.
What do you think?
Maybe we need a shorter or different name for the option?

I checked in the changes in my fork:
http://github.com/techarch/camping/commit/0152c606f286855ca7381c9394e9f05001d93764

Magnus, you might have some additional ideas for tweaking this feature. So
feel free to add/alter and merge to your liking.

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: Camping on Ruby 1.9.1 on Win32

2010-05-20 Thread Magnus Holm
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

2010-06-08 Thread Magnus Holm
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

2010-06-08 Thread Magnus Holm
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

2010-06-17 Thread Magnus Holm
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

2010-06-18 Thread Magnus Holm
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

2010-06-18 Thread Magnus Holm
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

2010-06-18 Thread Magnus Holm
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

2010-06-18 Thread Magnus Holm
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

2010-06-19 Thread Magnus Holm
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

2010-06-21 Thread Magnus Holm
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: Speed issue

2010-06-21 Thread Magnus Holm
Yep,

The reloader (located in camping/reloader.rb) watches a file and then
reloads the server whenever the file changes. It's what makes it
possible to just run `camping app.rb` and always have the latest
version served.

I can't reproduce it at my machine at the moment :( Could you send me
an example app which has the speed issues on your machine?

// Magnus Holm



On Mon, Jun 21, 2010 at 16:10, Raimon Fernandez co...@montx.com wrote:

 On 21jun, 2010, at 13:49 , Magnus Holm wrote:

 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...

 What's the reloader ?

 When I make some changes in the app.rb file ?

 thanks,

 regards.

 r.



 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



 ___
 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: versioning alternatives

2010-06-29 Thread Magnus Holm
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

2010-06-30 Thread Magnus Holm
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

2010-06-30 Thread Magnus Holm
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


  1   2   3   >