Macros unnecessarily being referenced in apostrophe-templates

[abea]

This module reference is included in some import statements, but not all? Is it ever really necessary? In what contexts?

https://github.com/apostrophecms/apostrophe-open-museum/blob/eea3e464bb9799523d5dbc848512c62f6c87be89/lib/modules/apostrophe-search/views/empty.html#L1-L3

[boutell]

This is "cross module include" syntax. It will load that template from the `apostrophe-templates` module, not your module. If your template doing the importing/including lives in some other module, it's necessary to load stuff that lives in `apostrophe-templates/views`. An import without cross-module include syntax looks for the template in the inheritance tree of the current module. No module inherits from `apostrophe-templates`, so if that's where you've got stuff, you're going to have to cross-module include it. If you want to avoid cross-module syntax for shared stuff, you can put stuff in the folder specified by `viewsFolderFallback`, or you can put it in `apostrophe-module/views`, which everybody *does* inherit from. At the time A2 was designed, the consensus of the frontend team was that `apostrophe-module/views` was not intuitive, so `viewsFolderFallback` was born and mapped to project level `/views` in our sample projects, and we've generally been pretty happy with it. However, a template that is in `viewsFolderFallback` can be overridden by having one of the same name in your own module; that one will always win (that's why it's called a "fallback"). And maybe that's not what you want for these shared macros - maybe you want them to truly be a distinct namespace and not have any surprises due to inheritance. In which case, `apostrophe-templates/views` is not an unreasonable place to put them. And so the convention of using a cross-module include for them was born. Could just as easily be `project-macros/views` though.

…

On Wed, Jul 24, 2019 at 2:58 PM Alex Bea ***@***.***> wrote: This module reference is included in some import statements, but not all? Is it ever really necessary? In what contexts? https://github.com/apostrophecms/apostrophe-open-museum/blob/eea3e464bb9799523d5dbc848512c62f6c87be89/lib/modules/apostrophe-search/views/empty.html#L1-L3 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#95>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAH27I5EZYT57YJW3SS5L3QBCQ3XANCNFSM4IGTCEUQ> .

-- *Thomas Boutell, Chief Software Architect* P'unk Avenue | (215) 755-1330 | punkave.com

[abea]

That's generally what I thought. This project has these macros in the /views directory (the viewsFolderFallback), but they're referenced on some pages this way. I guess it works because the template looks for a macro in apostrophe-templates and when the file isn't there it continues up the tree and finds /views as the fallback. So this is getting to the same place an unconventional way.

What I'm generally getting then is that when the macro is not actually in lib/modules/apostrophe-templates/views then we should remove that module reference from the import statement. As an instructional project we should probably do that on Open Museum then.

Does that all sound right?

[boutell]

Oh, definitely! It can make sense but certainly not if the macro isn't actually there.

…

On Fri, Jul 26, 2019 at 11:29 AM Alex Bea ***@***.***> wrote: That's generally what I thought. This project has these macros in the /views directory (the viewsFolderFallback), but they're referenced on some pages this way. I guess it works because the template looks for a macro in apostrophe-templates and when the file isn't there it continues up the tree and finds /views as the fallback. So this is getting to the same place an unconventional way. What I'm generally getting then is that when the macro is not actually in lib/modules/apostrophe-templates/views then we should remove that module reference from the import statement. As an instructional project we should probably do that on Open Museum then. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#95>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAH27KB4OR5JPR75B6ELF3QBMJ4PANCNFSM4IGTCEUQ> .

-- *Thomas Boutell, Chief Software Architect* P'unk Avenue | (215) 755-1330 | punkave.com