from discord 2023-09-08, just an idea for an enhancement (not urgent at all)
Bery
Hi,
I was thinking lately about some kind of assets collector "extension"
I have a few pages on my project where I dont use iommi (e.g. a FBV page with one file-input and ajax for xlsx import of some data) but I still need some assets there (js/css) that I have in Style for iommi pages, and maintaining those on multiple places is quite annoying.
So I think it would be nice to have "collectors" of Assets, one root (global, for all pages) and one bound to request with registrators, plus a context processor and something like StyleAssetsFromCollector
have you needed something like that before? or done it?
or have you thought about "contrib/" or "extensions/" or something in iommi, that isnt really iommi-core but is still related?
boxed
I guess that makes sense. So you can more easily write straight FBVs... otherwise there's also https://docs.iommi.rocks/en/latest/cookbook_porting.html to port FBVs into iommi. I'm not 100% happy with that solution though.
How about the iommi middleware adding iommi_assets to request on the way in and then in your FBVs you can do <head>{{ request.iommi_assets }}</head> or something?
hmm. in that case, we should change iommi to use the same API internally
Bery
I was thinking about {{ request.iommi_assets }} too, but I'm not too experienced with django yet, so I'm not sure how people feel about accessing request in templates? to me it feels a bit "not cool" 🙂
Btw this was just a thought I had lately, I'm not really in a hurry for this, but I think it might be quite nice
And maybe it would be better to first put all js code from templates into static/ 🙂
boxed
I think it's pretty ok to access request. Especially if the alternative is to require an iommi context processor. That makes the installation more complex and I don't want that.
Bery
one way to look at it... on the other hand if you use context proccessor, the variable can still be named iommi_assets, so if someone overrode base.html, it would be backwards compatible, except for the settings.py 🙂
boxed
if we put it on request you get the same advantage
Bery
oh, to put it as context={"iommi_assets": request.iommi_assets}? true
and there might be decorators for FBV's @with_extra_assets(**kwargs)
boxed
No I mean if we put it on the request object.
hmm.. yea ok, I see the decorators thing. If you want select2 for example?
from discord 2023-09-08, just an idea for an enhancement (not urgent at all)
Bery Hi, I was thinking lately about some kind of assets collector "extension" I have a few pages on my project where I dont use iommi (e.g. a FBV page with one file-input and ajax for xlsx import of some data) but I still need some assets there (js/css) that I have in Style for iommi pages, and maintaining those on multiple places is quite annoying. So I think it would be nice to have "collectors" of
Assets, one root (global, for all pages) and one bound torequestwith registrators, plus a context processor and something like StyleAssetsFromCollectorhave you needed something like that before? or done it? or have you thought about "contrib/" or "extensions/" or something in iommi, that isnt really iommi-core but is still related?
boxed I guess that makes sense. So you can more easily write straight FBVs... otherwise there's also https://docs.iommi.rocks/en/latest/cookbook_porting.html to port FBVs into iommi. I'm not 100% happy with that solution though. How about the iommi middleware adding
iommi_assetstorequeston the way in and then in your FBVs you can do<head>{{ request.iommi_assets }}</head>or something? hmm. in that case, we should change iommi to use the same API internallyBery I was thinking about
{{ request.iommi_assets }}too, but I'm not too experienced with django yet, so I'm not sure how people feel about accessing request in templates? to me it feels a bit "not cool" 🙂 Btw this was just a thought I had lately, I'm not really in a hurry for this, but I think it might be quite nice And maybe it would be better to first put all js code from templates into static/ 🙂boxed I think it's pretty ok to access request. Especially if the alternative is to require an iommi context processor. That makes the installation more complex and I don't want that.
Bery one way to look at it... on the other hand if you use context proccessor, the variable can still be named
iommi_assets, so if someone overrode base.html, it would be backwards compatible, except for the settings.py 🙂boxed if we put it on request you get the same advantage
Bery oh, to put it as
context={"iommi_assets": request.iommi_assets}? true and there might be decorators for FBV's@with_extra_assets(**kwargs)boxed No I mean if we put it on the request object. hmm.. yea ok, I see the decorators thing. If you want select2 for example?
...