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-22 Thread zimbatm
class H < Hash
# Gets or sets keys in the hash.
#
#   @cookies.my_favorite = :macadamian
#   @cookies.my_favorite
#   => :macadamian
#
def method_missing(m,*a)
x=(m.to_s=~/=$/?self[$`]=a[0]:a==[]?self[m.to_s]:super)
x.kind_of?(Hash) ? H[x] : x
end
undef id, type
  end

2008/7/22 Bluebie, Jenna <[EMAIL PROTECTED]>:
> 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
>
___
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