Re: [Apache Bloodhound] #185: Typeahead for usernames on 'assign to' fields

[James Wood <ja...@wandisco.com>]

It's mudri again,

To add, what's happening on the modify pages is that there are two forms,
#propertyform, which is always invisible, and #inplace-propertyform,
surrounding what is actually being modified. They both have the same
action. Inputs are being copied from the former to the latter, losing event
bindings. I've tried .clone(true), but it didn't seem to work.

My point is that #propertyform seems unnecessary. It is never shown, and
never performs its action. I think it would be better to leave the inputs
in their place in #inplace-propertyform, and get rid of #propertyform.

co'o


On Tue, Jul 23, 2013 at 5:02 PM, Apache Bloodhound <
dev@bloodhound.apache.org> wrote:

> #185: Typeahead for usernames on 'assign to' fields
> --------------------------+---------------------
>   Reporter:  jdreimann    |      Owner:  nobody
>       Type:  enhancement  |     Status:  new
>   Priority:  minor        |  Milestone:
>  Component:  ui design    |    Version:
> Resolution:               |   Keywords:  starter
> --------------------------+---------------------
>
> Comment (by mudri):
>
>  I've been looking into this issue, using AutocompleteUsersPlugin. One
>  problem is that, on version 0.6, inputs are destroyed and recreated at
>  various times. In this process, they lose the event bindings they are
>  supposed to get from the plugin. Fixing this seems to be messy.
>
>  When modifying a ticket (from a /ticket/1234 page), the inputs are
>  recreated when the “Modify Ticket” button is clicked. This can be
>  accounted for by calling `$('#inplace-edit-button').click()` with the
>  plugin's `$(document).ready()` handler. Note that `$('#inplace-edit-
>  button')` is the parent of the actual button. Binding to the button causes
>  the plugin's event handlers to be bound to the to-be-replaced inputs.
>
>  New tickets (on /newticket, still using the bh_ticket.html template) are
>  more difficult. The inputs are recreated in the `$(document).ready()`
>  handler, and there is no later event to bind to. The best solution I can
>  find involves triggering a custom event at the end of the template's
>  `$(document).ready()` handler, and then having the plugin listen for that.
>
>  However, it would probably be better to not have the inputs regenerating
>  at all. The creation is done through cloning dummy elements, which are the
>  elements that get the event handlers through all the `$(document).ready()`
>  calls. The new inputs are duplicates without the event handlers, and
>  worryingly have the same `id`s.
>
> --
> Ticket URL: <https://issues.apache.org/bloodhound/ticket/185#comment:6>
> Apache Bloodhound <https://issues.apache.org/bloodhound/>
> The Apache Bloodhound issue tracker
>

-- 
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
passed.

Re: [Apache Bloodhound] #185: Typeahead for usernames on 'assign to' fields

[Matevž Bradač <ma...@digiverse.si>]

On 23. Jul, 2013, at 18:12, James Wood wrote:

> It's mudri again,
> 
> To add, what's happening on the modify pages is that there are two forms,
> #propertyform, which is always invisible, and #inplace-propertyform,
> surrounding what is actually being modified. They both have the same
> action. Inputs are being copied from the former to the latter, losing event
> bindings. I've tried .clone(true), but it didn't seem to work.

AFAIK the #propertyform is also used for resetting the data when
the user cancels the ticket modification, so you'll probably need
to adjust that if the form is thrown out.

> 
> My point is that #propertyform seems unnecessary. It is never shown, and
> never performs its action. I think it would be better to leave the inputs
> in their place in #inplace-propertyform, and get rid of #propertyform.

Agreed, if it's not used anywhere it should be removed. Note that the
ticket page is used in different scenarios which should be tested, namely
the ticket view, inline ticket modification as well as the /newticket page.
Then there's also the responsive layout (mobile, tablet) which may also
be affected, but hopefully not too much.

--
matevz

> 
> co'o
> 
> 
> On Tue, Jul 23, 2013 at 5:02 PM, Apache Bloodhound <
> dev@bloodhound.apache.org> wrote:
> 
>> #185: Typeahead for usernames on 'assign to' fields
>> --------------------------+---------------------
>>  Reporter:  jdreimann    |      Owner:  nobody
>>      Type:  enhancement  |     Status:  new
>>  Priority:  minor        |  Milestone:
>> Component:  ui design    |    Version:
>> Resolution:               |   Keywords:  starter
>> --------------------------+---------------------
>> 
>> Comment (by mudri):
>> 
>> I've been looking into this issue, using AutocompleteUsersPlugin. One
>> problem is that, on version 0.6, inputs are destroyed and recreated at
>> various times. In this process, they lose the event bindings they are
>> supposed to get from the plugin. Fixing this seems to be messy.
>> 
>> When modifying a ticket (from a /ticket/1234 page), the inputs are
>> recreated when the “Modify Ticket” button is clicked. This can be
>> accounted for by calling `$('#inplace-edit-button').click()` with the
>> plugin's `$(document).ready()` handler. Note that `$('#inplace-edit-
>> button')` is the parent of the actual button. Binding to the button causes
>> the plugin's event handlers to be bound to the to-be-replaced inputs.
>> 
>> New tickets (on /newticket, still using the bh_ticket.html template) are
>> more difficult. The inputs are recreated in the `$(document).ready()`
>> handler, and there is no later event to bind to. The best solution I can
>> find involves triggering a custom event at the end of the template's
>> `$(document).ready()` handler, and then having the plugin listen for that.
>> 
>> However, it would probably be better to not have the inputs regenerating
>> at all. The creation is done through cloning dummy elements, which are the
>> elements that get the event handlers through all the `$(document).ready()`
>> calls. The new inputs are duplicates without the event handlers, and
>> worryingly have the same `id`s.
>> 
>> --
>> Ticket URL: <https://issues.apache.org/bloodhound/ticket/185#comment:6>
>> Apache Bloodhound <https://issues.apache.org/bloodhound/>
>> The Apache Bloodhound issue tracker
>> 
> 
> -- 
> THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
> PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
> subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
> If you are not the intended recipient, please notify us immediately and 
> destroy the message without disclosing its contents to anyone.  Any 
> distribution, use or copying of this e-mail or the information it contains 
> by other than an intended recipient is unauthorized.  The views and 
> opinions expressed in this e-mail message are the author's own and may not 
> reflect the views and opinions of WANdisco, unless the author is authorized 
> by WANdisco to express such views or opinions on its behalf.  All email 
> sent to or from this address is subject to electronic storage and review by 
> WANdisco.  Although WANdisco operates anti-virus programs, it does not 
> accept responsibility for any damage whatsoever caused by viruses being 
> passed.
>