0

I'm fairly new to Sharepoint. I've been using Infopath to build forms, but I'm trying to move away from that and into Sharepoint Designer as I have more of a developer background (recent CS grad) and I'm frustrated with the "no-code" interface.

I'm trying to build a fairly simple custom form (for creating a list item) and learn how to replicate some of the functionalities Infopath offers.

It's my understanding that through Designer 2013, there is no access to the "code behind" file that is paired with the aspx. This seems completely acceptable for most of the controls I enter, as they function correctly when added to the aspx file without me having to code anything - I have FormFields and a FileUpload. However, certain controls like UpdatePanel seem to require some sort of access to backend code.

Am I only limited to what I can do with these simple controls and Javascript? Can I build any of this in Visual Studio without having to deploy an entire app? Is there a way to insert inline C# in the aspx file? Do I just have the wrong idea about everything?

Any guidance at all would be appreciated. Most of the resources I've found either are 2010-specific or assume development in Visual Studio. (We don't even have an app server configured, for various reasons.)

0

If you're looking for code, get Visual Studio and start learning about SharePoint add-ins (which used to be called "apps", but were recently renamed).

Also, check into the JSLink property, which allows you to customize the look and feel of lists via javascript.

Also, look into SharePoint display templates, which allow you to change the look/behavior of things like search results via HTML/JavaScript. (this is big in SP 2013, as you can use search web parts to retrieve all sorts of data from SP, and then customize the look via these display templates)

Also, check out the JSOM and CSOM (JavaScript and C#), which let you interact with SharePoint data from client apps.

Also, check out Office 365 Apps, which allow you to access Office 365 data, such as mailboxes and onedrive, from client apps, such as ASP.Net apps or Window applications.

Or, check into "SharePoint solutions", which was the recommended way of doing things in SharePoint 2010, but is no longer recommended in 2013. Solutions consist of server side code that is deployed and run on the SharePoint server. (web parts and such).

But, don't insert inline C# into the aspx page in SPD. If you want, use SPD as an editor for HTML/JavaScript for any of the above items, but again, don't try to add C#.

Oh, and a simple way to do a customization is:

  1. create a javascript file and upload it to a library (like the site assets library).

  2. Create an html file that references the above javascript, and that also contains any additional script or style references and HTML, and upload it to the same library

  3. add a content editor web part to any desired page. In the properties, specify the above html file as the content to render

  4. map a drive to the site assets library

  5. edit the html or js file with any editor of your choice.

  • Thank you for the thorough clarification! I've read some articles that indicate the CEWP is not best practice? But I'm not sure what is, then. – Chip Potato Oct 5 '15 at 14:47
  • The "best practice" would be to create "apps" (or, add-ins, as they've been renamed). Personally, like many, I find apps to have a large amount of configuration and maintenance that doesn't seem justified when I just need a small bit of functionality added to a page. – Mike2500 Oct 5 '15 at 15:06
  • Oh, okay! That's absolutely what I'm finding as well. I just want to not use Infopath, not reinvent the wheel. Thanks! – Chip Potato Oct 5 '15 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.