Opened 2 years ago

Last modified 2 years ago

#25741 assigned Cleanup/optimization

Make 'request' available to syndication.Feed methods

Reported by: Ramez Issac Owned by: Alex Morozov
Component: contrib.syndication Version: 1.8
Severity: Normal Keywords: syndication, request
Cc: ramezashraf@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Use case : adding an image to feed.
i will to override Feed.item_extra_kwargs() and get my image url, But i can't make a Full URL as i'm missing the request.host

Proposal:
Add request to Feed class so it's accessible via self.request (as CBV)

Change History (8)

comment:1 Changed 2 years ago by Ramez Issac

Type: UncategorizedCleanup/optimization

comment:2 Changed 2 years ago by Alex Morozov

Owner: changed from nobody to Alex Morozov
Status: newassigned

comment:3 Changed 2 years ago by Tim Graham

Triage Stage: UnreviewedAccepted

Looks like an okay idea at first glance.

comment:4 Changed 2 years ago by Alex Morozov

I believe this will require functionality similar to View.as_view() to be thread-safe. Or even sublassing the Feed from the generic View. But this apparently will break backwards compatibility.

@timgraham, what do you think about it? Is it worth bothering?

comment:5 Changed 2 years ago by Ramez Issac

Either add it to the Feed class in Feed.__call__() , or later on in Feed.get_feed()
If that is not convenient for some reason (@alexmorozov care to elaborate on thread safe part, How this wont be thread safe?! I'm not an expert in this area)
Got it, request is a class attribute in our case.

Another option is to send request as a parameter.. not a big fan of that road.

Last edited 2 years ago by Ramez Issac (previous) (diff)

comment:6 in reply to:  4 Changed 2 years ago by Ramez Issac

Replying to alexmorozov:

I believe this will require functionality similar to View.as_view() to be thread-safe. Or even sublassing the Feed from the generic View. But this apparently will break backwards compatibility.

Can we implement as_view() code in the __call__() behind the scenes and escape backward-incompatibility ?!

comment:7 Changed 2 years ago by Alex Morozov

@RamezIssac: I surely can implement it either as a as_view() addition or a __call__() override. The problem is, AFAIK, Django is very conservative when it comes to breaking compatibility (it seems to me, the __call()__ override will break it too).

So I'd like to get an approvement from core devs before I start, so that my work won't be ultimately dumped.
I you ask me, I believe we should subclass the generic.View.

comment:8 Changed 2 years ago by Alex Morozov

Easy pickings: unset

Clearing the 'Easy pickings' flag, as it is obviously not the case.

Note: See TracTickets for help on using tickets.
Back to Top