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

A few observations before the long weekend

Jan 16, 2015 at 6:36 PM
Edited Jan 16, 2015 at 6:37 PM
First of all, thanks for all of your work on this Joe and Scott, it truly is a great product!

I heard about this last weekend at SharePoint Saturday Virginia Beach and couldn't wait to start playing with it so I've been playing in test labs all week playing with deployment of the solution. Currently I'm only testing for our 2010 environment. Once I have my deployment script completely tested on there, I'll be testing for our 2013 environment.

PROBLEM 1: As this is a sandbox solution, this must be put on each Site Collection you'd like to use it. If you have many Environments/Site Collections, this could be cumbersome.
SOLUTION 1: I've scripted this out to Add and Activate to either a single Site Collection, a Web App, or to all Site Collections on all Web Apps. I'll post the script after I clean out some things early next week. The script also Deactivates/Removes solutions and Upgrades/Activates. I still want to add the removal of all files if you remove the solution before I share it. Currently removing the solution leaves all files behind just removes the button on the list.

PROBLEM 2: Deploying the solution does not check in the files that are put in the Style Library. This means that only the person who deploys the solution can actually use the SPEasyForms. For everyone else, it will actually grey out the ribbon and make some other things "funky".
SOLUTION 2: My deployment script also checks in all files. If you're doing this manually I have no idea how you'd do this without touching every item in the SPEasyFormsAssets folder manually for the CheckIn.

PROBLEM 3: The script in the "Why is my form so jumpy?" blog post under documentation has the improper tags for use on SP2010.
SOLUTION 3: Remove the <SharePoint:ScriptBlock...> opening and closing tags. Use <javascript type="text/javascript"> and </javascript> (I hope it doesn't strip those out since I'm not using a code block in the message -- I'll edit after if it does!)

PROBLEM 4: SPEasyForms used in SP2010 will make forms larger than the popups they appear in.
WORK AROUND 4: I don't have an enterprise fix to this yet but in individual lists, if you tell forms not to open in dialogs it will be an 85% solution. Clicking "Add" on calendars and a few other places still force the popup form rather than the full-page form.

PROBLEM 5: Also related to popup forms on SP2010 -- once the style tags and script are added to the master page, dialog popups are collapsed. Based on the behaviour alone, size seems to be based on the height of the Once you set that to display:none it then collapses.
SOLUTION 5: I have no solution yet. I haven't reviewed the javascript to see what I can do with it yet. If you have a solution before I find one next week, please let me know.

REQUEST 1: Form configurations are kept in the root of the SiteAssets library -- for site management, a folder within the library would add easier management (especially if there are MANY different form mods on a site).

REQUEST 2: Joe stated he wanted to add the ability to add HTML snippets -- this will be a GREAT addition and I can't wait to see it!

Again, thanks again for all of your hard work on this! I can't wait to finish my 2010 testing so I can move on to 2013!

Casey D
Jan 16, 2015 at 8:51 PM
Edited Jan 20, 2015 at 12:01 AM
Hi Casey,

Thanks for all the great feedback.

RE PROBLEM 1: Scripting is really the only solution I can see here. When you finish your script I'll be happy to make it available as a separate download.

RE PROBLEM 2: Other than scripting, the only solution to this one is to turn off require checkout on the Style Library and then deploy the sandbox solution. Then the files come in checked in. I've only seen this on 2010, with 2013 and Office 365 module files appear to come in checked in regardless. I had documented this as a 2010 specific problem for some of my early beta releases, but then I stopped seeing the issue and dropped it from the documentation (probably because I turned off require checkout and never turned it back on ;).

RE PROBLEM 3: I'll add the script tags commented out with comments explaining to take out the ScriptBlock tags and uncomment the plain old script tags for 2010. For 2013 and Office 365, you definitely want to keep the ScriptBlock tags and not use plain script tags. Otherwise it breaks Minimal Download Strategy (MDS) and can cause some pretty horrible performance problems. Basically, if you put plain script tags in your master page and MDS is enabled, SharePoint tries to do an asynchronous load of the page, sees the script tag, gives up and does a full request of the page, so every page load is 2 requests. This obviously increases page load time but can also put a lot more load on the servers.

RE PROBLEM 4/PROBLEM 5: This is definitely something I'm aware of and short-term we recommend turning off open in dialog just as you said. In the past when I've done form customization post page load, I have played around with different solutions to resize the dialog when I'm done, but they usually involved calling Microsoft functions with names like SP.UI.Dialog.$24(). This is a bit troubling because this is intentionally obfuscated code and the numbers change between versions of SharePoint, so clearly its Microsoft's way of saying this is for us to call and not you! I wasn't going to hack something like that into SPEasyForms, but I have found a post titled SharePoint 2010: Easy Dynamic Resize of Dialogs that seems to provide a simple and elegant solution. I'll probably try adding it to the AddOns package sometime soon, and if it works I'll roll it back into the next release. Of course, if it doesn't work I've got nothing.

RE REQUEST 1: There are numerous problems here, starting with the fact that SPEasyForms is a site collection feature. So there is no way for me to create a folder in the Site Assets library of every sub-site during deployment (this would be particularly hard for sub-sites that haven't been created yet). So every time I saved a configuration I'd first have to see if the directory exists, create it if not, and then save, all through separate web service calls. I fear it would have a significant impact on performance. However, I had already figured that in the next major release I would provide the ability for you to add a small JavaScript file somewhere to override some of my default settings (like where I save the config files). The onus would then be on you to make sure that place exists. You could take care of that with your scripted deployment, although you'll still have a problem with sites that are created after your deployment. I'm not sure I know what the best solution is, but I'll keep thinking about it and I'm certainly open to suggestions. I agree that a bunch of {GUID}.txt files junking up the root of your site assets library isn't ideal ;). I ultimately choose to do it this way because I wanted to save to a place that should normally exist in any site on all 3 supported platforms.

RE REQUEST 2: I expect it will take me 2-4 weeks to get this added to the AddOns package, more because of real life getting in the way than because of how difficult it is.

Thanks again,
Jan 17, 2015 at 9:31 PM
FYI, I tried the solution described in SharePoint 2010: Easy Dynamic Resize of Dialogs, but it had no effect. So back to the drawing board, I'm still looking for a solution for forms in dialogs.
Jan 19, 2015 at 11:58 PM
Edited Jan 19, 2015 at 11:59 PM
I've put up my first attempt to fix the problems with dialog size when the form starts off hidden or is altered by SPEasyForms. It works, but I may still tweak the CSS a bit, sometimes the dialog ends up a bit too tall or wide, but it's much more useable than 2014.01. It's available in jQuery.SPEasyForms.AddOns.2015.00.05.
Jan 21, 2015 at 3:27 PM

Thanks for the replies and the work on the dialog resize. It is working great. Occasional circumstances where forms aren't fit exactly right should be okay (until they're not).

My script is nearing completion. I'm trying to make it as easy as possible to perform any necessary deployment, upgrade, or removal function as there are admins who don't use or know PowerShell. I'll send it to you when I'm happy with it so you can share it here. It's now fully tested in SP2010... next up is 2013 which it should still be good in.

  • When putting date/time fields inside of tabs, the hour and minute dropdowns collapse. This happens with and without the add-on. It happens when forms are opened full-page and in dialog. I've confirmed in SP2010 but haven't tested in SP2013 yet. To easily duplicate: add tab to OOTB calendar form, put start and end time columns in tabs. View New Item form.
Jan 21, 2015 at 4:26 PM
Edited Jan 22, 2015 at 1:38 AM
RE New Issue: I've seen something like this before, but it was on the Date control itself not showing the date even though I could see the correct value in the DOM inspector. This happened with dates on tabs or accordion. It turned out that jquery-ui was changing the font-size from 8px to 1em or something like that (i.e. changing from a fixed size to a relative size) and this caused problems on 2010 (I assume because the master page specifies IE compatibility mode). I'm not sure I tested datetime on a tab on 2010; I wonder if it's the same problem. I just overrode the size back to 8px (using JavaScript so I could do it only on 2010) and it worked, so if it's the same issue it should be very easy to fix. I'll let you know what I find when I get a chance to look at it.

Jan 22, 2015 at 1:36 AM
Edited Jan 22, 2015 at 1:37 AM
This turned out to be the exact same problem as what I saw on date input fields, jquery-ui was setting the font-size to 1em which porked something on SP 2010 only, setting it back to 8pt fixed it. In this case it is the date select fields, but the problem and the solution are exactly the same. This is fixed in the latest AddOns package.
Jan 22, 2015 at 5:13 PM
Edited Jan 22, 2015 at 6:16 PM
I'll be testing out the date/time fix tomorrow in my 2010 environment.

NEW ISSUE (UI display):
In SP2013 (haven't tried in 2010), editing the height of the CSS property #suiteBar (or #suiteBarLeft or #suiteBarRight) cuts off the SPEasyForms UI at the bottom for any size over the default height of this suiteBar area. To verify this, add the following to your css then increase the height to 200, then 300, then 400, etc. and watch the SPEasyForms UI behavior:
#suiteBar { height: 100px; }
I used the default contact form because it takes up the most vertical real estate (plus I'm using a vSphere console so it's easy to notice when my real estate is compromised).
Jan 22, 2015 at 6:23 PM

I've found something a bit more pressing...

NEW ISSUE (Rich Text field in containers):
I've identified this in SP2013 and have not tested in SP2010. When adding a rich text field to a container, it (1) does not maintain the value of the field and (2) does not allow the use of some rich text editing tools. I identified this using the "Notes" field in the default contact list trying to use in tabs, accordions, and columns. Once added, the field values do not appear if it is inside a container. They do appear if the field is moved to the DefaultForm. Single rich-text options such as bold, italics, and position work properly. Options with more than one selection (text size, color, etc.) do not open their menus.

Jan 22, 2015 at 6:48 PM
NEW ISSUE (Calculated Columns not showing in UI):

I've identified this in SP2013 and have not tested in SP2010. Calculated columns are not showing in the SPEasyForms UI. The fields show on the customized form wherever you have DefaultForm located but you cannot move them. When I was reviewing the code that I had seen the column type declarations and saw calculated columns commented out. I'm not sure which file it was in or if it's intentional.

To replicate, create a calculated column. For simplicity, I created "Calculated full name" and concatenated First Name and Last Name. Attempt to change the order (or conditional visibility, etc.).

Jan 22, 2015 at 11:01 PM
Edited Jan 23, 2015 at 1:09 AM
RE UI Display Issue When Suitebar Size is Increased: Don't increase the size ;). Short term that really is the only answer. Long term I know I have some issues with floats and overflow and that's what you're seeing. It's a PITA to come up with any design/css that works on all 3 platforms and doesn't have some quirks, and I'm a better programmer than I am a designer, but I know what the problem is and this is fixable. I just don't know when I'm going to get to it.

RE Rich Text Fields in Containers: I doubt if this is fixable at all, the old rich text fields have some pretty crappy JavaScript behind them, so moving them around on a form is a tricky business. For the most part, if they don't work, the best I can do is document that they don't work and suggest you use only plain text or enhanced rich text, or don't put them on a container. I thought I had more or less gotten past these issues on 2010 and Office 365, but it's definitely possible that I just didn't test them as well as you have. I've never really considered it before, but it might be easiest to create a custom adapter for rich text that just strips out everything Microsoft did and replaces it with my own rich text editor. I've been playing around with CLEditor for the HTML Snippet container, which is a jQuery rich text editor plug-in that's really tiny and very impressive in what can be done with it.

RE Calculated Columns Not Available: Scott's already identified this, and fixing it is going to be a pretty major change and probably cause a bit of a performance hit, but it is what it is. There are basically 2 ways I can try to figure out which fields should be available:
  • I can look at the list schema, but its going to show me a whole bunch of garbage fields with not enough information for me to determine which of those fields are actually displayed on forms and which are just internal fields that Microsoft uses for it's own nefarious purposes.
  • I can load the form and parse it. I chose this way, but then which form do I load. Each of the forms is a little different, the new form doesn't show things like content type, and only the view form shows calculated fields. I chose the edit form, which is why calculated fields aren't available. It's possible I could just switch to the View form, but I'd have to do some pretty careful testing to make sure that there isn't something on the edit form sometimes that isn't on the View form, maybe even depending on what type of list it is. I think ultimately, I'm going to have to load both forms and merge the results, thus the major change and performance hit.
Unfortunately, this may have too high an impact on too much of the code to be done in the AddOns package, so it may have to wait until the next major release. When I get a chance I'll investigate a bit more before I throw in the towel and say this is just a limitation of 2014.01 that will be addressed in 2015.01, but either way it is on my radar.
Jan 26, 2015 at 3:38 PM
I've made some progress on the rich text editor on Office 365. It now retains it's value, which is the only problem I'm seeing on Office 365, the problem you mentioned where dropdown options don't work doesn't occur on Office 365. I'll have to go back to SharePoint 2013 and 2010 and see if my fix works and if I can reproduce the other problem, but I'm now cautiously optimistic I can fix the regular rich text editor.
Jan 26, 2015 at 11:51 PM
Ok, I've now seen the menu problems you're seeing with rich text, and I don't see much chance of fixing it any time soon. For now, I'm going to patch it so if a field contains a rich text editor, I won't put it on a container regardless of what the configuration says. It'll just remain on the default form. Plain text and Enhanced Rich Text will continue to work normally. I'll add it to the documentation as a known limitation and suggest that if possible you should switch to Enhanced Rich Text.

I may go back and try to tackle it later, but there's about 8000 lines of mostly obfuscated JavaScript behind those old rich text editors, and because they're obfuscated they're different for every version of SharePoint. And the things that aren't working aren't throwing any exceptions, so isolating where the problem is will be somewhere between difficult and impossible.
Mar 4, 2015 at 10:56 PM
I think I've addressed all of the issues you brought up in the latest AddOns package, at least as well as I think I'm going to in a hotfix as opposed to the next major release. There are a couple of issues with solutions that aren't very satisfying, and they are:

Rich Text Editors - as you know, I punted on this and just don't put them on the containers regardless of what the configuration says. I may have some ideas for how to address this better long term, but for now I'm moving on. Enhanced Rich Text fields are better anyway ;)

Overflow Issues on Settings page - i.e. the problems you saw when you changed the size of the suitebar nav. It's more dynamic now than it was, but still a bit crappy. A better solution will definitely have to wait until the next major release.

I'm doing some housekeeping so I'm going to mark this thread answered, let me know if I missed something. And if you get your deployment script working to your satisfaction, start a new thread for it so people can find it easier, and I'll put it in a release too.
Marked as answer by mcsheaj on 3/4/2015 at 3:56 PM