Wednesday, January 30, 2013 5:21 AM
Apparently I have a so simple question that nobody asks it on internet and I could not find a solution myself. Here it is.
I have custom lists stored on a site collection level and would like to create a small sharepoint-hosted app to maintain data in it (CRUD). The use of REST and then generating HTML tables to display the data seems to me quite labours process (there will be more apps using the lists as well) that makes me feel I am doing it wrong way and there is a simple solution. I was thinking of displaying the list items in its webpart (apparently SP creates it automatically for lists or I might read it wrong way?) on app’s aspx pages.
Cross domain is not involved in this project.
I am working Visual Studio 2012. Sharepoint-hosted apps for SP2013.
Guys, please, be gentle. I am making my first steps in SP programming.
Thursday, January 31, 2013 12:14 AM
Part of the idea of SP apps is that the app is self-contained; that is, it does not depend on anything outside itself except in the box components, such as lists, that are built into SharePoint. Your scenario of an app that would access custom lists is not an intended scenario for SharePoint apps.
Ordinarily, if you want your users to maintain data in a custom list, they would simply add the list to a SharePoint page through the SharePoint UI. This automatically puts a list web part on the page and populates it with the list's data.
Rick - MSFT
Thursday, January 31, 2013 1:08 AM
Thanks Rickee. It is getting clearer now. Looks like REST will become my best friend soon.
Just want to double check. If I create a web part that displays data from a custom list and put it into site collection along with the list will I be able to display it on aspx page of sharepoint-hosted application? Or that web part will be considered as a server side code and will not work in the app?
Another option. If I move lists and webparts into app will I be able to show the webpart on another app?
I want to segregate user access to the resources by using applications rather than manage access to each resource individually. That is the best practice for that?
Thursday, January 31, 2013 1:24 AM
I'm afraid it is not entirely clear to me what you want to do and why you think a SharePoint app is the way to do it.
>"Just want to double check. If I create a web part that displays data from a custom list "
Why would you create a custom web part to do this? There's already an in-the-box web part that displays lists, including custom lists. When a user creates a list on a site collection, the web part that displays it comes along for the ride. The same point applies when you add a custom list to a site collection in a farm solution or sandboxed solution; the web part comes along for the ride. You don't have to include any markup or code in your solution for the web part.
>"will I be able to display it on aspx page of sharepoint-hosted application?"
If it is a custom web part, then you can't include it in an app.
>"Another option. If I move lists and webparts into app will I be able to show the webpart on another app?"
You can't have custom web parts in apps. Also, one app should not attempt to use components, sucn as a list, that are installed as part of another app. This is not an intended scenario for SharePoint apps.
Rick - MSFT
Thursday, January 31, 2013 2:05 AM
Rickee, thank you for not leaving me along with the problems.
I am kind of stuck at design stage then :(
I planned to place all the lists into the site collection (basically use it as a DB) and develop sharepoint-hosted apps for users to do CRUD. Also I wanted to simplify managing access to the data by specifying user access to apps rather than to the lists. The apps would do workflow related activities and change data in the site collection. If they get deleted then the data will remain on the site collection. The hard part for me in this scenario was to getting rid of overhead GUI programming and I wanted to develop GUI forms along with the logic, place them in a certain location and then display them on the apps. Example: Show dealer’s details with addresses (one-to-many relationship. This is what SP can’t do out of box).
- - Centralised location of the data
- - Segregate uses access to the data
- - - Same user GUI look and feel in the apps.
IIs Is there a way out?
Monday, February 18, 2013 10:25 PMModerator
I think you can very much use SP apps for your purpose Zero. Essentially you will provide your own UI and use SP APIs for the crud work. The only thing to be aware of is that in order to traverse site/site collections from within an app you need to set the appropriate context for the call. Take a look at the "Cross site collection calls" section of this post (which as you point out, is not a cross-domain problem but an internal traversal problem).
Program Manager, Office Developer Platform.
Tuesday, February 19, 2013 5:37 PM
Please to give more details. How can "specifying user access to apps rather than to the lists"? Is possible to specify user access to apps? How?
It say many place MSDN SharePoint app only access custom lists that it install. Many apps can share lists from in the box, but not share custom lists.
Saturday, February 23, 2013 2:43 PM
I started writing a response to this thread, and it ended up being long so I decided to make it a blog post.
It can be viewed here:
Friday, March 15, 2013 5:41 AM
Sorry guys for not appearing here for a long time. I was kind of away.
“SP app is self-contained”. That is kind of different from the purpose of SharePoint.
I mean if app brings and maintains only own data and nothing on earth should try to pull the data out then it defeats whole purpose of having SharePoint, is not it? Unless the app grows into corporate monster. Sorry, but to me that approach looks very similar to using MS Access to me - all in one app.
The question is: What is the best practise for storing, changing, sharing, analysing data and using SP apps in company?