Comments on: "Guru of governance?" http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/ After much frustration, it seems DEFAULT is the way to go... Tue, 27 Jul 2010 11:20:51 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Ryan McIntyre : Web.Config FeatureReceiver Update http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/comment-page-1/#comment-1349 Ryan McIntyre : Web.Config FeatureReceiver Update Mon, 21 Jul 2008 16:54:51 +0000 http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/#comment-1349 [...] However, during that discussion, we talked a bit about security.  Mike referred me to a post by a colleague of his inspired by this very topic.  The gist of the discussion and post is that modifying the [...] [...] However, during that discussion, we talked a bit about security.  Mike referred me to a post by a colleague of his inspired by this very topic.  The gist of the discussion and post is that modifying the [...]

]]> By: CleverWorkarounds » A neat trick with the publishing feature http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/comment-page-1/#comment-1329 CleverWorkarounds » A neat trick with the publishing feature Sat, 19 Jul 2008 14:48:11 +0000 http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/#comment-1329 [...] only ever modify settings related to that site collection. I previously blogged about how it was bad practice for a site collection feature to modify the web.config files for a given web application. If you [...] [...] only ever modify settings related to that site collection. I previously blogged about how it was bad practice for a site collection feature to modify the web.config files for a given web application. If you [...]

]]> By: admin http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/comment-page-1/#comment-685 admin Thu, 05 Jun 2008 23:53:55 +0000 http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/#comment-685 Hey Ryan In the case of webparts, if they are bunded into a solution (wsp file then there is no need to deal with it at the feature level. the solution manifest can make this change for you and since installing a solution is performed by a farm administrator, the security boundaies remain intact. cheers Hey Ryan

In the case of webparts, if they are bunded into a solution (wsp file then there is no need to deal with it at the feature level. the solution manifest can make this change for you and since installing a solution is performed by a farm administrator, the security boundaies remain intact.

cheers

]]> By: Ryan McIntyre http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/comment-page-1/#comment-683 Ryan McIntyre Thu, 05 Jun 2008 18:31:01 +0000 http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/#comment-683 Mike and I have talked about this topic before (he pointed me to your post) since we were thinking of very similar ideas surrounding web.config modifications. I was thinking more on this recently...Since deploying a web part required a SafeControl entry into the web config, would you recommend all web parts be scoped at the web application level? Mike and I have talked about this topic before (he pointed me to your post) since we were thinking of very similar ideas surrounding web.config modifications. I was thinking more on this recently…Since deploying a web part required a SafeControl entry into the web config, would you recommend all web parts be scoped at the web application level?

]]> By: Neil Richards http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/comment-page-1/#comment-395 Neil Richards Mon, 21 Apr 2008 21:21:21 +0000 http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/#comment-395 Just a quick update to share. turns out the use of the web.config was unnecessary (indeed inappropriate). Really I should have been using configurable web-part properties (which allow for both hard-coding AND changing). Part of the problem was I didn't know how to get relative urls (to point to the 12hive). The same approach for getting relative urls (SPContext.Current.Site.ServerRelativeUrl) can be used to find sharepoint objects throughout the site, so by being a litte bit clever, changes to the web.config can be minimised (which seems like a positive thing). Thanks again. Just a quick update to share.

turns out the use of the web.config was unnecessary (indeed inappropriate). Really I should have been using configurable web-part properties (which allow for both hard-coding AND changing). Part of the problem was I didn’t know how to get relative urls (to point to the 12hive).

The same approach for getting relative urls (SPContext.Current.Site.ServerRelativeUrl) can be used to find sharepoint objects throughout the site, so by being a litte bit clever, changes to the web.config can be minimised (which seems like a positive thing).

Thanks again.

]]> By: admin http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/comment-page-1/#comment-369 admin Thu, 17 Apr 2008 17:13:01 +0000 http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/#comment-369 No problems, you have renewed my faith that app developers and governance can co-exist :-) cheers mate Paul No problems, you have renewed my faith that app developers and governance can co-exist :-)

cheers mate

Paul

]]> By: Neil Richards http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/comment-page-1/#comment-368 Neil Richards Thu, 17 Apr 2008 16:45:20 +0000 http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/#comment-368 Really helpful, thanks. I'm keen to have something admin friendly / admin approved, and what you say about activating features makes perfect sense. With your help I think I'm on the right track now. Really helpful, thanks. I’m keen to have something admin friendly / admin approved, and what you say about activating features makes perfect sense. With your help I think I’m on the right track now.

]]> By: admin http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/comment-page-1/#comment-367 admin Thu, 17 Apr 2008 09:55:57 +0000 http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/#comment-367 In relation to GUID or hard code, forget GUID I think - I'm sure you can go by name (but I don't code full time I'd have to double check). But you can draw some comfort from some of the ideas used by the publishing feature. Upon enablement, several lists and libraries are created in the root of the site collection, meaning that it does rely on hard coded paths, relative to the site collection root. In relation to placing files in the 12 hive, your right, it is theoretically available to any site collection, but its the solution that does this, not feature activation. Solutions are always added to the store by the farm administrator. Thus those supporting files can be placed in their correct locations via the activation of the solution by the farm administrator. But the farm administrator chooses which web app to deploy the solution to, which is in the form of a feature. So only 1 web app would have the feature available to be activated from. (And at this point web.config has been adjusted for safecontrol and the like). At that point, all of the pre-requisite files are in their right places, and all activating the feature does is add the web part to the gallery of the site collection, and create some of the supporting config items. Hope this helps, its only off the top of my head though so apologigies if I get it wrong.. In relation to GUID or hard code, forget GUID I think – I’m sure you can go by name (but I don’t code full time I’d have to double check). But you can draw some comfort from some of the ideas used by the publishing feature. Upon enablement, several lists and libraries are created in the root of the site collection, meaning that it does rely on hard coded paths, relative to the site collection root.

In relation to placing files in the 12 hive, your right, it is theoretically available to any site collection, but its the solution that does this, not feature activation. Solutions are always added to the store by the farm administrator. Thus those supporting files can be placed in their correct locations via the activation of the solution by the farm administrator.

But the farm administrator chooses which web app to deploy the solution to, which is in the form of a feature. So only 1 web app would have the feature available to be activated from. (And at this point web.config has been adjusted for safecontrol and the like).

At that point, all of the pre-requisite files are in their right places, and all activating the feature does is add the web part to the gallery of the site collection, and create some of the supporting config items.

Hope this helps, its only off the top of my head though so apologigies if I get it wrong..

]]> By: Neil Richards http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/comment-page-1/#comment-366 Neil Richards Thu, 17 Apr 2008 08:00:09 +0000 http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/#comment-366 Thanks for the response, I thought of doing what you suggested, but couldn't figure out how to avoid hard coding list guids or file paths into my code (i.e. the guid of the config list or the path of the xml file). I suppose I could put the xml file into %12hive%/TEMPLATES/LAYOUTS/INC/myfolder/ Also, my deployment feature is pushing a number of files into the 12 Hive (css, ascx user control, javascript for ajax, etc). The inenvitable impact is that these become available to every site collection. So that seems to only be appropriate at the web-application (or farm?) scope. I'm using Ted Pattison's stsdev tool which you've written about previously, and it seems like using the 12hive for this purpose is "best practice", but it feels a little messy, as every sharepoint site now gets access to the underlying resources. Thanks for the response,

I thought of doing what you suggested, but couldn’t figure out how to avoid hard coding list guids or file paths into my code (i.e. the guid of the config list or the path of the xml file).

I suppose I could put the xml file into %12hive%/TEMPLATES/LAYOUTS/INC/myfolder/

Also, my deployment feature is pushing a number of files into the 12 Hive (css, ascx user control, javascript for ajax, etc). The inenvitable impact is that these become available to every site collection. So that seems to only be appropriate at the web-application (or farm?) scope. I’m using Ted Pattison’s stsdev tool which you’ve written about previously, and it seems like using the 12hive for this purpose is “best practice”, but it feels a little messy, as every sharepoint site now gets access to the underlying resources.

]]> By: admin http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/comment-page-1/#comment-365 admin Wed, 16 Apr 2008 23:53:43 +0000 http://www.cleverworkarounds.com/2008/04/04/guru-of-governance/#comment-365 The settings of this web part - should the site collection administrator be the one to modify them? If that is the case, one option is possibly to use a list on the top level site of the site collection for your configuration? Either that or an XML file somewhere on the root site (if its in a document library than you get recycle bin and versioning if you want it). Your feature can then be scoped to site collection and it can create this list/config file as well as copy your web part to the web part gallery? regards Paul The settings of this web part – should the site collection administrator be the one to modify them? If that is the case, one option is possibly to use a list on the top level site of the site collection for your configuration? Either that or an XML file somewhere on the root site (if its in a document library than you get recycle bin and versioning if you want it).

Your feature can then be scoped to site collection and it can create this list/config file as well as copy your web part to the web part gallery?

regards

Paul

]]>