| bio | website | |
|---|---|---|
| location | Perth, Australia | |
| age | 29 | |
| visits | member for | 1 year, 10 months |
| seen | 36 mins ago | |
| stats | profile views | 26 |
Lead SharePoint developer for a major Australian mining company.
|
Nov 5 |
comment |
Dynamically registering JavaScript from within a sandbox web part I just updated the original question with a fourth option (which was posted in a comment by @eirikb). It uses the custom action method too, but he instead points it to a JavaScript function which then works out whether the script file should be loaded on the current page (as apposed to getting the custom action to blindly write the <script> tag). It's the most risky solution as I have no idea how much testing it's had (if any), but it's probably the cleanest as it can be used for CSS files too. Care to weigh in with an opnion? |
|
Nov 5 |
revised |
Dynamically registering JavaScript from within a sandbox web part Added fourth option (based on user comments). |
|
Nov 5 |
revised |
Dynamically registering JavaScript from within a sandbox web part deleted 31 characters in body |
|
Nov 5 |
comment |
Dynamically registering JavaScript from within a sandbox web part I wasn't aware you could use tokens inside the ScriptSrc value -- that makes it an attractive option. Unfortunately though, in my case, the JavaScript files registered by the web parts really shouldn't be loaded onto every page in the site, just the home page. So that's a real deal-breaker for me! My common scripts are already referenced directly in my master page. |
|
Nov 2 |
comment |
Dynamically registering JavaScript from within a sandbox web part That's very interesting indeed! I haven't downloaded your source yet, but it looks at first glance like you're using the CustomAction's ScriptLink attribute to call a "middle-man" function that you've written to do all the necassary checks (i.e. determine if the file is already loaded and that all its dependencies have loaded etc.). Is this about right? Some quick follow up questions... Are you able to control where / when in the DOM the scripts gets registered? For example, what if I want to ensure that my custom CSS is loaded either before or after the OOTB SharePoint stylesheets? |
|
Nov 2 |
revised |
Dynamically registering JavaScript from within a sandbox web part added 109 characters in body; edited tags |
|
Nov 2 |
asked | Dynamically registering JavaScript from within a sandbox web part |
|
Oct 26 |
comment |
Custom Content Query Web Part in a Sandbox Solution Thanks for your feedback. Unfortunately, the web part I am creating will be dropped onto the page by users (who aren't developers), so it needs to be completely hooked up to the plugin and all preconfigured. That is why I was trying to create a custom CQWP which I could then add to the gallery. Do you know of any other applicable web parts which I can access / implaement via code in a sandbox solution? This must surely be a common thing. |
|
Oct 26 |
asked | Custom Content Query Web Part in a Sandbox Solution |
|
Oct 19 |
comment |
How do you add Meta-tags/CSS/JavaScript to head on SharePoint Online (without unghosting the MasterPage) I'm using this method in a sandbox solution and it works great. The only problem I've found so far is that it doesn't check if the script file has already been registered before loading it. For example, if you add jquery-1.7.2.js this way in two seperate web part projects and add both web parts to the same page, then you will get 2x copies of jquery-1.7.2.js being sent to the browser. Do you know of any way to prevent this? I tried prefixing document.write(...) with if(!jQuery) but the custom action appears to get processed BEFORE the scripts have actally been loaded :/ |
|
Aug 24 |
awarded | Yearling |
|
Aug 23 |
comment |
How do I show the quick launch menu in a SharePoint foundation blog? Can you add some details Jash? Post your code, and also let me know exactly what page / URL it is you're having trouble with. |
|
Aug 21 |
comment |
“Service too busy” exception occurrs when trying to programmatically activate a sandbox feature with an attached feature receiver Thanks for your insights @Sreejit. All I'm doing is programmatically activating OOTB features though, so there's not much I can do about reducing the load on the CPU. For the record, I'm still searching for an answer on this... |
|
Aug 21 |
awarded | Critic |
|
Aug 17 |
asked | Custom SiteMapProvider in Sandbox Solution |
|
Aug 14 |
comment |
Can not update Navigation programatically One more thing to add... If you create your subsite using a custom WebTemplate instead, then you can configure the navigation by simply passing in the appropriate feature properties. See below: <!-- Per-Web Portal Navigation Properties -->
<Feature ID="541F5F57-C847-4e16-B59A-B31E90E6F9EA">
<Properties xmlns="http://schemas.microsoft.com/sharepoint/">
<Property Key="ShowSiblings" Value="false" />
<Property Key="IncludeSubSites" Value="true" />
<Property Key="IncludePages" Value="false" />
</Properties>
</Feature>
I can confirm that this works in a sandbox solution. |
|
Aug 10 |
answered | Can not update Navigation programatically |
|
Aug 10 |
comment |
Compiling code against the Microsoft SharePoint 2010 sandbox assembly Thanks for your feddback, and for confirming my same thoughts (unfortunately!). I've had to change my references back to the regular SharePoint assembly, but we do periodically replace it with the sandbox version just to verify we don't have any bugs before we do a build / release. |
|
Aug 10 |
accepted | Compiling code against the Microsoft SharePoint 2010 sandbox assembly |
|
Aug 9 |
comment |
Can not update Navigation programatically Hi @Davy. I'm also working on a sandbox solution and need to initialise the navigation settings on my publishign sites. Did you ever find a workaround? |