Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- - research memory usage of UrlService
- - finish up url service
- - urlService utility needs a rewrite
- - e.g. if i change / to /home in my yml file and i call urlService.urlFor('post', data), i would receive /welcome and not /home/welcome
- - i think post.url must die on the model layer (!) -> this is nothing the model has knowledge of -> different layer (routing)
- - but we still need to ensure that we return the current post url to the admin interface
- - need to dig into that part a little deeper
- - same for tag: the url utility uses static route keywords, but instead we need to use the taxonmoies/resources of the yml file (!)
- - i think some of the routing keywords must die???
- - which data is required to fetch for the urlservice?
- - id, slug, type is currently remembered
- - memory currently goes up because we fetch all attributes, but we only keep a minimal set in process (memory goes up and goes down after ~2mins)
- - we can reduce the memory by using "columns: id, slug"
- - i think the url service should not cache the whole data set right now
- - i think the urlservice could use a DataCache, which can be disabled/enabled -> but this is a different feature
- - for now the url service just knows which urls are available in the service
- - if the first request comes in, we have to ensure that the url service did finish it's url caching
- - > need to be able to apply filters to existing JSON objects, to see if they match. Therefore reworking and extending GQL is a must.
- - this happens because the urlsrvc fetches all the data on bootstrap
- - now it has to figure out which post belongs to which collection
- - based on FILTERS (which actually run against the db)
- - the question now is: should we rewrite GQL to see if objects match a filter
- - OR should we fetch the data already based on the route patterns
- - that means the component, who instantiates collections etc, will trigger the urlsrvc to cache a set of routes
- - we also need to keep in mind, that we might need a similar logic for apps ? e.g. /subscribe
- - e.g. fetch filter=x for /podcast/:slug/
- - if we run them sequentially, the urlsrvc is able to keep unique urls for each post
- - ????????
- - what we then need to do is, if we register /nature/:slug as express route, we have to ensure the UrlSrvc has the requested url
- - alternatively, we don't register ANY routes in express and use a * and ensure the url is known in the UrlSrvc
- - the event listeners in the url service won't work anymore
- - needs a little rewrite
- - because currently it just calls toUrl, which does not return the correct url
- - sitemaps rewrite ??????
- - if the urlsrvc does not cache any data, except of the urls, why should the sitemap generator request the urlsrvc?
- - sitemaps generator needs more information e.g. modified date, images
- -
- - write the channel controller
- - handles rss (if not disabled)
- - handles pagination
- - fetches the data
- - write the basic controller
- - write collection class
- - this.controller = ChannelController
- - write resource/taxonomy class
- - this.controller = ChannelController
- - write routes class
- - this.controller = BasicController
- - base class of these three types will be able to resolve resource paths e.g. page.home
- - yml file reader + parser
- - default yml file lives in the Ghost core tree
- - if you provide a custom yml file, we prefer this file
- - we fallback to the default yml file if we can't read the custom yml file
Add Comment
Please, Sign In to add comment