source: allow optionally specifying an extension for looking up source files #17

kellyredding · 2016-04-08T19:14:28Z

This helps when you have two files names the same thing but with
different extensions. Previously, only the first file globbed would
be rendered. This allows you to prefer rendering one over the other.

This scenario should have been covered in PR 16 but was missed.

Note: this also changes to have Nm complain if asked to render a named
template that doesn't exist (whether specifying an extension or not).
This makes for more friendly errors in this scenario.

See #16 for reference.

@jcredding ready for review.

This updates template sources to pass the extension that was used to register an engine to the engine as an option. The goal is to allow the engine to choose templates that match the extension that was used when configuring the extension. This is also part of fixing an issue with the engines not knowing which template file to pick because they no longer hard-code an extension that the templates have to use. The template source now always sets an ext option and passes it to the engines when they are registered. The ext will always be set and can't be different from how the engine is registered. It would be non-sensical to register with one engine ext and pass a different engine ext as an option. Sanford would either not use the registered engine to render the template or the template engine wouldn't find the file. Either case wouldn't produce the desired result. Specifically, this is part of fixing an issue with the nm template engine no longer forcing templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one sanford will now pass to the engine) to address this issue (redding/nm#17). Finally, this also renames "path" variables to "name" in the template source and engine. The variables are expected to be names and not full paths. This doesn't change any functionality it just clarifies the variable names.

jcredding · 2016-04-08T20:55:37Z

@kellyredding - Looks good 💥

This updates template sources to pass the extension that was used to register an engine to the engine as an option. The goal is to allow the engine to choose templates that match the extension that was used when configuring the extension. This is also part of fixing an issue with the engines not knowing which template file to pick because they no longer hard-code an extension that the templates have to use. The template source now always sets an ext option and passes it to the engines when they are registered. The ext will always be set and can't be different from how the engine is registered. It would be non-sensical to register with one engine ext and pass a different engine ext as an option. Sanford would either not use the registered engine to render the template or the template engine wouldn't find the file. Either case wouldn't produce the desired result. Specifically, this is part of fixing an issue with the nm template engine no longer forcing templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one sanford will now pass to the engine) to address this issue (redding/nm#17). Finally, this also renames "path" variables to "name" in the template source and engine. The variables are expected to be names and not full paths. This doesn't change any functionality it just clarifies the variable names.

This updates the template engine to pass its ext to nm source. The template engine ext is set by sanford when the engine is registered. This makes it so nm will use templates with the extension that was used when registering the engine with sanford. This is the expected behavior and avoids confusion with nm randomly not using a template that matches the registered extension. This is part of fixing an issue with sanford not rendering the expected nm template. This is because the nm engine no longer forced templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one sanford-nm will now pass to it) to address this issue (redding/nm#17).

This updates the template engine to pass its ext to nm source. The template engine ext is set by deas when the engine is registered. This makes it so nm will use templates with the extension that was used when registering the engine with deas. This is the expected behavior and avoids confusion with nm randomly not using a template that matches the registered extension. This is part of fixing an issue with deas not rendering the expected nm template. This is because the nm engine no longer forced templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one deas-nm will now pass to it) to address this issue (redding/nm#17).

This updates the template engine to pass its ext to nm source. The template engine ext is set by sanford when the engine is registered. This makes it so nm will use templates with the extension that was used when registering the engine with sanford. This is the expected behavior and avoids confusion with nm randomly not using a template that matches the registered extension. This is part of fixing an issue with sanford not rendering the expected nm template. This is because the nm engine no longer forced templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one sanford-nm will now pass to it) to address this issue (redding/nm#17).

This updates the template engine to pass its ext to nm source. The template engine ext is set by deas when the engine is registered. This makes it so nm will use templates with the extension that was used when registering the engine with deas. This is the expected behavior and avoids confusion with nm randomly not using a template that matches the registered extension. This is part of fixing an issue with deas not rendering the expected nm template. This is because the nm engine no longer forced templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one deas-nm will now pass to it) to address this issue (redding/nm#17).

This updates the template engine to pass its ext to nm source. The template engine ext is set by sanford when the engine is registered. This makes it so nm will use templates with the extension that was used when registering the engine with sanford. This is the expected behavior and avoids confusion with nm randomly not using a template that matches the registered extension. This is part of fixing an issue with sanford not rendering the expected nm template. This is because the nm engine no longer forced templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one sanford-nm will now pass to it) to address this issue (redding/nm#17).

kellyredding · 2016-04-09T01:34:35Z

@jcredding I've reworked this to have the source expect its files to end with any optional extension if one is given and to also be aware if the given template name already ends in the extension.

I'll make comments on what I've changed since you've looked at this and you can tell me what you think. Thanks man.

kellyredding · 2016-04-09T01:37:36Z

lib/nm/source.rb

-    def source_file_path(template_name)
-      Dir.glob(self.root.join("#{template_name}*")).first
+    def source_file_path(name)
+      Dir.glob(self.root.join(name.end_with?(@ext) ? name : "#{name}*#{@ext}")).first


@jcredding Here is where I make the glob expect the the template to end with the ext if one is present. Notice I default the ext to nil above. This allows me to not have to check whether an ext is present of not. If no extension is present, end_with? is false the the string interpolations means the glob ends up being name*.

Does this work for you?

@kellyredding - Yeah this looks like what we discussed. I didn't know end_with? was a thing. Nice.

kellyredding · 2016-04-09T02:03:55Z

lib/nm/source.rb

+          template_desc += " with #{@ext.inspect} as an extension"
+        end
+        raise ArgumentError, "#{template_desc} does not exist"
+      end


@jcredding here I add checking that a filename exists and raising a friendly argument error if not. I made the template description aware of any specified ext and if the given template name already ended with it.

@kellyredding - I'm good with the better error here.

jcredding · 2016-04-09T02:29:22Z

@kellyredding - I'm good with the changes. Thanks for working through what we discussed 💥

…e files This helps when you have two files names the same thing but with different extensions. Previously, only the first file globbed would be rendered. This allows you to prefer rendering one over the other. This scenario should have been covered in PR 16 but was missed. Note: this also changes to have Nm complain if asked to render a named template that doesn't exist (whether specifying an extension or not). This makes for more friendly errors in this scenario.

This updates the template engine to pass its ext to nm source. The template engine ext is set by sanford when the engine is registered. This makes it so nm will use templates with the extension that was used when registering the engine with sanford. This is the expected behavior and avoids confusion with nm randomly not using a template that matches the registered extension. This is part of fixing an issue with sanford not rendering the expected nm template. This is because the nm engine no longer forced templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one sanford-nm will now pass to it) to address this issue (redding/nm#17).

This updates the template engine to pass its ext to nm source. The template engine ext is set by deas when the engine is registered. This makes it so nm will use templates with the extension that was used when registering the engine with deas. This is the expected behavior and avoids confusion with nm randomly not using a template that matches the registered extension. This is part of fixing an issue with deas not rendering the expected nm template. This is because the nm engine no longer forced templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one deas-nm will now pass to it) to address this issue (redding/nm#17).

This updates the template engine to pass its ext to nm source. The template engine ext is set by sanford when the engine is registered. This makes it so nm will use templates with the extension that was used when registering the engine with sanford. This is the expected behavior and avoids confusion with nm randomly not using a template that matches the registered extension. This is part of fixing an issue with sanford not rendering the expected nm template. This is because the nm engine no longer forced templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one sanford-nm will now pass to it) to address this issue (redding/nm#17).

* source: allow optionally specifying an extension for looking up source files #17

This updates the template engine to pass its ext to nm source. The template engine ext is set by sanford when the engine is registered. This makes it so nm will use templates with the extension that was used when registering the engine with sanford. This is the expected behavior and avoids confusion with nm randomly not using a template that matches the registered extension. This is part of fixing an issue with sanford not rendering the expected nm template. This is because the nm engine no longer forced templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one sanford-nm will now pass to it) to address this issue (redding/nm#17).

This updates the template engine to pass its ext to nm source. The template engine ext is set by deas when the engine is registered. This makes it so nm will use templates with the extension that was used when registering the engine with deas. This is the expected behavior and avoids confusion with nm randomly not using a template that matches the registered extension. This is part of fixing an issue with deas not rendering the expected nm template. This is because the nm engine no longer forced templates extension to be `nm` (see redding/nm#16). By not expecting an extension, the nm engine can't pick the correct file as the template if there are multiple files with the same name except for their extensions. For example, a common pattern is to name a handler file and the template the same only the handler will have `.rb` for its extension and the template would use `.nm`. In this scenario, it's possible for the nm engine to try and use the ruby file as its template. Nm is being updated to use a custom extension (the one deas-nm will now pass to it) to address this issue (redding/nm#17).

kellyredding force-pushed the kr-opt-preferred-ext branch 3 times, most recently from 8e0c34a to bb55eab Compare April 8, 2016 19:20

jcredding mentioned this pull request Apr 8, 2016

Pass registered engine ext to engine as option redding/sanford#170

Merged

jcredding mentioned this pull request Apr 8, 2016

Pass sanford template engine ext to nm source redding/sanford-nm#6

Merged

jcredding mentioned this pull request Apr 8, 2016

Pass deas template engine ext to nm source redding/deas-nm#11

Merged

kellyredding force-pushed the kr-opt-preferred-ext branch from bb55eab to 2f211b6 Compare April 9, 2016 01:32

kellyredding reviewed Apr 9, 2016
View reviewed changes

kellyredding force-pushed the kr-opt-preferred-ext branch from 2f211b6 to f11cc03 Compare April 9, 2016 02:02

kellyredding reviewed Apr 9, 2016
View reviewed changes

kellyredding mentioned this pull request Apr 9, 2016

source: require named templates end in any given extension redding/deas-erubis#27

Merged

kellyredding force-pushed the kr-opt-preferred-ext branch from f11cc03 to 789cb9b Compare April 9, 2016 02:51

kellyredding force-pushed the kr-opt-preferred-ext branch from 789cb9b to 00dcc67 Compare April 9, 2016 15:14

kellyredding merged commit 1f6d760 into master Apr 11, 2016

kellyredding deleted the kr-opt-preferred-ext branch April 11, 2016 15:22

kellyredding added a commit that referenced this pull request Apr 11, 2016

version to 0.5.2

80086cf

* source: allow optionally specifying an extension for looking up source files #17

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

source: allow optionally specifying an extension for looking up source files #17

source: allow optionally specifying an extension for looking up source files #17

kellyredding commented Apr 8, 2016

jcredding commented Apr 8, 2016

kellyredding commented Apr 9, 2016

kellyredding Apr 9, 2016

jcredding Apr 9, 2016

kellyredding Apr 9, 2016

jcredding Apr 9, 2016

jcredding commented Apr 9, 2016

source: allow optionally specifying an extension for looking up source files #17

source: allow optionally specifying an extension for looking up source files #17

Conversation

kellyredding commented Apr 8, 2016

jcredding commented Apr 8, 2016

kellyredding commented Apr 9, 2016

kellyredding Apr 9, 2016

Choose a reason for hiding this comment

jcredding Apr 9, 2016

Choose a reason for hiding this comment

kellyredding Apr 9, 2016

Choose a reason for hiding this comment

jcredding Apr 9, 2016

Choose a reason for hiding this comment

jcredding commented Apr 9, 2016