We are using Plumsail forms for SharePoint Online. We have 300+ forms that we have developed and, on average, each form has 200+ lines of Java Script. We also have a pretty sizable CSS file that we reference and maintain in the Site Assets library.
Has anyone ever tried to consolidate all this Java Script into a single js file outside of the form designer, reference this external js file from inside the designed form, just using 5-8 lines of code like you would to reference an external CSS file, and then call a master function in that external js file and pass through the arguments (fd.webUrl, LIST, CONTENT_TYPE and FORM) - New, Edit, Display.
Much of the Java Script code we use is replicated in every Form, with minor variations, and therefore, when we have to make a change to that replicated code, we have to update 300+ forms.
1 Like
Thank you. Yes this worked just fine. Strange that I could not find this in the search, but hey, I am a happy Plumsail user.
2 Likes
This is promising. Most of my forms are nearly 2K lines of JS - certainly due to user expertise [lack of] in JS refinement. We also have 200+ SharePoint Online columns that we manipulate with JS. It's a highly customized environment and we do not leverage SharePoint Designer 2013, primarily because I am waiting for MS to pull functionality completely. I am curious how you develop your sites and if Plumsail is your primary IDE.
@vhancock - I have enjoyed your posts to the community.
1 Like
@shedev Yes, Plumsail forms is currently our primary IDE. In fact, we are targeting our UX so that users will only see Plumsail forms and will not even know that you are on SharePoint. One remaining challenge we are working through is that all our logic, and there is a LOT of it, is on forms. So if a user gets into a standard SharePoint Grid and makes changes, we can get messed up.
We have decided that writing and maintaining that amount of code outside a repository is getting risky (Version Control, diff, branching, etc.). So, we have decided to onboard a full time developer to manage that for us. Our current plan is to have the team continue to work in Forms, since the build/test is so fast in forms, but introduce some new naming conventions and standards. With these new naming conventions and standards, we plan to create a process to easily move this code from the Form/Site where we are developing, and into a single file on a testing site. We will also start to use Bit Bucket for our repo. When we figure out that process, we will post to the board what & why we did what we did.
The speed of our appdev using Plumsail Forms is simply amazing. We have completely given up on the entire MSFT Power Platform suite. It's just too complex and slow in development. Furthermore, PowerAutomate is slooooooow to execute. JS in a form is immediate and fast.
Will keep you posted.
@vhancock - I read your post 14344 relating to targeting our UX so that users will only see Plumsail forms and will not even know that you are on SharePoint. I appreciated that a lot as I have always struggled with keeping the users from using SP tools and menus that staff/admins need but not end users. In our case, all users are collaborators and as such have more permissions than I would like (e.g. accessing Site Contents, etc) - why on Earth Microsoft doesn't already integrate more elegant methods for administrators to have better control OTB is beyond me. I battle with too little/too much access all the time.
I will test-run some of the suggestions from your post as they look promising. In our organization, SharePoint is a dirty word. Our users and staff hear SharePoint and roll their eyes. It's a PR problem I think and I suspect we're not the only company that has this love/hate relationship with SP 365. We have in-house developers that code for other enterprise products we use; SP is for custom applications that can be stood up relatively quickly, such as our intranet and for Azure guest user access (the collaborators).
Again - thank you for your contributions to this community. People like me who have many roles and whose primary duties are not development, gain great insight in this space. Keep it coming!