Re: An idea for Q filter objects

[Tim Graham]

I think the issue would be fixed by tackling the ticket, "Get rid of 
field.get_db_prep_lookup()" [0]. If I understand correctly, the exception 
is coming from DateField.get_db_prep_value() which is trying to do the 
conversion to a datetime.

[0] https://code.djangoproject.com/ticket/22936

On Monday, March 28, 2016 at 8:00:19 PM UTC-4, Michael E wrote:
>
> I don't know if this is possible, but I think it would highly useful if it 
> were.
>
> Basically, I want to filter a DateField as though it were a string (see 
> the StackOverflow post 
> 
>  to 
> understand why)
>
> If there was an option on a Q filter like this:
>
>  Q(field__icontains="data", *T**ypeCheck=False*)
> ^^
>
> (instructing Django to bypass type checking for this field)
>
> it would then be possible to do *datatype conversion on the database 
> level*, allowing code like this to work
>
> from django.db.models import Lookupfrom django.db.models.fields import 
> DateField
> @DateField.register_lookupclass DateTextFilter(Lookup):
> lookup_name = 'dttxt'
> def as_postgresql(self, compiler, connection):
> lhs, lhs_params = self.process_lhs(compiler, connection)
> rhs = self.rhs.strftime("%b %d, %Y") # this would be replaced by a 
> partial date. e.g., 'Mar 05'
> return "to_char(%s,'Mon DD, ') ~* '%s'", ([lhs,rhs])
>
>
> Currently, this causes a ValidationError
>
> ValidationError: [u"'Mar 09' value has an invalid date format. 
> It must be in -MM-DD format."]
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d70ffcca-f7fa-442e-808a-c2c30780f78d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

An idea for Q filter objects

[Michael E]

I don't know if this is possible, but I think it would highly useful if it 
were.

Basically, I want to filter a DateField as though it were a string (see the 
StackOverflow 
post 

 to 
understand why)

If there was an option on a Q filter like this:

 Q(field__icontains="data", *T**ypeCheck=False*)
^^

(instructing Django to bypass type checking for this field)

it would then be possible to do *datatype conversion on the database level*, 
allowing code like this to work

from django.db.models import Lookupfrom django.db.models.fields import DateField
@DateField.register_lookupclass DateTextFilter(Lookup):
lookup_name = 'dttxt'
def as_postgresql(self, compiler, connection):
lhs, lhs_params = self.process_lhs(compiler, connection)
rhs = self.rhs.strftime("%b %d, %Y") # this would be replaced by a 
partial date. e.g., 'Mar 05'
return "to_char(%s,'Mon DD, ') ~* '%s'", ([lhs,rhs])


Currently, this causes a ValidationError

ValidationError: [u"'Mar 09' value has an invalid date format. 
It must be in -MM-DD format."]

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f38f1e24-df0e-422f-a1c3-5105911a8ece%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Add HTML5 required attribute on form widgets

[Jon Dufresne]

Hi,

I'm working on ticket #22383 to add the HTML5 required attribute to form
widgets.

The hope is this will add an additional level of validation at the client
side. The feedback provided to the user is much faster than a server round
trip.

This is something I've done manually in my own projects. I'll frequently
add "required" to widget attrs to take advantage of this validation. As I
already use this frequently, I'm motivated to see it adopted by the Django
core.

This feature have been discussed in the ticket [1] as well as a previous
email thread [2].

In the past, there were two discussed concerns:

* Allow a project to opt-out of using the required attribute
* Add a deprecation warning that new version of Django will include the
required attribute

Past discussion settled on using the class attribute
Form.use_required_attribute to decide if a form's widget should render the
HTML5 required attribute. As this was the previous consensus I have
implemented a PR [3]. To be on the safe side, this PR also adds the
deprecation warning.

Upon review, Tim Graham replied with the following:

I fear the deprecation will be quite annoying if every form in a project
> needs to be modified to silence all warnings.
> ...
> I guess I'm not sure if a deprecation path provides more value than making
> a backwards-incompatible change. For example, if we expect a majority of
> projects to adopt this change, then a deprecation will require every Django
> project to silence the warning instead of a subset of users to opt-out.
>

No problem for me. I'm OK skipping the deprecation path. I don't see it as
necessary, I was simply trying to accommodate other opinions. I have
created a second PR which is identical to the first, but without the
deprecation warning [4].

Also in the review Tim suggested the following:

I wonder if template-based widget rendering (#15667
> ) might ease this change. A
> project could provide custom widget templates if they don't want the
> required attribute (or if they want required='required'.
>

This is a different approach than previously discussed. I see the merit in
this suggestion and think it could be a better implementation. With this
idea, we could avoid adding the Form.use_required_attribute, entirely.
However, template-based widget is still very much a WIP. I worry waiting on
that feature may mean this simpler feature may miss a release cycle. Is it
reasonable to expect the template-based widget rendering to land before the
next alpha/beta cut?

Tim asked I post these ideas to the mailing to get other opinions and
feedback on these two points.

Thanks,
Jon


[1] https://code.djangoproject.com/ticket/22383
[2]
https://groups.google.com/forum/#!topic/django-developers/obw18wSc4xU/discussion
[3] https://github.com/django/django/pull/6341
[4] https://github.com/django/django/pull/6352

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b7z08aYuY_wpzCCkCaEfOAT5uQvh74wsPCJoZT0hF5aGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.