Wondering why there is no field formatter support for 'Float' type, such that editors could enter a more precise float value and display that as stars. E.g. 4.25 (out of 5).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

girishmuraly’s picture

Status: Active » Needs review
FileSize
1.6 KB

Attaching a patch to alter field schema to hold float values instead of int.

Along with this patch, I've created this sandbox module to allow entering of float values. More info and usage on the sandbox page.

Depending on the community reaction, I hope to either merge the sandbox with fivestar (as a submodule if necessary), promote to full project, or discontinue if better alternatives are suggested. Thanks.

ericduran’s picture

Status: Needs review » Needs work

I say lets bring it on board. This is going to require a proper update hook.

Also I'm not totally convinced you need the different field widgets (unless you really want to enter 3.145). At most maybe some new formatters or even better adding a precision value to the current formatter.

Would this work for you?

girishmuraly’s picture

Thank you :)

As far as requirements go, we need to be able to enter float values with one decimal point precision e.g. 2.3 & 4.1. More precision e.g. 2.14, 4.23 is not required. If such values are entered, we could either discard the value beyond the first decimal point or round up to the first decimal point (2.14 becoming 2.2).

I'm not sure how we can enter decimal point ratings using the field widgets supplied by the module at present, which is why I added the fivestar_float widget. On the contrary, I felt a new formatter is not needed, however adding a precision value to the current formatters should work just as well. Making the precision value setting configurable in the formatter would be ideal.

Regarding an update hook, on my local sites, this one was sufficient - function fivestar_float_alter_field_schema() along with the patch in #1. The main challenge was hook_field_schema() is not alterable. However I'm sure we would have to expand on that to cater to all use cases. Eager to know your views.

ericduran’s picture

Ah I see, In that case lets also bring in the new field widget.

The schema alter would work in the sandbox this now this would need to cover everyone's case. So we'll need a hook_update_N that would alter the schema properly and also not empty out the field table.

girishmuraly’s picture

If we are planning on a sub-module, then its hook_install() is enough. Otherwise we need the hook_update_N(). If it is to be made part of the main module, it would mean altering fivestar_field_schema() as mentioned in patch #1. Is that what you have in mind? I am for integrating into main module itself, cos a sub-module that alters field schema is not very nice.

Also, how can I help in this integration? It would mostly be copying over stuff from the sandbox module with few alterations to put everything in place and then also adding the hook_update_N() as required. Thanks.

ericduran’s picture

It can't be a sub-module because you're altering the field_schema. It has to be in the core module.

All that's needed to get this done is a patch with the new widget in your sandbox and creating a hook_update_N. Once there's a patch with everything I'll commit it. :)

girishmuraly’s picture

I have integrated the code from my sandbox onto the latest code and tested. All seems to be working fine so far.

Pending:
* fivestar_update_7206() updates the field schema for fields that do not hold data only. Need a way to update the appropriate 'rating' column in tables that have data. field_update_field() does not do this when tables have data. The only option seems to be collecting all the field table names and altering them using the Database API. I would like to hear your thoughts on this too before committing a solution.

Future Todo:
* An option for controlling precision in the display side (formatter).

I would appreciate if you could test the patch and let me know what you think. You should be able to see a new field widget called "Float field (rated while editing)". On the widget form, it would be displayed as a textfield, for which there are 'field_prefix' and 'field_suffix' settings on the widget settings form (for adding text like 'out of 5.0' etc.)

Thanks.

girishmuraly’s picture

Status: Needs work » Needs review

Setting as needs review / bump!

marcelovani’s picture

marcelovani’s picture

skruf’s picture

Here is a revised patch which fixes a bug which allowed values higher than the 'star' value and displayed the value as a percentage if the form failed validation.

After speaking with Girish I've also removed the schema alter as 2 decimal point precision should be ample for the majority of user cases.

girishmuraly’s picture

To sum up, the patch in #11 does the following:

  • Fixes a bug in patch #7 whereby when a form (e.g. node form having a fivestar rating while editing field) fails validation, any input entered in the fivestar field is displayed as percentage instead of its original value on the reloaded form.
  • Floating point precision fixed upto 2 decimals only - no schema alteration required. We can tackle extra precision and its configuration as a rare case later, as we think having two point precision is better than none for now and more precision is a rarer use case.

This should be an easy patch to apply onto the main module itself.

girishmuraly’s picture

Issue summary: View changes

Updated issue summary.