Autocomplete

I see a big jquery.js file (100K) included in your package. Do you think we can use current jQuery version of Drupal instead and get rid of this duplicate?

Hello, and thank you for applying for a CVS account. I am adding the review tags, and some volunteers will review the code, pointing out what it needs to be changed.

As per requirements, the motivation message should be expanded to contain more features of the proposed project. For themes, it should include also a screenshot of the theme, and (when possible) a link to a working demo site; for modules, it should include also a comparison with the existing solutions.

The only explanation I find for the purpose of the module are the following three sentences:

For the moment i need to add autocomplete functionality in any text input form.
Not only cck, taxonomy or search but in all text input fields.
I have developed a simple module that i want named Autocomplete, with this module you can add a result of a Views or a custom Sql into any text field.

As reported from the requirements, you must provide a motivation message, which should be a few paragraphs instead of only a few sentences.

• The points reported in this review are not in order of importance / relevance.
• Most of the times I report the code that present an issue. In such cases, the same error can be present in other parts of the code; the fact I don't report the same issue more than once doesn't mean the same issue is not present in different places.
• Not all the reported points are application blockers; some of the points I report are simple suggestions to who applies for a CVS account. For a list of what is considered a blocker for the application approval, see CVS applications review, what to expect. Keep in mind the list is still under construction, and can be changed to adapt it to what has been found out during code review, or to make the list clearer to who applies for a CVS account.

1. The version line needs to be removed from the .info file.
   The package name is used when the package name is already used from another module.
2. Files available from third-party sites should not be committed in Drupal.org repository. Files licensed under a license different from GPL License (even if it is a compatible license) should not be committed in Drupal.org repositories.
3. Hook implementation comments should be like the following one:

   /**
    * Implements hook_menu().
    */
   

   As reported in Documenting hook implementations:

   If the implementation of a hook is rather standard and does not require more explanation than the hook reference provides, a shorthand documentation form may be used in place of the full function documentation block described above:

   /**
    * Implements hook_help().
    */
   function blog_help($section) {
     // ...
   }
   

   This generates a link to the hook reference, reminds the developer that this is a hook implementation, and avoids having to document parameters and return values that are the same for every implementation of the hook. Optionally, you can add more information in a separate paragraph to describe the particular quirks of your hook implementation.

   In the case of hooks that have variables in the names, such as hook_form_FORM_ID_alter(), a slightly expanded syntax should be used:

   /**
    * Implements hook_form_FORM_ID_alter() for node_type_form().
    */
   function mymodule_form_node_type_form_alter(&$form, &$form_state) {
     // ...
   }
   

   This generates a link to the hook reference, as well as to the particular form that is being altered. Again, optionally you can add more information in a separate paragraph to describe the particular quirks of your hook implementation.

4. None of the module functions are prefixed by hook_.
5. Before exit, the code should call module_invoke_all('exit').

6.       drupal_set_message(t(check_plain("Remove autocomplete from field $fid finish successfull")));
   
   

   Use t()-placeholders. The string passed to t() is not passed to check_plain().

7.   drupal_set_message("Error until delete of $fid ". $query);
     drupal_goto('admin/build/autocomplete');
   
   

   Strings used in the user interface should be translated. Error until delete is not grammatically correct.

8.     '#description' => t("SQL query. This field is not compatible with view, 
                             and have priority on view. So choise to write your 
                             own SQL query if you don't wont use Views module. 
                             You must be use %s standard for yoir query param. Es: 
                            SELECT * FROM {autocomplete} WHERE title = '%s'"),
   
   

   There are some typos in the string (choise is not a verb).

9.     form_set_error('autocomplete', 
               t("The choise field id {$input_field_id} is already in use, 
                   please choise another field id.*" .
                   autocomplete_get_field( $input_field_id ) . "!=$input_field_id"));
   
   

   The first argument of form_set_error() is the form field identifier.
   The first argument of t() is a literal string, not a concatenation of strings. The script used to create the translation template is not able to handle any dynamic value, even in the case of code similar to t($variable), or t(function()); this means that if the argument of the function is not a literal string, it will not appear in the translation template.

10.   if ($type == 'Views') {
        if (isset($view_name) && isset($input_field_id)) {
          $view = '';
          if ( ! ($view = views_get_view( $view_name )) ) {
            if (!module_exists('views')) {
              drupal_set_message("the Views module is not installed");
            }
            else {
              drupal_set_message("the Views module is installed and fight");
            }
            form_set_error('autocomplete', 
                    t("The view {$view_name} not exists. Plese enter a valid views name"));
    
          }
          $filter_test = $view->get_item('default', 'filter', $filter_name);
          if ( (trim($filter_name) == '') || !$filter_test ) {
            form_set_error('autocomplete', "the Filter for this Views not exits");
          }
        }
        else form_set_error("If you choise View type you must insert : view name and view filter");
      }
    
    

    See http://drupal.org/coding-standards to understand how a module should be written. In particular, see how the code should be formatted.
    In English, there isn't a space before the colon.

11.   $input_type       = $form_state['values']['autocomplete_type'];
      drupal_set_message("Field $input_field_id active with autocomplete");
    
    

    Strings used in the user interface should be translated.

Please check typo "finish successfull".

Files available from third-party sites should not be committed in Drupal.org repository, independently from the license used for the files. There is actually a case where committing such files is possible, but this doesn't seem the case.

Your code can depend from files that are available from third-party sites, but you cannot commit them in Drupal.org repository; the reason for not committing them in Drupal.org repository are mainly four:

1. Drupal.org is not the repository for third-party project files; it is thought for Drupal themes, modules, and installation profiles.
2. If third-party files are committed in Drupal.org, then you would need to create a new version of your module every time there is a new version of the library files.
3. Every module that use the same library would need its own copy of the library files, with the consequence that a Drupal-powered site would have multiple copies of the same files, one copy for each module that uses those files; if the user is instructed to copy the files in a site directory, there would be a single copy of every file (the module need to be flexible on where to look for the required files).
4. In the case different modules require a different version of the library, there could be conflict issues. Imagine what would happen if a module would come with version 1.x of a jQuery plug-in, while another module comes with version 2.x of the same plug-in; if both the plug-ins would be loaded in the same page, one of the modules (or both) would not work correctly.

There are many modules that use third-party libraries, and they require the user to install them separately.

If the plugin is a modified version, and there is already a module that comes with the modified plug-in, then the proposed module should depend on it; if there is not a module that includes the modified jQuery plug-in, then including the plug-in would be the correct way (and it is listed between the reasons to include a third-party library).

I am just suggesting what should be done; this is not something that blocks the application approval.

Why don't you give ziomizar a chance to release this as a module? This is a essential functionality for many of us and there is no adequate solution for autocomplete in exposed filters or similar.

Hi Ziomizar,

Seems that your module is all I ever waited for! I installed your latest version, but I cannot get it running.

I tried to use it in views-mode. I selected the view ("Jobs") which I want to enhance by your autocomplete feature. In "Input field id:" I entered the name of the field I want to search through, in my case it is "field_location". In "The view filter name:" I entered to name of the filter, in my case it is "field_location_filter".

When I click "save" I get the message: "Filter #field_location_filter for Jobs not exits".

As I do not have enough Drupal experience I cannot see the mistake by myself.

Thank you in advance!

Best

Sebastian

Note: I cannot approve or decline CVS account applications, but I'm trying to help real coders in reviewing applications more efficiently. The following comments are *not* ground for approving or declining an application – just a help to get going.

I had a look at the module, and just a few comments:
* There was a typo in the module description (.info file) – 'ustom Sql' should probably be 'custom SQL'.
* In autocomplete.module, lines 79–85, there is a non-standard formatting on a comment.
* In autocomplete.module, the line break at line 242 and 243 decreases readability.
* In autocomplete.module, there are two blank lines at the end (while Drupal standard says one).
* In README.txt, line 27, there is a typo period (.) in the middle of the sentence.

I'd say all of these issues are minor, and not blockers for CVS account.
The module functionality seem different enough from other autocomplete modules.
I have NOT security reviewed the module.

Good luck!

I am changing the status as per previous comment.

Hi. Please read all the following and the links provided as this is very important information about your CVS Application:

Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for your application. Please read the following documentation on how this affects and benefits you and the application process:
Migrating from CVS Applications to (Git) Full Project Applications

• The status of this application will be put to "postponed" and by following the instructions in the above link, you will be able to reopen it.
• Or if your application has been "needs work" for more than 5 weeks, your application will be marked as "closed (won't fix)". You can still reopen it, by reading the instructions above.

Are there any news about this? I really, really need this functionality, and many other people do too. I've downloaded the last version of the module and tried using it on a view of my site, but I keep getting an error message ("filter x for view not exists")

This issue should be changed to 'needs review' -- if you're applying to create a 'real' project (and not only a sandbox project).

@gusti77: It should be possible to post issues and have discussions in the sandbox project, just so you know. And, I may add, it is good with feedback like this -- it shows that the module is needed and appreciated.

Updating issue with requirements as linked to in comment #33:

Updated title
Moved issue from the CVS to Git application queue

Link to the Sandbox Project Page: http://drupal.org/sandbox/ziomizar/1076018

Now that the application is in the proper application queue, another reviewer should be along to continue review process shortly. (Please be patient, as the current queue backlog is somewhere in the order of 4 weeks.)

Please address the open issue and move this back to "needs review" status.

The applicant has been contacted to ask if the application is abandoned.

The application has been closed. If you would like to reopen it, you are free to do so.
See http://drupal.org/node/894256