- Steve McNiven
Check this out:
Keep in mind this assumes the control has been registered with an “sf prefix”, either at the top of the page or in the webconfig.
What’s it all about
So you get one simple to use control which will handle both scripts and styles. The bonus is that the scripts will automatically render at the bottom of the page, and styles will render in the header. However you can feed the control a property to change the position of the script.
<sf:ScriptStyle runat="server" ScriptEmbedPosition="InPlace"
- BeforeBodyEndTag (default)
This is one thing the Sitefinity controls can’t do…inline scripting\styling. You need to hard-link to a physical file in the markup. LIMITATION, REMOVED!
- Inline code in the markup
- Duplicate script detection: Will only load scripts once. If you have 5 ScriptStyle widgets all loading the same script, it’ll only appear on the page once. (Keeping in mind…it’s not searching the page for what scripts are there, it’s just checking other instances itself). So if you manually have a script linked on the masterpage, then you link it again in this widget…it’ll appear twice.
- Visual Studio\Editors will syntax highlight the inline code
- Ability to render in multiple places on the page
- Automatic detection and wrapping of the <script and <style nodes
- You can set an alias that will render in design mode so you can denote what the code you’ve written will do. Currently NOTHING renders in the existing widgets so you have to keep opening them to figure out what they do.
- Define if you want the script to run in design mode or not
- You won’t get caught hard-coding the domain prefix on your links…this is a bug in SF that nobody just ever seems to want to take the 30 seconds to fix.
- Doesn’t render an empty \on your page where you dropped the widget
(from 6.0.4200.0 to 6.0.4200.1)
@Telerik I’ll be happy to give you this control to tweak and put into the SF core (and remove it from my assembly)…it’s better than yours :)