Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SiteTree types #239

Closed
ivoba opened this issue Aug 13, 2019 · 3 comments
Closed

SiteTree types #239

ivoba opened this issue Aug 13, 2019 · 3 comments

Comments

@ivoba
Copy link

ivoba commented Aug 13, 2019

This is more a question than an issue:
In the docs in the inheritance section: https://github.com/silverstripe/silverstripe-graphql#dealing-with-inheritance the generated schema contains a SiteTree type altough its not declared in the yaml/php section above.

Are the standard CMS types included in silverstripe-graphql or was the declaration of SiteTree just omitted?

Maybe it would be good to have a standard declaration for the CMS basic types like SiteTree, Page?

@unclecheese
Copy link

unclecheese commented Aug 13, 2019

Hi, @ivoba . Great questions, and I'll be honest -- this is an area we're still trying to get right. There's been a lot of discussion about how to deal with inheritance.

Related: #215

Right now, exposing any dataobject to graphql results in the entire inheritance chain being exposed. For instance, exposing Page will implicitly expose SiteTree and RedirectorPage.

The reason being:

  • By exposing page, you've also exposed all of its inherited fields, so those need to be put into separate types. (Whether they should be exposed in read/write operations is open to debate. I believe a recent commit added a flag to suppress the creation of inherited operations)
  • You could in theory query all pages, and some of those would be RedirectorPage, and you may, on a case-by-case basis, want to access the RedirectorPage fields in the list. This is done using ... on RedirectorPage in your query.
foreach (Page::get() as $page) {
  $page->RedirectType; // Bad practice, but we have to support this, as the ORM allows it.
}

Does that help at all?

@ivoba
Copy link
Author

ivoba commented Aug 14, 2019

@unclecheese I see, thats actually quite cool.

So you get the whole CMS types for free with simply exposing Page.

I played around with this a bit and have some remarks:

  • the read*Pages queries also expose Pages that are supposed to be not public, like when they have "CanViewType": "LoggedInUsers",
  • aditionally to Limit & Sort i miss a URLSegment filter on the read*Pages queries to query a single page. This would get you out of the box already quite far in rendering pages on frontend side.
    Writing this pageByUrl resolver is not a big deal though, i guess.

I will test this a bit more and might get back :)
Thanx for explaining.

@maxime-rainville
Copy link
Contributor

I'll close this for now as there's nothing to action. If you need more help maybe try one of those community support options:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants