Myslik/csharp-ember-handlebars

Handlebars Templates - Directory Organization & Naming

MilkyWayJoe opened this issue ยท 14 comments

Must add the ability to compile templates from within ~/scripts/app/templates/ taking the directory name under templates as part of the name.

A router defined as follows:

App.Router.map(function() {
    this.resource('products', function() {
        this.route('index');
        this.route('add');
        this.resource('product', { path: ':product_id' }, function() {
            this.route('index');
            this.route('edit');
        });
    })
});

Should have a director similar to the following

~/
 |_ scripts
        |_ app
             |_  templates
                        |_ product
                        |      |_ index.hbs
                        |      |_ edit.hbs
                        |_ products
                               |_ index.hbs
                               |_ add.hbs

should generate template names:

product/index
product/edit
products/index
products/add

Due to Ember Router's dsl, this approach (unfortunately) will likely not handle plurals in the same directory.

I would like to implement something along these lines before the end of the week.
Hoping for ideas/feedback

But according to this guide http://emberjs.com/guides/routing/defining-your-routes/ you also have routes product and products which can be used to serve some master template with another outlet where you can then insert your index and edit template. I named it default.hbs so it would be named accoring to parent directory.

So you propose that default.hbs gets renamed to the directory the file is in? Meaning, if I have a path ~/scripts/app/templates/products/default.hbs, the library pre-compiles to products?
Maybe we could do this, and also, if the file has the same name of the directory, the same rule could be applied?
So for ~/scripts/app/templates/products/products.hbs, the library pre-compiles to products as well

Exactly ๐Ÿ˜ƒ

๐Ÿ‘ Sounds like a plan.

I was waiting for that other merge to go up to keep working on something else without the reference to the lib source, and now that it's up I've got a few things in my plate; so I'll have to write something for the directory later this week and submit the PR.
If you already have something that does it, commit and let's see what we can improve.
Thanks

I've got something almost done for this but I've encountered some issues after I updated to Ember RC3. Should send PR tonight or tomorrow.

With the next update, it will check for subdirectories under ~/scripts/app/templates and append the subdirectory name directory to the template name. Subdirectories under a subdirectory will carry only the name of the immediate subdirectory and template name. Consider the following:

~/
 |_ scripts
     |_ app
         |_  templates
              |_ show
              |  |_ default.hbs
              |  |_ edit.hbs
              |  |_ remove.hbs
              |
              |_ shows
                 |_sidebar
                 |  |_actions.hbs
                 |
                 |_ shows.hbs
                 |_ add.hbs

The templates will be compiled as:

~/scripts/app/templates/show/default.hbs          => Em.TEMPLATES["show"]
~/scripts/app/templates/show/edit.hbs             => Em.TEMPLATES["show/edit"]
~/scripts/app/templates/show/remove.hbs           => Em.TEMPLATES["show/remove"]
~/scripts/app/templates/show/shows.hbs            => Em.TEMPLATES["shows"]
~/scripts/app/templates/shows/add.hbs             => Em.TEMPLATES["shows/add"]
~/scripts/app/templates/shows/sidebar/actions.hbs => Em.TEMPLATES["sidebar/actions"]

Note: Since nested resources templates (see table) don't carry the name of the parent resource, we will simply combine the name of the last directory and the template name. In the sample above, sidebar/actions won't include the parent directory shows. The developer must use Route#renderTemplate to properly load a view/template in the correct outlet when using this kind of scenario with multiple outlets.

For now, I'm keeping the replacement of dash to slash in template names:

~/scripts/app/templates/show-remove.hbs  => Em.TEMPLATES["show/remove"]

Let me know what you think.

Great to hear ๐Ÿ˜„

@Myslik Added updates to that comment. Any input is welcome.

I have only one comment. Why not just ignore the nested resources and have each resource as root directory under templates. This way it exactly follows the convention by Ember, because Ember does not include parent resource in the naming convention.

This is in place for cases where the developer wants to organize a subdirectory exactly like in the Router.map. For example, in a router like this:

App.Router.map ->
  @resource 'shows', ->
    @route 'add'
    @resource 'show', {path: ':show_id'}, ->
      @route 'edit'
      @route 'remove'

I might want to organize my templates like the following in order to match the structure in the router:

~/
  |_scripts
     |_app
         |_templates
            |_shows
               |_show
               |   |_default.hbs
               |   |_edit.hbs
               |   |_remove.hbs
               |
               |_shows.hbs
               |_add.hbs

And the template names keep the same naming convention

~/scripts/app/templates/shows/show/default.hbs  => Em.TEMPLATES["show"]
~/scripts/app/templates/shows/show/edit.hbs     => Em.TEMPLATES["show/edit"]
~/scripts/app/templates/shows/show/remove.hbs   => Em.TEMPLATES["show/remove"]
~/scripts/app/templates/show/shows.hbs          => Em.TEMPLATES["shows"]
~/scripts/app/templates/shows/add.hbs           => Em.TEMPLATES["shows/add"]

It would only make a difference if, for example, there was a sub directory under shows/show/ (3rd or more level deep), which would be handled via renderTemplate in a Route class, in order to manage the multiple outlets.

Note: Nothing stops the developer from creating a directory for shows and another for show in the same level under templates. This feature is purely for organization of template files.

Fair enough ๐Ÿ˜„

I have merged the PR from @MilkyWayJoe so closing this issue.

Updated NuGet published ๐Ÿฐ

๐Ÿ‘

I should have mentioned earlier, but maybe we could include the helpers (right now they're in the sample app) and a readme file to the nuget project that would be added to the users's project when they install the lib. What do you think?

Sounds like a plan.