5

I am working on an enterprise wiki site collection inside an on-premise sharepoint server 2013 , and currently I have the following:-

  1. I have a site column of type choices named “Wiki page Type”. It have options such as; “General Info”, “Internal Procedure”, etc..

  2. I added this site column inside the metadata navigation for the wiki list + I added it inside the enterprisewiki.aspx page layout.

  3. So each wiki page will be linked to this site column.

Now our customer asked us to show a summary of the wiki pages inside the enterprise wiki home page as follow:-

Wiki Page Type | Number of Pages

General Info ---> 10 Pages

Internal Procedure ---> 15 Pages

When users click on the summary links they will be redirected to a pages which shows the wiki pages associated with the realted “Wiki Page Type”. Now I am planning to do the following to achieve this requirement:-

  1. Inside the home page to reference a “javaScript” file.

  2. The java-script file will do a couple of rest api calls to query the wiki pages list for each of the “wiki page type” options. then i can show the count of the object returned.

  3. In this way I can get the summary as desired.

But since I did not implement such a functionality before,,so I am not sure if my above approach sound valid ? or there is a better and a more reliable approach I can follow?

Thanks

Improve this question
3
  • 2
    Why not create a grouped and totaled view in your Wiki Page library, add an App part on your home page and use that view?
    – Eric Alexander
    Commented Feb 21, 2017 at 17:40
  • @EricAlexander can you please advice more on this? now if i use the built-in group and total list view it will not work 100% the way i want.. first of all the group and total built-in view will show the related items and not only the total. also i can not add hyperlink for each summary row ,so when the user clicks on the summary row it will show the related wiki pages.also i want to show the summary link inside HTML table..so i need a more dynamic appraoch which is not provided inside the list view.. second point,, are you against my appraoch of using JavaScript + rest api to achieve this ?
    – John John
    Commented Feb 22, 2017 at 1:56
  • 1
    I'm generally opposed to writing script when the ootb method would work just fine, you don't have to use totals, but if you group the pages based on wiki page type, then you'll get an aggregate of the number of pages and be able to expand the heading to see the items. This is standard view grouping and satisfies exactty what you need.
    – Eric Alexander
    Commented Feb 22, 2017 at 4:40

1 Answer 1

Reset to default
3

There isn't a need to develop anything, this functionality is readily available with out of the box features. In your wiki library, you create a view grouped by your page type, it would look like this, no need to use totals like I had mentioned, the grouping takes care of this for you:

enter image description here

Configure the view to include the desired columns. When expanded, it will look like this:

enter image description here

Then on your home page, add an App Part of your wiki library and tell it to use the view you created above. Save the page and your done.

It doesn't look exactly like you described, but it delivers everything you want for 5 minutes of work. Use the features of the platform.

Improve this answer
2
  • Now the issues with your appraoch taking into considerations the requirements from our customer are 1) they want the summary data to be shows in a table layout. 2) they also want be able to click on certain "wiki page type" and then get redirected to a list view where i have enabled Metadata Navigation for the wiki library, so they can do further filtering .... that why using the group by inside the list views will not achieve these 2 main points... what do u think ?
    – John John
    Commented Feb 22, 2017 at 17:34
  • If they want further filtering, then add those columns into the view and they can be filtered right there, in place or add it as a secondary group. I still don't see a compelling reason to write something to do that. It's additional overhead and maintenance for little gain over what is available ootb.
    – Eric Alexander
    Commented Feb 22, 2017 at 17:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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