UI Router Considerations

[MatthewVita]

David,

Just wrote up the following wiki entry on UI Router templates: https://github.com/RupertJS/rupert/wiki/Cookbook:-Angular-UI-Router-Templates. Please "QA" it when you get the chance.

While writing it, I ran into a concern. Consider there needs to be multiple template files (safari-template.jade and arctic-template.jade) in a "feature" directory called zoo. It appears (and I could be wrong here) that Rupert can only reference the $templateCache of key 'zoo', causing ambiguity since there are > 1 templates.

Would it be worthwhile for me to write up a PR that sets/gets $templateCache as named more granularly (zoo-arctic and zoo-safari as key names, for example) or can you make a case for the 1 template per feature directory implementation?

[DavidSouther]

No - those templates should be broken into zoo/safari/safari-template.jade and zoo/arctic/arctic-template.html. Having the level of granularity you mention becomes onerous.

NB: The entire naming needs to get separated - this is the last place of Angular-specific knowledge still in Stassets. Stassets should use a bare object, with rupert-config-angular overriding the method to inject Angular-specific details.

[MatthewVita]

Okay, so this answers my question about accessing > 1 templates within a feature directory, however, I would like to continue the conventions conversation.

Suppose a Rupert app needs a dashboard feature directory that expects the following templates as based on the role:

├── dashboard
│   └── roles
│       ├── admin-template.jade
│       ├── student-template.jade
│       └── teacher-template.jade

With the way Rupert is set up, it would look like this:

├── dashboard
│   ├── admin
│   │   └── admin-template.jade
│   ├── student
│   │   └── student-template.jade
│   └── teacher
│       └── teacher-template.jade

...or:

├── dashboard
│   └── roles
│       ├── admin
│       │   └── admin-template.jade
│       ├── student
│       │   └── student-template.jade
│       └── teacher
│           └── teacher-template.jade

Which is better in your opinion and why?

[DavidSouther]

as based on the role

If this is the design requirement, clearly the second is better (though I might go so far as to name the files admin-profile-template.jade, student-profile-template.jade; the template.jade is the only critical part).

If the design were merely to have three sections in the dashboard, the first option would make more sense.

[MatthewVita]

I agree with you.

As for your comment on the first option making sense if the design were to merely group the sections together in the dashboard... obviously this is not uncommon with partials, would the first option work with Rupert? (a "layout" feature directory with header-template.jade and footer-template.jade at the same level, for instance)

[DavidSouther]

No; rupert sees all template.jade files as equivalent within a directory. Sort of. Technically, what will happen is all the files will get put in the templateCache, but under the same name. Because stassets works as a mapreduce, the render phases (which build the $templateCache) don't know about eachother, so it's either use the entire template name, or use just the path name. All this can be changed by monkey-patching the wrap method, though. I'll have an example soon.

[MatthewVita]

I think this should be added to roadmap for us to work on because there are valid instances where it makes sense to have multiple templates at the same level. Do you agree?

[DavidSouther]

Yeah, it certainly does. Again, it's a pretty straightforward thing to do - more on the documentation roadmap, than an actual feature.

[MatthewVita]

Okay, I follow. Once you give me an example / point me in the right direction of how to do this, I can put this into the UI Router cookbook that I wrote or do you feel it should be somewhere else?

[DavidSouther]

Should be a different doc entry. I'm just going through some testing, give me half an hour.

[MatthewVita]

take your time

[DavidSouther]

https://github.com/RupertJS/rupert-config-angular/blob/master/src/config.js#L3-L31

[MatthewVita]

Dang, I just did a fresh install of Rupert w/ angular config and am now only seeing the generic window object format version of templates.js... if I understand correctly, the Angular config simply extends the template code's prototype to do templating the 'Angular way' with $templateCache. Something isn't right though... any ideas?

window.Templates = {};
Templates['zoo'] = '<h1>arctic</h1>';
Templates['zoo'] = '<h1>safari</h1>';

[DavidSouther]

Make sure rupert-config-angular is @0.0.6

On Tue Dec 30 2014 at 11:21:00 AM Matthew Vita notifications@github.com wrote:

Dang, I just did a fresh install of Rupert w/ angular config and am now only seeing the generic window object format version of templates.js... if I understand correctly, the Angular config simply extends the template code's prototype to do templating the 'Angular way' with $templateCache. Something isn't right though... any ideas?

window.Templates = {}; Templates['zoo'] = '

arctic

'; Templates['zoo'] = '

safari

';

— Reply to this email directly or view it on GitHub https://github.com/RupertJS/rupert/issues/13#issuecomment-68370305.

[MatthewVita]

https://github.com/RupertJS/rupert-config-angular/commit/7abd3f49918d0994560465ed63e0cea635357bd0 <- ah, I see.

Unfortunately, I'm running into this error after manually upgrading:

  Uncaught ReferenceError: angular is not defined
  at /laptop/projects/RupertTemplates/www/application.js:9

Chrome 38.0.2125 (Linux): Executed 0 of 0 ERROR (0.226 secs / 0 secs)

Warning: Task "karma:client" failed. Use --force to continue.

Aborted due to warnings.

...and if I look at www/vendors.js, I only see jQuery in there

[MatthewVita]

David, here's a PR for this: https://github.com/RupertJS/rupert-config-angular/pull/5/files

things are looking a bit better, but the keys are still ambiguous, fyi:

window.Templates = {};
angular.module('zoo.template', []).run(function($templateCache){$templateCache.put('zoo', '<h1>safari</h1>');});
angular.module('zoo.template', []).run(function($templateCache){$templateCache.put('zoo', '<h1>arctic</h1>');});

[DavidSouther]

Ok all cleaned up. Still need to do a new feature on stassets, but the issues you're seeing here and in rupert-config-angular should be resolved with 0.0.7 there (Rupert@0.2.7, stassets@0.3.8)

[DavidSouther]

What do you think of this:

1. Templates must have a known extension in the Template Renderer (Default HTML & Jade, must transpile to HTML, new renderers may be added).
2. Template file names end with template.<ext>, with <ext> from above.
3. Templates may have an arbitrary prefix, separated with a - eg <component>-template.<ext>.
4. The generated fragment name is
   1. The path within the client source folder, as determined by AssetWatcher::pathpart
   2. Except the suffix template.<ext>, and either the preceding - or / are dropped.
   3. If the template file prefix matches the parent directory name, the prefix gets dropped.

Examples:

• main/template.jade becomes main.
• main/content/content-template.html becomes main/content
• main/dashboard/panela-template.jade becomes main/dashboard/panela.

[DavidSouther]

Take a look at https://github.com/RupertJS/stassets/pull/27

[MatthewVita]

I love it! the main/template.jade -> main is a great and intuitive idea.

In regards to 1's 'new renderers may be added'... are there any other popular + mature HTML preprocessors out there that we should put on the roadmap? I know of https://www.npmjs.com/package/haml and https://github.com/twitter/hogan.js as other popular choices.

(edit: on second thought, it's kind of an interesting question since we're not making use of the JS templating controls in the renderers such as loops or variable replacement since the front-end framework/library is responsible for this, so things like hogan aren't that useful 'cause it's basically HTML in this context)

[DavidSouther]

we're not making use of the JS [...] things like hogan aren't that useful

That doesn't mean someone couldn't write rupert-config-hogan that would put the hogan render function, instead of the string HTML, as the result of the render call. At this point, however, I'm content with saying "when someone needs that, we will guide them on how to make it". I really want to focus on Rupert being a solid and stable base, rather than having every single feature.

[MatthewVita]

The same can be said for all of the template engines when a non-spa (templates initially rendered from the server that is) is required really. In time...

[DavidSouther]

Yep. I'm going to go ahead and release stassets with that merged in and close this issue.

[MatthewVita]

:smile:

[DavidSouther]

@MatthewVita would you be interested in getting the algorithm in https://github.com/RupertJS/rupert/issues/13#issuecomment-68445209 put into the docs at https://github.com/RupertJS/rupert/wiki/Cookbook:-Angular-UI-Router-Templates, then moving the angular-specific portions to the wiki in rupert-config-angular and link the two?

[MatthewVita]

k. give me a few

[MatthewVita]

updated angular wiki entry: https://github.com/RupertJS/rupert-config-angular/wiki/Cookbook:-Angular-UI-Router-Templates

'generic' base wiki entry: https://github.com/RupertJS/rupert/wiki/Cookbook:-Using-Templates

:+1:

[DavidSouther]

Merged the PR for the updated README. Thanks so many bunches!

[MatthewVita]

:+1: