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

Theme API: make {{nextpost}} {{prevpost}} available to themes #529

Closed
ErisDS opened this issue Aug 25, 2013 · 4 comments
Closed

Theme API: make {{nextpost}} {{prevpost}} available to themes #529

ErisDS opened this issue Aug 25, 2013 · 4 comments
Labels
feature [triage] New features we're planning or working on

Comments

@ErisDS
Copy link
Member

ErisDS commented Aug 25, 2013

We need to have some way to get hold of all the details of the next and previous post on the post page.

This means providing access to all properties of those two models through something like

{{#nextpost}}
{{title}}
{{/nextpost}}

@ErisDS
Copy link
Member Author

ErisDS commented Aug 25, 2013

Anyone got any clever ideas for how to do this?

ATM I'm thinking one of:

  • the single controller is just going to have to do 2 extra queries.
  • the helper is an async helper and does the query itself.

In the former, every post page does 2 extra fetches for data, forever. Even though we will have caching, that's a bit bleh.

In the latter, content gets loaded in dynamically and only when it's actually requested - but over ajax which will be a slower request I guess. Also makes it harder to know where what came from when, and I don't think it will be as usable.

Any other ideas?

@ghost ghost assigned ErisDS Aug 25, 2013
@ErisDS
Copy link
Member Author

ErisDS commented Aug 25, 2013

So I decided to go with just loading the 2 extra posts on every post page. This way, it's just data that is available by default and not a handlebars helper.

The problem with doing this is building the query as at the moment I can't find a way to pass anything other than straight '=' style where clauses, other operators require 3 args. If we upgrade to bookshelf 0.2.5 we get a function syntax which is useful, but basically, we need to rejig findPage quite a lot, into our own dynamic interface to query builder. That is, create a way we can define complex arguments in JSON and then have findPage call relevant query builder functions with each argument. The JSON -> query builder stuff should probably be a base function so we can use it later for building fancy queries for other objects.

This will be a separate issue, which this issue will depend on.

Punting to 0.4 for now.

@ghost ghost assigned cobbspur Oct 27, 2013
cobbspur added a commit to cobbspur/Ghost that referenced this issue Nov 25, 2013
closes TryGhost#529

makes previous and nextpost available when a post has been selected
@ErisDS ErisDS modified the milestones: Future Release Backlog, 0.5.x Feature Release Backlog Aug 23, 2014
@ErisDS
Copy link
Member Author

ErisDS commented Aug 23, 2014

I think it should be possible to revisit this now that knex properly supports subqueries.

@ErisDS
Copy link
Member Author

ErisDS commented Nov 3, 2014

Closing in favour of #4262

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature [triage] New features we're planning or working on
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants