From dev-return-8837-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Thu Feb 25 10:31:34 2010 Return-Path: Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: (qmail 69874 invoked from network); 25 Feb 2010 10:31:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 25 Feb 2010 10:31:34 -0000 Received: (qmail 31164 invoked by uid 500); 25 Feb 2010 10:31:33 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 31125 invoked by uid 500); 25 Feb 2010 10:31:33 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 31115 invoked by uid 99); 25 Feb 2010 10:31:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Feb 2010 10:31:33 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of matt.goodall@gmail.com designates 74.125.82.180 as permitted sender) Received: from [74.125.82.180] (HELO mail-wy0-f180.google.com) (74.125.82.180) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 25 Feb 2010 10:31:27 +0000 Received: by wyb42 with SMTP id 42so1631170wyb.11 for ; Thu, 25 Feb 2010 02:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=D5UPldOKBHFgqskxWrHR51sgC2xrYnznHdpdkcqJLzs=; b=W4SmQ2+en5tn+ZwIngPoH/2C7TAGnWo55gMDk0OjLLPN/+CcLSq0LdBBffXcUSbnX5 IHipebylA4+TXfIShrfOaG6RmNUSZ+thI/eeikGXRdg8OdWQtVjCmKDojIrDR9cBwS26 b0aKHU87MoiXbRghr6+vb/Ai95tN5mk+wET8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ulXJOEdUgfLZjEs1g8JK1trijZIgacuyxiYKxNz4RvC9JKCA8/Jz4dEmXBd5qHlqk5 3lOWGwTZnZpWSlPvcylaQvLMjcfUbLncXR0bi13kyBDy2uCUJacae5+/r9HmPlgxmowi TJWb2Zo/muPhkLO8Zca+ujChmCtJCC6bdiPg4= MIME-Version: 1.0 Received: by 10.216.88.143 with SMTP id a15mr589084wef.6.1267093865641; Thu, 25 Feb 2010 02:31:05 -0800 (PST) In-Reply-To: <214c385b1002230857y71c56bf9r15925518b36c9edb@mail.gmail.com> References: <214c385b1002230525j2ebd9768qa201e9fde953efb0@mail.gmail.com> <44449DB9-5B32-4F17-986B-FDD93F5B287A@gmx.de> <214c385b1002230835g27f9a344h57dd2f94d46959a@mail.gmail.com> <214c385b1002230857y71c56bf9r15925518b36c9edb@mail.gmail.com> Date: Thu, 25 Feb 2010 10:31:05 +0000 Message-ID: <214c385b1002250231q2ef5390fscdcad7578443826f@mail.gmail.com> Subject: Re: 0.11.x futon storage From: Matt Goodall To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=0016e6d6454ec235ed04806a472c --0016e6d6454ec235ed04806a472c Content-Type: text/plain; charset=UTF-8 On 23 February 2010 16:57, Matt Goodall wrote: > On 23 February 2010 16:35, Matt Goodall wrote: > >> On 23 February 2010 16:20, Christopher Lenz wrote: >> >>> Hi Matt, >>> >>> On 23.02.2010, at 14:25, Matt Goodall wrote: >>> > 2. Implicit type conversion. Doc attribute values are now implicitly >>> > converted to some type of Futon's choosing. I'm guessing this is >>> deliberate >>> > but, IMHO, it's just awful. It's easy to come up with contrived >>> examples, >>> > e.g. try changing "1" to 1 or changing "[]" to "[100]", but I managed >>> to end >>> > up with a {} getting stored as a string somehow (although I can't >>> repeat it >>> > again) and it broke my application. >>> >>> The motivation for this was to make editing text less painful. Not having >>> to escape quotes and line breaks means it's now actually possible to edit >>> fields containing longer strings without pulling your hair out. >>> >>> The implementation is simple: Anything that doesn't parse as valid JSON >>> is automatically treated as a string. I'm not going to claim that that this >>> approach is perfect, and there are certainly cases where it's unexpected or >>> annoying. >>> >>> Just saying that IMHO there is a pretty large benefit to this approach >>> when trying to edit text fields. >>> >>> >> OK, that's a good point. I don't dump blocks of text into couchdb often so >> I hadn't considered that. >> >> I'm still not sure how I managed to accidentally convert {} to "{}" but it >> had me totally confused. I'd just made a change to the application code and >> I normally trust CouchDB a lot more than me ;-). >> >> I'm running 0.11.x on my machines now so I'll see how I get on. It >> certainly caused me some surprise and pain so far but perhaps I was just >> unlucky. >> >> > Chris, you're right it is nicer for long text. :) > > One immediate problem is that for small strings (less than 60 chars) it > uses an input field and replaces line breaks with spaces. > I'm going to add a 0.11 ticket for this, for now. I honestly don't think 0.11 should go out while it does this and I'm worried it will get forgotten otherwise. - Matt > Perhaps it should always use a textarea? One of those autoexpanding ones > might work nicely. A special key binding, say Shift+Enter, to leave and > close the field would nice as we'd lose and . > > However, even using a textarea, isn't there a danger of changing the line > break characters? e.g. changing \r\n to \n. > > - Matt > > --0016e6d6454ec235ed04806a472c--