On Mon, Aug 12, 2013 at 4:09 PM, Olemis Lang <[email protected]> wrote:
> On 8/12/13, Matevž Bradač <[email protected]> wrote: > > On 12. Aug, 2013, at 19:08, Olemis Lang wrote: > > > [...] > > > >>> It seems logical for the Boostrap code to be part of the ThemePlugin > >>> since > >>> it is responsible for adding Boostrap to all of the pages (via > >>> `bloodhound_theme.html`). I agree with the aim that "Bootstrap-specific > >>> enhancements should be added by theme". If more work needs to be done > >>> for > >>> this to be realized in BloodhoundDashboard, then I think we should at > >>> least > >>> consider making those changes. > >>> > >> > >> Not all bootstrap styles have to be added by theme . Widgets are > >> «self-contained» components so they have to take care of loading > >> required assets , including bootstrap css+js , no matter on what > >> context they are inserted . > > > > IMO this also speaks in favour of a "core" package. Although the widgets > > are self-contained, we probably want to avoid having each widget bring > > their > > own copies of all the needed resources - this could presumably lead to > > various (in)compatibility issues etc. > > > > Yes . Even if using add_(script|stylesheet) if the the same lib code > is loaded from different locations then it will be executed twice ... > definitely triggering errors , not to mention the degraded performance > due to download overhead . > > For JS however there's yet another solution . What I do in practice in > my plugins is similar to Trac's jquery_location i.e. > > - declare an option e.g. [trac] bootstrap > That seems like a useful enhancement for Bloodhound. > - set its default value to load it from a well know CDN location > * e.g. my preferred option is Cloudflare's CDNJS , the value > would be like this > //cdnjs.cloudflare.com/ajax/libs/twitter-bootstrap/2.3.1 > - URLs to individual files would be generated from there . > - All components will read that option , it does not really matter > where exactly it is defined as long as it will be read from the > same location . > > The only drawbacks with this approach is that in Trac it seems that > href generation with protocol off is buggy , so I always end up > including it ... > Is it something we could push a fix for back to Trac for the 1.0.2 release? > [...] > > -- > Regards, > > Olemis - @olemislc >
