This project has moved. For the latest updates, please go here.

Limit deployment scope

May 19, 2016 at 9:03 AM
Edited May 19, 2016 at 1:04 PM

First of all: Awesome work dude, blows paid third party forms solutions out of the water.

We're using it in an enterprise environment & noticed that the JS is loaded in the whole SC due to the Feature Scope. Would it be possible to split the activation & deployment into seperate features to gain more control over the usage of SPEasyForms across a site collection?
  • SC Feature - deploys files to Style Library
  • SC Feature - Activate across SC
  • Web Feature - Activate only on this Web
Then I also noticed that, even though a form was not modified with SPEasyForms, the SPEasyForms logic is running on the submit form button [EDIT: this statement was wrong: the validation errors are styled with SPEasyForms CSS].

Would it be possible to not affect un-modified forms?
Jun 6, 2016 at 8:25 PM
Sorry I didn't get back to you sooner, you caught me on vacation.

It is possible, but it would be very difficult to do it the way you suggest. The first problem is due to the was sandbox deployed features work in SharePoint. When you activate a sandbox solution with a site scoped feature, SharePoint automatically activates the feature. When it's a web scoped feature, SharePoint doesn't activate the feature anywhere.

The problem comes into play when you need to upgrade. To upgrade a Sandboxed solution you first need to deactivate it, at which time SharePoint automatically deactivates all of the features whether site or web scoped. Then you upload the new solution and activate it, at which time SharePoint automatically activates site scoped features but again doesn't activate any web scoped features anywhere. It doesn't remember where the features were activated before and reactivate them. This seems to me to be pretty useless.

Now I have been toying with the idea of a deployment mechanism that doesn't depend on sandboxed solutions at all. You'd just upload the files to the style library manually (possibly using explorer view since there are a lot of files), and then go to a page in the uploaded files that allows you to 'activate' it. I put activate in quotes because there would be no SharePoint feature, the activation would just create all of the script link and ribbon custom actions that make SPEasyForms work. If I do this, I could certainly allow you to activate it at either the site or web scope, although you would still need to be an SCA to do it at either scope.

If this is of any interest to you, I can create a feature/issue for this and prioritize it, but this would be quite a bit of work and I'm pretty busy right now so I don't know when I could get to it.

Also, I have seen the style issue you're talking about with SPEasyForms affecting the CSS of error messages even on forms where it's not configured. I'll look into fixing it, but I don't know how difficult that will be at the moment.

Jun 7, 2016 at 6:38 AM
Hi mcsheaj,

I understand your point of view on this. For us it's not as much of an issue in regards to feature activation, deactivation.

You do not have to prioritize this alternate deployment approach you had in mind. It'd be easier still if you could provide the web feature in addition to the ones you already have? That way we can decide ourselves if we want the granular flexibility of enabling it or the ease of having it everywhere at once? I'd prefer it over forking the solution just to add this feature ourselves :).

Thanks for the follow up!
Jun 7, 2016 at 3:38 PM
I can provide this feature pretty easily, but I'd prefer to do it as a separate download/solution as opposed to modifying the existing solution, because I think it could be confusing and should only be used by those who understand the issues involved, which I can explain on the separate download page. The separate solution would not include all the SPEasyForms files, so it would be wholly dependent on SPEasyForms being loaded alreadyl it would just have the files necessary for the web feature.

Among the issues are that if you enable both the site collection and site features, I'm pretty sure SharePoint will happily load the JavaScript twice, with isn't ideal, but I don't think there is anything I can do about it within the solution/feature framework. I could get around this if I only let SharePoint load a simple JavaScript files that downloads all of my dependencies as needed (via require.js or something similar), but that would be a pretty major rewrite. If I knew when I started this project what I know now about integration of JavaScript with SharePoint, I probably would have designed it that way from the start, but cay sera.

Anyway, if this would be useful to you, I can probably make this available for download sometime this weekend as I don't think it would be that hard. If it's important to you that it's all in the same solution, I'd say go ahead and fork ;), but I can certainly understand why you'd rather not do that.

Marked as answer by mcsheaj on 7/4/2016 at 12:23 PM