Duplicates

[proft]

Hi!

Every time I press Save in admin I have 2 new color (#000). It doesn't depend if I change field with color, just click Save ... Why?

My model:

class Color(models.Model):
    color = RGBColorField(verbose_name=u'Color')
    ware = models.ForeignKey(Ware, verbose_name=u"Ware", related_name="colors")

My admin:

class ColorInline(admin.TabularInline):
    model = Color
    extra = 2
    max_num = 10

@admin.register(Ware)
class WareAdmin(admin.ModelAdmin):
    list_display  = ('id','title',)
    inlines = [ColorInline,]

[charettes]

Does your browser use the native color input or the JS fallback?

[hplodur]

Hi Simon,

I think my problem is a bit different, but let my try to explain better. I'm writing a shift plan application. As my Department has three teams we would like to colour the rows according to the team (it will be one big table for the department and user from different teams will have a different colour of the raw... lets say team 1 - blue, team 2 - green and team 3 white). The shifts will also have their own colours (morning - green, evening - blue but we would like to leave the colour of the normal shift the colour of the Department). In my case everything is working correctly but it is not possible to leave the field empty as the default colour is always set to default #000000. Here is how my class looks:

class Shift(models.Model):

def __unicode__(self):
    return self.shift
shift = models.CharField(max_length=20)
shift_code = models.CharField(max_length=5)
shift_bg_color = RGBColorField(null=True, verbose_name="Background Color")
shift_txt_color = RGBColorField(null=True, blank=True, verbose_name="Text Color")
shift_start_time = models.DecimalField(choices=TIME_CHOICE, null=True, max_digits=5, decimal_places=2)
shift_end_time = models.DecimalField(choices=TIME_CHOICE, null=True, max_digits=5, decimal_places=2)
lunch_start_time = models.DecimalField(choices=TIME_CHOICE, null=True, blank=True, max_digits=5, decimal_places=2)
lunch_end_time = models.DecimalField(choices=TIME_CHOICE, null=True, blank=True, max_digits=5, decimal_places=2)
comments = models.CharField(max_length=20, blank=True, null=True)
department = models.ForeignKey(Department)

What I'm trying to achieve is that while creating the shift default value of #000000 will not be passed to the database... I thought that setting blank=True will fix the problem but when adding the new shift the default black colour is there.

Is there a possibility to not put the default colour and leave the field empty?

Thank you very much for your help.

Kind regards,
Tomasz

[charettes]

Hi Tomasz,

You have the exact same issue, you want to have a blank field and not one that defaults to #000000.

Does your browser use the native color input or the JS fallback?

[hplodur]

For my test I use firefox 31.4.0 in CentOS VM. Sorry for asking dummy questions but how can I check it?

[charettes]

Don't worry, if you're using such an old version of FF you must be using the JS fallback.

[hplodur]

Is it not possible to have it working with JS Fallback? Only Native Color Input will work?

[charettes]

@kraiz, it looks like the update of jquery.colorPicker made empty fields turn into #00000. Do you have an idea of what might be happening?

[charettes]

@hplodur, it should be working. I'm trying to figure out why it's not.

[kraiz]

Hey...joining the conversation. I had a look at this and i think the problem is not the fallback as the screenshot above actually shows a native input which FF supports from 29+.

It seems like you can't really have an empty color input value as the spec omits any word on it and leaves this to the browsers.

<input type="color">

Chrome will give you "#000000" (requested in JS and submitted via POST). In IE11 it's an empty string (it doesn't support color input and handle the field as normal text input). I would guess FF follow Chrome on this.

The JS fallback just requests the current value and writes it to the input. Through the effect above this explicitly writes "#000000" into the input field for Chrome and FF, but "#FFFFFF" for IE as this is the colorpicker-library-default.

All in all: Seems like we can't have an empty value the easy way and may need to work around here in some clever way. But anyway i feel we should provide a browser independend default value.

Am i right on this @charettes? What do you think?

Besides all this...the colorpicker-library-update of #23 shouldn't have to do anything about that. I guess that @hplodur is using the current pypi version (1.1.0)?

[charettes]

Thanks for the investigation @kraiz, greatly appreciated.

What do you think of allowing the users to force the use of a type="text" with the fallback on a widget an automatically do it when dealing with a non-required forms.ColorField. Are we even sure the fallback widget doesn't behave the same way and the native one on Chrome/FF?

[kraiz]

Wouldn't vouch for that :) Needs to be tested. The current fallback-js-library does not support empty values either.

Native vs. fallback-enforced input in case of non-required field needs to be documented in a kind of highlighted way. I would not expect that the fancy color chooser (i love it in android chrome) disappears when i add blank=True to the model field. But this way we're able to support the basic django feature of optional fields independent of browsers implementation.

I think about that and maybe have an experiment with spectrum. It has a polyfil-mode (for required color field) and an "allowEmpty" option (for non-required color fields). It maybe saves some work on our side.

[charettes]

@kraiz, spectrum looks like an interesting candidate. I wouldn't mind switching to it and documenting it will be automatically used if you specify your field must be blank.

[kraiz]

Yeah, i had a look some time ago and just want to keep you updated. I found out that spectrum is missing datalist support, which would be great for the polyfill usecase. So i added it but the PR ( bgrins/spectrum#368 ) is hanging around unseen.
Maybe it's not to bad as we can workaround by instanciating the library (setting the preset palette as parameter) as it's done with current colorpicker but with the PR it would be way cleaner.
Anyway my time is limitted at the moment and this changes by the end of the year. When is PR is not merged until then, i'll have a look at the workaround.

[cjmochrie]

I'm not sure if this is related, but running Ubuntu 14.04 both Chrome 50 and FF 46 do not render the HTML 5 color input and instead use the shim (which does not accept custom Hex input).

[charettes]

@cjmochrie I'm running Ubuntu 14.04 and the HTML 5 native color input is used in both cases. I just tested with Django 1.9.6 and django-colorful 1.2 on Firefox 46 and Chromium 49.0.2623.108.

[cjmochrie]

@charettes Thanks for the quick reply!
I found the issue (not colorful). It's a conflict with django-grapelli. Found this in their docs:

"GRAPPELLI_CLEAN_INPUT_TYPES Replaces HTML5 input types (search, email, url, tel, number, range, date, month, week, time, datetime, datetime-local, color) due to browser inconsistencies. Set to False in order to not replace the mentioned input types."

After setting that to False, the HTML5 input rendered as expected. This seems like an issue that might trip somebody else up as Grappelli is pretty popular. I could make a PR to the README with a note about this if you'd like?

[charettes]

Sure, thanks for the investigation!