On 15 čnc, 01:22, Carl Meyer <carl.j.me...@gmail.com> wrote: > On Jul 14, 4:15 pm, SmileyChris <smileych...@gmail.com> wrote: > > > We also need d) Media hooks for a single widget - whether this can be > > done in only the template layer is a tricky problem... > > > I'm still struggling with how you'd be able to render all the media at > > the top of your template for the form. I guess you'd have to define > > any field widget overrides in that block, before rendering the form > > media. > > Yeah, this is tricky. For JS generally it shouldn't be rendered until > the bottom of the template, for page-speed reasons, but the reverse is > true for CSS. I don't think there's yet been a proposal in this thread > for how to enable rendering widget media before the form is rendered, > both proposals so far would have you specifying/overriding chrome (or > widget templates) only at form-render time. > > Obviously it'd also be good to be able to split CSS from JS, like the > Media framework allows. > > One half-baked idea: what about annotating the form object itself with > information about customizations you've made: paths to form-rendering > templates and widget templates? So you could use the same > customization syntax when rendering the form or rendering the form > media, whichever you do first, and it would remember those > customizations for later? > > This introduces a little more cleverness than I'd prefer, but if the > only other option is repeating every customization twice... I'm also > not sure how this would interact with the idea that the "form media > render" tag should accept multiple form objects, so even if you use > the same widget/chrome in multiple forms on a page, its media still > only gets rendered once. > > Carl
I think that the best practice is not to use css and js in the html page, only in external files (but maybe it is too theoretical opinion, impossible in reality). I would not like if an reusable widgets library embed css or js in my pages. And if there is an requirement that widget's specific css or js code could be in different request, it is much more complicated - generation of forms could be very dynamic and generally it is not possible to say which widgets are used without repeating the process. For me, the right reusable widgets library would: - implement html code without any css or js, - implement external css and/or js code - static or dynamic, - embed some hints for js and/or css in html code (html class for widget identification or possibly more complex information such as html5 data-* attributes for situations as slug fields in admin), - give me a note that I have to reference some js and/or css files. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
