don't make assumptions on how frontend-urls will look like

[distributev]

The only valid statement is that if there is no /admin inside the URL ==> it's a frontend URL ==> it should go through the frontend theme. Any additional assumption it's a hard-coding and it's not correct.

Commit https://github.com/distributev/the-app/commit/8e3a8ae1db5bca8c50458be2ef1b61f4e8942946 hard-coded /invoices/ into the frontend theme. This is not correct. Instead replace that with a more flexible and generic solution which will not make assumptions on how the front-end URLs will be or on which dynamic HTML document will get returned / fetched from the database. It could be any document type and any valid frontend URL (i.e. invoices, payslips, etc.)

[distributev]

See if it helps. He is speaking here about express-handlebars but maybe the conceptual solution is applicable to us too.

Express and Handlebars: Implementing multiple themes -

http://stackoverflow.com/questions/34866926/express-and-handlebars-implementing-multiple-themes

[luismanuel001]

Can we assume all document permalinks will start with something like /documents/*? I think this will help keep things organized, and avoid collisions with other root level frontend urls like for example /about /contact etc.

[distributev]

We could assume that. Though I would prefer that, if possible, the only assumption is "if no /admin inside the URL then it's a frontend URL"

[distributev]

How that /documents/* assumption will help? Please give more details.

[distributev]

Please check following possible approaches to better separate frontend from /admin (but still keep them integrated - if that makes any sense at all)

How to separate the routes and models from app.js using NodeJS and Express

http://stackoverflow.com/questions/19619936/how-to-separate-the-routes-and-models-from-app-js-using-nodejs-and-express

(10m video) -- Modular web applications with Node.js and Express - https://vimeo.com/56166857

[luismanuel001]

So if we follow the modular server side approach, we can easily update our server/router.js file with something like this,

  // All routes starting with /admin
  app.route('/admin/*')
    .get((req, res) => {
      res.sendFile(path.resolve(app.get('appPath') + '/index.html'));
    });
  // All other routes should redirect to the frontend-index.html
  app.route('/*')
    .get((req, res) => {
      res.sendFile(path.resolve(app.get('appPath') + '/frontend-index.html'));
    });

But this will require us to maintain 2 app entry points and will mess up the current gulpfile setup.

Also in order to have separate assets (html/css/js/dependencies) for /admin (or /theapp as per #47) and the frontend urls so we don't load unnecessary assets, we need to modify that gulpfile quite a lot. So at the end will have pretty much 2 completely different apps with a different set of gulp tasks for bundling all assets.

[luismanuel001]

Another approach will be to keep things like they are, and handle these with the angular ui-router.

Thats why I suggested a /documents/ folder for all permalinks instead of the root /. By assuming all document permalinks will start with /documents/* we can separate the other frontend static urls (/, /about, /contact, and any other future hexo generated pages) from the document permalinks and from the /admin app.

In this case we can create angular routes that will catch all /document/{{permalink}} urls and look for the specified permalink in the DB, and resolve it to render the specified html on a frontend template. All in angular.

[luismanuel001]

Is the backend for creating/getting documents from the DB already in place?

[distributev]

No - backend for this is not yet ready. There is a separate project to implement this backend and will come after this project - the front-end for this feature is already built in this project https://github.com/distributev/ng-mail-merge-directive.

You could assume the HTML document will come from a table - more specifically it will be saved in a CLOB column. That column will contain only the document itself and not the header, footer or menus of the site (which will come from the /frontend hexo corporate theme). The HTML document will be rendered in an