Rename _resources

[ajmueller]

_resources is a confusing name for those who aren't familiar with our structure. With a looming public release of this project, we should rename the _resources folder to something more standard across the industry. I recommended the name "assets" in our FED meeting. Let's discuss possible names.

[jbascue]

I don't feel that _resources would confuse anyone with any amount of technical aptitude.

Assets, however, is more appropriate and gets my vote.

[pc-pdx]

Assets seems to have an entirely different connotation (like PDFs and word DOCs) for the majority of uses i'm currently aware of. I honestly love [_resources] and it's the winner in my book.

[pgregorova]

When it comes to naming folders, I don't know how many times I wasn't sure what some of the new folders mean or may me containing. I came to find out that the best way it's to always look inside to find out.

I think the key here is that if we decide to rename it to something new, it should be the same across all projects company-wide moving forward (Sitecore, Drupal, etc.), to avoid confusions down the line. Whether we keep using _resources or assets, or something else.

I'd like for the folder to be at the top, so if "_" is bothering people, assets is something that I'd lean more towards to.

[kamsar]

I'm totally for dropping the _ at the very least (a hack to move that folder to the top in ancient IDEs). Kinda dig the Resources name though as the items within are all resources for the page we're loading.

Am fine with changing it, however. Most of the projects I've seen in the open source world seem to use /css and /js in the root as opposed to a separate folder for FED stuff (of course, for a multi-site install for Sitecore this would be e.g. /sites/foo/css). Some Node configs I've seen seem to favor placing build output from task runners in /dist. ASP.NET MVC inexplicably places CSS in /content and JS in /scripts.

I think if we're going to change it I'd vote for:

/ /scss /js /img /gulp /dist/css /dist/js /dist/img

Where the dist is the build output and the root folders are source.

Clay pwns Kam's mom.

[justinskolnick]

Why not make the directory's name and location dependent on the project type? Move the uncompiled src to the root (or near the root) and have it compile into a place and with a name the project's back-end framework likes, via an object mapping ideal output directories per project type. Sitecore gets things where it wants it, CakePHP gets things where it wants it, etc.

[ajmueller]

@pgregorova this is exactly why I sent the email to the whole tech department. We should definitely make this a company-wide change.

I like a combination of the recommendations by @kamsar and @justinskolnick. Justin and I were just chatting and he suggests we keep a single directory that contains our source. Having quick and easy portability of the file structure is something that would be good to keep.

[pc-pdx]

I am very much for a universal approach, standardization is key.

After having thought about it a bit more and considering passing conversation with @kamsar, i still like the segregation of the FED resources as we've historically done.

Portability does make a good argument. the nodes and bower and all that complied jazz does seem to warrant a re-consideration of our practices. FED oriented stuffs are progressing super-wicko-madd-crazy-fast right now and we shouldn't be cornered by tradition. I do very much argue for a single-point container unless there is a compelling reason to split - organization is key and i think that _resources does a great job for everything but angularjs SPAs (which is just it's own beast).

(fwiw)Granted it's usually a one time per instance affair, but having the [/resources/] parent folder is helpful for configuring EEtags and caching headers etc..

[InstyleVII]

I personally have never cared for the resources naming. Removing the and keeping resources would be alright in my book, assets however, as @pc-pdx stated could be confused with assets from a client (PDFs and Docs). Going off of @kamsar proposal I would suggest a separate folder altogether to host the distributed, compiled files.

Example 1 On your local you would have:

/uncompiled/scss /uncompiled/js /uncompiled/img /uncompiled/gulp

Then the compiled-to folders

/compiled/css /compiled/js /compiled/img

while on production you would only have the /compiled folder with all compiled files. Another option is to then take the two I have listed above and put them in a folder containing them, in which case I would suggest a structure as such.

Example 2 /resources/uncompiled/scss /resources/uncompiled/js /resources/uncompiled/img /resources/uncompiled/gulp /resources/compiled/css /resources/compiled/js /resources/compiled/img

This way in naming there is a clear indication of which folders house which code, because right now there is absolutely zero indication to someone who is just looking through of which contains the compiled code and which contains the uncompiled and in development code.

Yet another option is to rename 'src' to bin and swap the files from /src with the fiels in the root. This would actually mirror how .NET does things so that you end up with an interesting mirror. '/resources' would host all uncompiled files with all compiled files going into '/resources/bin'. This is actually a reverse of our current schema and another option for how to handle compilation.

In this schema the folder structure would be as such

Example 3 /resources/scss /resources/js /resources/img /resources/gulp /resources/bin/css /resources/bin/js /resources/bin/img

In this case compiled is inferred by the standard 'bin' name used across a lot of projects, so it doesn't need to be stated.

Either way a clear separation of compiled vs uncompiled (whether via clearer naming shown in my 1st and 2nd examples, or by mirrored structure as shown in my 3rd example) and a removal of the _ at the very least should be done.

[kamsar]

My vague recollection as to why right now the source files are in _resources/src was that Gulp had issues watching a relative parent path (e.g. ../css) but was fine with child paths. So it may not fly to have the main gulpfile.js anywhere other than higher in the tree than the source.

Given everyone's feedback so far I suggest something like this:

/resources/src (organized pretty much like it is today) /resources/dist (organized pretty much like /_resources is today - compiled output files the site uses)

or having separate root folders for compiled and uncompiled (thus maintaining separation as well as not nesting more deeply than older sites):

/resources (/_resources/src of today) /dist (/_resources of today)

edit: Third option:

/resources /resources/dist

Thoughts?

[ajmueller]

I second the option above of:

/resources/src /resources/dist

This keeps all files under one parent (resources) while separating the source files vs. the compiled files.

[InstyleVII]

The option has been seconded, now we must vote!

http://www.strawpoll.me/1992286

[kamsar]

This is a democracy? ;)

[ajmueller]

This is no democracy...

[isite-jenkins]

Great now I have this song stuck in my head… http://www.youtube.com/watch?v=ETgk56xT4Mk

From: Alex Mueller [mailto:notifications@github.com] Sent: Thursday, June 26, 2014 10:30 AM To: isitedesign/FED-Template-Engine Subject: Re: [FED-Template-Engine] Rename _resources (#21)

This is no democracy...

[https://camo.githubusercontent.com/779e06ee7035d6e138103990aa7bbfd4b13e91c0/687474703a2f2f63646e2e6d656d6567656e657261746f722e6e65742f696e7374616e6365732f353030782f35313639343932352e6a7067]https://camo.githubusercontent.com/779e06ee7035d6e138103990aa7bbfd4b13e91c0/687474703a2f2f63646e2e6d656d6567656e657261746f722e6e65742f696e7374616e6365732f353030782f35313639343932352e6a7067

— Reply to this email directly or view it on GitHubhttps://github.com/isitedesign/FED-Template-Engine/issues/21#issuecomment-47254841.

[InstyleVII]

In FED Meeting on 7/30:

• Directory name will be Assets
• Assets directory will contain:
  • src (contains source files)
  • dist (contains compiled files; is ignored .gitignore)

Future idea - config.js object with an output folder variable