Page "Proposals/BEP-0012" was changed by sifa_sensay Diff URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0012?action=diff&version=10> Revision 10 Changes: -------8<------8<------8<------8<------8<------8<------8<------8<-------- Index: Proposals/BEP-0012 ========================================================================= --- Proposals/BEP-0012 (version: 9) +++ Proposals/BEP-0012 (version: 10) @@ -20,21 +20,46 @@ Autocompletion of ticket fields would be a great feature for the Bloodhound, as it saves user’s search time, catch a user’s mistake and allows repeating a favorite search. Typing the whole search word makes finding information slower and requires more typing and also increases the chance of misspelling that leads to incorrect search results which degrades the interface usability. -== Motivation == - -<The motivation is critical for BEPs that want to change the copy of ''Trac'' patched using vendor branch . It should clearly explain why the existing ''Bloodhound'' solution is inadequate to address the problem that the ''BEP'' solves. ''BEP'' submissions without sufficient motivation may be rejected outright. > == Proposal #proposal -<The technical specification should describe any new features , detail its impact on the components architecture , mention what plugins will be included as a result , whether they are hosted by [http://trac-hacks.org trac-hacks.org] or not , and any other relevant technical subject . The specification should be detailed enough to allow competing, interoperable implementations for any of the current supported database platforms (e.g. ''SQLite'', ''Postgres'', ''MySQL'') and server technologies (e.g. ''Apache HTTPD server'', ''nginx'', ''mod_wsgi'', ''CGI'').. > +The implementation of the project can be splitted into three distinct parts, the keyword and user suggestion components, and duplicate ticket search component. +The keyword suggestion component of the project will suggest entries that are used in existing tickets while user suggestion component will autocomplete the Owner and Cc fields from a list of valid users. Pressing the down key will be sufficient to display suggested keywords in an alphabetical list that the user can scroll through. Instead of an alphabetical order, popularity of entries would be used to order the suggested keywords and also matching would not be case sensitive to give more flexibility to the user in typing. + +The keyword and user suggestion component of the project will be coded using jQuery (JavaScript library). Since most of Bloodhound’s design is done using the Twitter Bootstrap framework, the autocompletion part of the code can also be designed using Twitter Bootstrap Typeahead plugin. + +Suggestions can be stored into the source array and can be retrieved on page load. However, this is really inefficient when there are thousands of keywords/usernames since user needs to wait for a long time for the page to be displayed. Alternative solution to this would be storing the suggestions in dynamically retrieved server-side (i.e. database), which will provide faster and more efficient results. More advanced approach would be using the dynamically retrieved server-side with a JSON format (JavaScript Object Notation) for human-readable data interchange between client and server. + +Using dynamically retrieved server-side for retrieving the suggestions will be faster. However, there will be some latency in retrieving the possible keywords/usernames. In order to overcome the latency, AJAX (Asynchronous JavaScript And XML) would be used to leave client active while the server retrieves the keywords/usernames. + +The duplicate ticket search component of the project will assist the user to search for the duplicate tickets when entering a new ticket’s summary. One of the possible solution would be determining the duplicates by searching the summary of existing tickets whereas searching the ticket description would be better and powerful solution. + + +The duplicate ticket search part of the project will be coded using +jQuery and AJAX. Since most of Bloodhound’s design has been done using the Twitter Bootstrap framework, this part of the code can also be designed using Twitter Bootstrap. First, the duplicate search feature will be implemented to work with the Trac Search API then it will be manipulated to work with the BloodhoundSearchPlugin since it is much more powerful than Trac Search API. However, the ticket Query API would be another solution to implement duplicate search feature rather than interacting with Search components. The ticket Query API has support for searching ticket summaries and descriptions that contain words and phrases. + +We are going to use TicketQuery wiki macro which listing tickets that match certain criteria. Listing tickets according to ticket ID next to the summary, with each ticket on a separate line is one of the format parameters that determine how the list of tickets is presented. + +Therefore, Query API would be better choice than using the incremental set of feature Track Search API first, then BloodhoundSearchPlugin. + +Furthermore, there are going to be a number of areas of the code that deal with tickets including the base implementation from trac and the modifications added by bloodhound. We are going to interact with these through the various interfaces that are available in trac, like IRequestHandler (for handling web requests), ITemplateProvider, IRequestFilter and others. (Initially, we will start to implement the project with bloodhound without the BloodhoundMultiproduct, since it causes complication, after that support for Multiproduct might be added) +Overall, this project will provide faster search facility to users whereas decrease the chance of misspelling. In other words, it will improve the usability and the core functionality of the Apache Bloodhound. This project would also be a start point for my contribution to the Bloodhound application. + +Deliverables +• Keyword Suggest Component +• Autocomplete Users Component +• Duplicate Ticket Search Component +• Unit tests for the three main components +• Documentation + == Rationale #rationale -<The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other issue trackers or ''Trac'' hacks . The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. Take a look at sample rationale below> +Autocompletion features can be divided into three components for this project; autocompletion of keywords, autocompletion of usernames and search for duplicate tickets. +Each of these components has a link to a plugin in track-hacks, called KeywordSuggestPlugin, AutocompleteUsersPlugin and DuplicateTicketSearchPlugin respectively. However, we don't want to clutter the Bloodhound project with another plugin for basic features. -''BEP'' submissions come in a wide variety of forms, not all adhering to the format guidelines set forth below. Use this template, in conjunction with the [wiki:/Proposals general content guidelines] and the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines], to ensure that your ''BEP'' submission is easy to read and understand. +Therefore, each of these features can be added to the BloodhoundThemePlugin as an individual component. This will work well since the client-side functionality (i.e. the JavaScript parts) can be added directly in each individual feature and the server-side request handling can also be handled in individual components within the BloodhoundThemePlugin. Moreover, the user will able to enable/disable each feature since they are implemented individually into the BloodhoundThemePlugin. -This template allows to create BEPs and is very similar to [http://www.python.org/dev/peps/pep-0012 PEP 12] . However it has been optimized by moving long explanations to the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines] . If you are interested take a look at the [?action=diff&old_version=1 differences]. The goal is to redact new BEPs just by following in-line instructions between angle brackets (i.e. **<** **>**) . Even if this will allow to write BEPs faster , it is highly recommended to read the [wiki:/Proposals/Formats/WikiFormatting WikiFormatting BEP guidelines] at least once in your lifetime to be aware of good practices and expected style rules . == How to Use This Template #howto -------8<------8<------8<------8<------8<------8<------8<------8<--------
-- Page URL: <https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0012> Apache Bloodhound <https://issues.apache.org/bloodhound/> The Apache Bloodhound issue tracker This is an automated message. Someone added your email address to be notified of changes on 'Proposals/BEP-0012' page. If it was not you, please report to .
