bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Apache Bloodhound] #146: Inline editing of objects
Date Mon, 05 Nov 2012 21:28:42 GMT
On 11/5/12, Jure Zitnik <> wrote:
> On 11/5/12 12:44 PM, Gary Martin wrote:
>> Individual confirmation on every field? That sounds like the same thing
>> as
>> an immediate save. I think that so far the consensus is that we don't
>> want
>> that.
> +1
>> I've been using a few developers at apachecon as sounding boards as I am
>> worried that things might be more complicated than necessary. The
>> solution
>> that would seem most efficient would be that all the fields that are
>> editable are considered to be in an editable state already. The problem
>> with this is then how it is made abundantly clear that a field is
>> editable

So far it turns out that we don't need jEditable at all . It seems to
me that we are moving towards an scenario in which existing «Modify
Ticket» is redesigned to look like fields list and then toggle it to
switch back and forth between editable form and initial read only
field / value list .

Did I understand what you mean ?

>> - and it would be nice to see when a field has been edited too.

this introduces some complexities . IMO if edits are canceled
read/only ticket field/value list should be reverted to reflect its
initial state .

>> I am not yet convinced that a button to make all fields editable is the
>> right approach at the moment - it seems like a step you shouldn't need.
> I think that the ticket could be shown as read only initially, with the
> scroll spy component being visible from start (I think that was
> discussed in another thread already). As the scroll spy already includes
> the 'Modify ticket' button, clicking that button would enable 'edit
> mode' which would replace ticket fields inline (read only for editable)
> - that is, w/o scrolling to the 'Modify ticket' section. So, I would go
> for one button to enable the 'edit' state and one button for submission.
>> Other than that, a submit all changes button would probably work well.
> +1

Well this looks like what I mentioned above , isn't it ?



Blog ES:
Blog EN:

Featured article:

View raw message