The second part is about the order in the files and the head for "quite junior"
Part 1Your customer')
You must have a folder for each client, not related to the project you are currently doing for him. Inside this folder should be a folder for each project. Initially, you will only have a folder called website /, but soon you will also have folders such as logo /, reports /, competitive analysis /, etc. It also makes sense to put design files into this folder, probably creating for them subfolder design / or graphics /.
Do not open access to this folder for Apache. It will store sensitive information. Depending on the development tool used, you can choose to either keep the code in this folder, or move it beyond the site folder. You can call it code / or, if you think that for other projects there will be a separate code - website-code /. If most of your other projects are related to design or business, then probably there will be no code at all in them, except for a random script for which you don’t need a separate folder at all.
In addition to the client's working folder, you can also create a completely separate folder for documents that your client should not see. Surely you will regularly show the client documents related to work, and it is likely that at some point you will want to give him access to the entire folder (and some clients will ask about this: “And you can archive all my files and drop them to me ? I just want to make sure I have copies of everything. ") In order not to run the risk of accidentally sending them the file “10 things for which I hate them.doc”, put such files in a separate personal folder on the client.
In general, here is an example of the structure we just built:
YourBusiness/ Accounts/ Documents/ Customers/ bEat/ Minutes/ 10 , .doc Proposal.doc CustomerProjects/ bEat/ website/ ... .... code/ ... ... reports/ graphics/
Now let's talk about the “code /” and “website /” folders described above.IMAGES
There are two types of images (almost always): those that are part of the design, and those that are part of the content presented on the site. The latter should be located in the resource folder (or downloads, or multimedia), for example, in the pictures / subfolder. Design pictures, which are unlikely to be searched frequently, can be put in the images / folder.
If your design is a bit more complicated, you should have images for buttons, icons, navigation, page background, etc. In this case, you will soon have 10 to 20 images in this folder, so you should split it into subfolders. It would still be nice to have general-purpose images in the top-level folder, but at the same time, the subfolders will help control a huge number of your small files. Give files sensitive and easy-to-remember names, for example form-warning-icon.png.
STYLE TABLES
For most sites, style sheets should not be very large. For a small site or even for a larger site without a large number of different sections (each of which has its own design), you usually only need one file for CSS. In this case, you can simply call it main.css or styles.css.
Despite this, many people like to split style sheets into multiple files. There are several ways to do this. The most popular option is one table for markup, one for fonts and one for colors. The idea is not bad, but in practice it complicates management - you get bogged down in assigning a large number of classes 3 (or more) times, and tracking bugs can be a nightmare.
I think it's better to separate the styles for “markup” and “content”. "Layout" will include elements such as navigation, footers, sidebars, fields, sections. "Content" will include elements such as paragraphs, headings, quotes, lists, floating images, links. Going further, it makes sense to create a “form” style file. However, as content on the web becomes increasingly interactive, the line between forms and content is quickly erased.
Again, call things by their proper names, and therefore it is better to name these files layout.css, content.css and forms.css. If you decide to give them more inaccurate names, like presentation.css, model.css, page.css, you will have to think every time before deciding which file to open.
Sometimes it is useful to have separate CSS files for individual pages that have their own design requirements. But this may be more expensive, depending on the complexity of such a page. If you have to click on the tabs in the editor in the search for the desired CSS file for a particular element, it is probably better to simplify the CSS. It also doesn’t hurt to think about using Sass or LESS to make CSS more attractive and clean. You may also have separate style sheets for different multimedia files, and they certainly should be a separate file. Well, as usual, they should be given a sensitive name, for example, print.css.
If you have several CSS files, this is fine, but before you present them, combine them into one with an automated tool, otherwise your site’s download speed will be very sad. Do not combine your well-decomposed CSS manually. The computer itself is easily done with the help of a chess machine. You can use Minify (PHP) or Juicer (Ruby) for this.
JAVASCRIPT
Between the organization of files JavaScript and CSS for most sites have a lot in common. They have similar (but different) functions, they are both presented to the browser for interpretation, they both interact with the DOM (if used correctly), and they often interact with each other. JavaScript is often used to add functionality to the same set of elements that are used in CSS to create a style.
Usually you come to the fact that you have a JavaScript library file (jquery.js, mootools.js, etc.), several widgets (say, datepicker.js and dropdown.js) and several code files for each site (for example, my -image-slider.js). It definitely makes sense to store all this information in separate files, but you often have some JavaScript for sites, which makes sense to create only one file for it.
Put all these files in a folder called javascript /. If you use a third-party library like jQuery, you will rarely create such complex sites that you need to share this folder.
PATTERNS
Templates are not content, not code or presentation. Templates may include certain aspects of these elements, but only a bare hint of them, if used correctly. This should help develop a pattern of the skeleton. Your server code helps templates acquire content (content from databases, error messages, data field values, etc.), and the browser complements it with an aesthetic shell, allowing you to achieve the final result.
Of course, in your templates there can be a random piece of human-readable text, for example, for a button, a drop-down menu, and so on. This is normal - such text is usually closely related to the function on the page, and not to the content.
Put all the templates in the templates / folder. Despite the above, templates are really server-side code (they are sensitive), so make sure that they are not shared. If your site sends emails, then create in this folder several subfolders for plain text templates and email messages in HTML. If your site is more than just advertising, you will need a lot of templates for different pages and screens of your application. If you have a version of the site for smartphones, there should also be a separate subfolder for it. Create the appropriate structure of such subfolders. Here is a good example:
templates/ blog/ sidebar.tpl post.tpl comment.tpl emails-plaintext/ subscribe.tpl change-password.tpl emails-html/ subscribe.tpl change-password.tpl social/ twitter-feed.tpl facebook-sidebar.tpl mobile/ base.tpl contact.tpl customer-profile.tpl friend.tpl homepage.tpl reviews.tpl base.tpl contact.tpl customer-profile.tpl friend.tpl homepage.tpl reviews.tpl