Today we get PageHead
& PageFooter
... would like to have BEFORE/AFTER DIV's for QuickLaunch
& PlaceHolderMain
If you are planning to share a new feature request (enhancement / suggestion), please use SP Dev UserVoice at http://aka.ms/sp-dev-uservoice.
OK... cross-referenced:
https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/19536022-extensions-application-customizer-additional-pl
Thx AC for the input.
We'll absolutely introduce additional placeholders for the framework and this is a good input for getting the needed placeholders tracked. We would also love to have some details around the actual scenarios where you'd use the requested capabilities. That might be obvious in some cases, but actual business scenarios and use cases help to prioritize the requests. Thx.
Cross posting my response from UV.
Hey AC - While I know what you mean here, can you refine this to target the modern experiences? For example, PlaceholderMain is an asp.net masterpage div that doesn't exist in the newer code. Would you think of Pre/Post Placeholdermain to be ContentHeader and ContentFooter (as opposed to PageHeader and PageFooter?
Additionally, how would you expect scrolling to work in this scenario? For example - what should happen with a listview with infinite scroll vs. a page with 500k of text?
@patmill Will xpost from UV too :)
Specifically looking for any place these extensions are supported... if that's just modern experiences, then just those (although I hope these will also apply to classic pages, just as client-side web parts do). Understand the names are different... I was referring to the intent of where things would go... a picture might help. I see the RED is what you provide today... the GREEN is what I'm asking for:
As for infinite scroll... I'd expect it to behave like the components that wrap them. For instance, on the QuickLaunch, it doesn't scroll so I'd expect what I put right after it to be pinned to the bottom border of the QL. Same is true with the main body of the page.
@VesaJuvonen - Biz case: context help, messages to the user based on the context of what they are doing or reminders they haven't done something. I could do this by doing DOM manipulation from the header / footer, and that's what folks will do as these are common places we want to add / remove stuff... but that's now how we should be doing it... so don't give them a reason to do it and add it for them. Make sense?
I agree with AC. While @VesaJuvonen has mentioned that keeping our customization's within the confines of these placeholders, which I assume is the contractual safe place for custom content, ensures that it will not get destroyed or broken with future updates to the DOM, if there are not additional Placeholders to be populated, users will simply begin manipulating the DOM.
While this isn't how they should add customization's, as @andrewconnell as mentioned, if there are no other places, peeps will still do it.
The Pre/Post locations could also provide the ability to wrap that content with a custom CSS classname for ensuring specificity within a certain brand/design.....just one possible other thought.
Adding some additional placeholder requests here, as discussed in #656
To updated everyone on this topic: the scenario is well understood and we are working to be sure we tackle that properly. There's still an open conversation to understand if Placeholders is the right technology to use to enable such scenarios or it is something else.
I'm confused @lucaband ... why close the issue if the conversation is still open even if internally?
Andrew, thanks,
Reason why I closed was because I though I answered the initial question.
But I'm perfectly fine to keep it open, assign it to me, and reply back here once we have some concrete news.
This might be interessting for you as well: https://sharepoint.uservoice.com/forums/329220-sharepoint-dev-platform/suggestions/31752808-extensions-property-pane-sidebar-placeholder-r
I would like to see a sidebar placeholder on the right side.
I would like to achieve the below-highlighted stuff in the modern experience but it is not possible due to the limited number of placeholders. Please introduce more placeholders as requested.
@lucaband Are there any updates on a solution to this issue?
as this is a new feature request and not specifically an issue, we'll close this, for now, to help on tracking actual issues in the issue list (trying to drive new feature requests to UserVoice). We will have some announcements coming up around this area during this spring - SPC18 and later.
I dont see any additional placeholders. The following only shows me Top and Bottom. Is there anything I have to do to get the other placeholders?
console.log(
"Available placeholders: ",
this.context.placeholderProvider.placeholderNames
.map(name => PlaceholderName[name])
.join(", ")
);
Output: Available placeholders: Top, Bottom
Sorry for the lack of clarity. Feature requests are handled via user-voice. There are currently no additional placeholders.
I dont think there are any new placeholders till today. I can only fine Top and Bottom. So people who want to customize have to manipulate DOM directly. @VesaJuvonen Please throw us a light on this.
Top & bottom are the only two.
Microsoft has said in recent public community calls they are working on some stuff related to extensions. With a big conference (Ignite) coming up in November, I'd suspect we may learn more there, but not likely much before that.
Any update on above request, i am looking for solution.
Afraid not @malleshatla
With new 1.10 version, we have an option to modify Search experiences (https://docs.microsoft.com/en-us/sharepoint/dev/spfx/building-search-extensions), but no new PlaceHolders yet
Locking the issue as it's already closed and no reason to keep on having chat on closed issues as those comments can easily get fully ignored.
Most helpful comment
@patmill Will xpost from UV too :)
Specifically looking for any place these extensions are supported... if that's just modern experiences, then just those (although I hope these will also apply to classic pages, just as client-side web parts do). Understand the names are different... I was referring to the intent of where things would go... a picture might help. I see the RED is what you provide today... the GREEN is what I'm asking for:
As for infinite scroll... I'd expect it to behave like the components that wrap them. For instance, on the QuickLaunch, it doesn't scroll so I'd expect what I put right after it to be pinned to the bottom border of the QL. Same is true with the main body of the page.
@VesaJuvonen - Biz case: context help, messages to the user based on the context of what they are doing or reminders they haven't done something. I could do this by doing DOM manipulation from the header / footer, and that's what folks will do as these are common places we want to add / remove stuff... but that's now how we should be doing it... so don't give them a reason to do it and add it for them. Make sense?