Strong-Type Classes?
Closed this issue · 6 comments
After finally getting a Graph.Community.List, I noticed that everything was in the AdditionalData. Is that how the majority of the objects are going to be?
Mind you, I come from a CSOM mentality where everything was very strongly-typed, so this threw me off. I had hoped to see more info, like if the List had versioning enabled.
The intent of the Community Library is to provide data/functionality that is not included in the core Microsoft Graph SDK.
Lists are available in the SDK: https://docs.microsoft.com/en-us/graph/api/resources/sharepoint?view=graph-rest-1.0
The List object in this library, at the moment, contains only the ChangeToken from SharePoint. The list version information is a great suggestion -- but is not currently implemented.
I think it would be helpful if you create a new issue detailing the information from SharePoint that you need (there are four or five versioning properties), and how you would like to work with that info (read only, update, etc.). We can then map out the requests/models.
Thanks!
Paul, first off, thanks for everything you've done, not only in this library, but in all the years I've been dealing with SharePoint (coming up on 10 now).
Second, I'll have more details about what our team's needs are as I keep poking around. If I can do some PRs, I might do that.
Is adding a strong-typed property really as easy as just doing [JsonProperty]? If so, I may test it on Web to add string WebTemplate or List to add int BaseTemplate.
For now, our needs are to simply read info for these objects, since MS Graph seems to have no interest in ever adding them.
Thank you for the kind words!
PRs are great. An issue first would be helpful tho -- it is a place to have a discussion and a place I can point some folks who want to know what should be added to the Graph endpoints. ;)
Adding property to the model is that easy, but the request must be updated to ensure the property is requested from the server. Otherwise the resulting object will have a null value for that property.
On Graph, the list resource includes the template type. Granted, that is not an int, but you may be better off long term using the Graph information rather than relying on SharePoint REST (IMO). It is somewhat difficult to create a list that is not based on the Generic list template.
I'll definitely start with some issues soon (I hope to not overload this repo. 😄 ).
RE: List template type - Not a huge fan that they made it a string instead of an enum/int, but it's usable for sure.
One thing I'd love to see, and this is obviously my $0.02, is taking the List/Web/etc. and making them similar to CSOM. If not, then I'd go use the newer PnP stuff, but I'd rather not.
I understand trying to use MS Graph whenever possible. That's our team's goal (I'm only going down this rabbit hole because we found that MS Graph lacked some required properties to do some filtering on sites and the versioning info on lists). However, I'd hate to query MS Graph to get 98% of what I need, then use this library to query SharePoint REST to get the other 2%. If I NEED that 2% (for whatever reason, and perhaps it's a one-time call), then I'd rather make a single call using the SharePoint REST (this library), even if it means that Graph.Community.List almost "feels" like it inherits from Microsoft.Graph.List and then adds its own properties (such as EnableMinorVersions, EnableVersioning, etc.).
Just based on using:
var list = graphServiceClient.SharePointAPI($"{sharePointDomain}{siteCollectionPath}").Web.Lists["ListTitle"].Request().GetAsync();it seems like it's not doing any $select whatsoever and is shoving everything into Microsoft.Graph.Entity.AdditionalData, making it an "expensive" call.
So, the library contains only what someone has needed. In the case of List, it is just the ChangeToken. 🤷♂️
The default deserialization code (in the Microsoft.Graph.Core) library, puts everything not explicitly defined into AdditionalProperties.
You are correct, no $select specified at all. Certainly an area for improvement.
BTW, regarding "filtering on sites", the Enumerate Sites operation is in beta: https://docs.microsoft.com/en-us/graph/api/site-list?view=graph-rest-beta&tabs=http
I gotcha! Didn't realize it was a minimal approach. I follow ya now!
As for the Enumerate Sites, yeah, we were looking at that. As of today, we're using https://graph.microsoft.com/v1.0/sites?$orderBy=displayName&$select=id,webUrl,displayName,name.
We need to filter out OneDrive sites and SharePoint Add-In App Webs. Hence my desire for the Web WebTemplate and AppInstanceId properties. (We don't do this today.)
I'll close this issue to leave you be for now. Thank you for your generosity with your time and education.