incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@wandisco.com>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Fri, 05 Oct 2012 03:36:15 GMT
On 05.10.2012 05:17, Olemis Lang wrote:
> On 10/4/12, Branko Čibej <brane@wandisco.com> wrote:
>> On 04.10.2012 18:33, Olemis Lang wrote:
>>> On 10/4/12, Gary Martin <gary.martin@wandisco.com> wrote:
>>>> On 04/10/12 16:54, Joachim Dreimann wrote:
>>>>> On 4 Oct 2012, at 12:01, Gary Martin <gary.martin@wandisco.com>
wrote:
>>>>>>> On 03/10/12 20:50, Olemis Lang wrote:
> [...]
>>>> I don't like the inconsistency there. Personally I would store up the
>>>> changes, marking which fields are altered in some way and provide a
>>>> means to submit those changes as a set.
>>>>
>>> That's the way in-place editing works [1]_
>>>
>>> .. [1] jEditable # How does in place editing work?
>>>         (http://www.appelsiini.net/projects/jeditable)
> [...]
>> Ticket changes should be complete and intentional,
> +1
>
>> not
>> something that happens because some bit of code downloaded from
>> somewhere happens to "work that way".
>>
> I think you are misunderstanding my previous comment . Firstly
> in-place edits happen one at a time , at least that's what they are
> meant to be . What I said should be interpreted as «that's the common
> way of doing things» , not as /me saying «we have to do it that way
> because everybody does» . I did it that way because I was told to do
> it that way . Indeed ...
>
>> As a user using a web application with the server 50 hops away with a
>> 1.5 second ping time, I'd be very, very pissed off if every click I make
>> generates a POST request to somewhere; even if it's an async XHR (even
>> worse! then I don't know in what order the server actually receives the
>> requests).
>>
> ... if you take a look at #146 attachments you'll notice that my first
> proposal included submit button for select fields . I was told to
> revert that .

Hmm. "Told to" implies hierarchy. Ain't no such thing in an Apache
project. What gives? If you don't agree with someone's ideas about a
feature, surely the thing to do is to discuss the various pros and cons
on this list. The log for that ticket isn't exactly a glaring example,
but it's worrying.

-- Brane

P.S.: Yes I know that BH development is funded. <mentor>Regardless,
things should happen by consensus of project members, clearly expressed
on the mailing list, not because of "told to".</mentor>

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download


Mime
View raw message