Guest User

Untitled

a guest
Mar 21st, 2018
92
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.39 KB | None | 0 0
  1. - research memory usage of UrlService
  2.  
  3. - finish up url service
  4. - urlService utility needs a rewrite
  5. - 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
  6. - i think post.url must die on the model layer (!) -> this is nothing the model has knowledge of -> different layer (routing)
  7. - but we still need to ensure that we return the current post url to the admin interface
  8. - need to dig into that part a little deeper
  9. - same for tag: the url utility uses static route keywords, but instead we need to use the taxonmoies/resources of the yml file (!)
  10. - i think some of the routing keywords must die???
  11. - which data is required to fetch for the urlservice?
  12. - id, slug, type is currently remembered
  13. - 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)
  14. - we can reduce the memory by using "columns: id, slug"
  15. - i think the url service should not cache the whole data set right now
  16. - i think the urlservice could use a DataCache, which can be disabled/enabled -> but this is a different feature
  17. - for now the url service just knows which urls are available in the service
  18. - if the first request comes in, we have to ensure that the url service did finish it's url caching
  19. - > need to be able to apply filters to existing JSON objects, to see if they match. Therefore reworking and extending GQL is a must.
  20. - this happens because the urlsrvc fetches all the data on bootstrap
  21. - now it has to figure out which post belongs to which collection
  22. - based on FILTERS (which actually run against the db)
  23. - the question now is: should we rewrite GQL to see if objects match a filter
  24. - OR should we fetch the data already based on the route patterns
  25. - that means the component, who instantiates collections etc, will trigger the urlsrvc to cache a set of routes
  26. - we also need to keep in mind, that we might need a similar logic for apps ? e.g. /subscribe
  27. - e.g. fetch filter=x for /podcast/:slug/
  28. - if we run them sequentially, the urlsrvc is able to keep unique urls for each post
  29. - ????????
  30. - 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
  31. - alternatively, we don't register ANY routes in express and use a * and ensure the url is known in the UrlSrvc
  32. - the event listeners in the url service won't work anymore
  33. - needs a little rewrite
  34. - because currently it just calls toUrl, which does not return the correct url
  35.  
  36. - sitemaps rewrite ??????
  37. - if the urlsrvc does not cache any data, except of the urls, why should the sitemap generator request the urlsrvc?
  38. - sitemaps generator needs more information e.g. modified date, images
  39. -
  40.  
  41. - write the channel controller
  42. - handles rss (if not disabled)
  43. - handles pagination
  44. - fetches the data
  45.  
  46. - write the basic controller
  47.  
  48. - write collection class
  49. - this.controller = ChannelController
  50. - write resource/taxonomy class
  51. - this.controller = ChannelController
  52. - write routes class
  53. - this.controller = BasicController
  54. - base class of these three types will be able to resolve resource paths e.g. page.home
  55.  
  56. - yml file reader + parser
  57. - default yml file lives in the Ghost core tree
  58. - if you provide a custom yml file, we prefer this file
  59. - we fallback to the default yml file if we can't read the custom yml file
Add Comment
Please, Sign In to add comment