AmyStephen · December 12, 2015 10:09 · Feb 11, 2013 · Feb 11, 2013 · Feb 11, 2013 · Feb 11, 2013
diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -118,7 +118,7 @@ It is a good idea to take time to think through the implications of how Composer
 
 ###Advice to achieve the minimum install path, possible
 * Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
-* If you cannot do that, specify the Vendorname/Packagename using the Composer *target_dir* parameter -or- build the Vendorname, Packagename values into your package repository folder structure as the first and second folders.
+* If you cannot do that, specify the Vendorname/Packagename (or, just "Vendorname", if appropriate) using the Composer *target_dir* parameter -or- the highest level(s) of your package repository folder structure.
 * Do not add folders to the "top" of your package repository that are not a part of your namespace. 
 * Remember, your entire repository is distributed; include only those files you wish to distribute.
 

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -3,7 +3,7 @@ PSR-0 and Composer
 
 It's helpful to understand how [Composer](http://getcomposer.org/) works and how to best utilize the environment as you implement your [PSR-0 Namespace](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md#examples). There are factors that you, where you, as a user of the environment, will not be able to change and you should be aware of those points. There are areas where your choices directly impact the folder path and the implementation of your namespace.
 
-##Composer Name Parameter##
+##1. Composer Name Parameter##
 
 The first data relevant to the package install path is the name you provide to Composer.
 
@@ -45,7 +45,7 @@ If you enter the same value for Vendor name as Package name, that value will sti
 
 It is important to remember that the purpose of this data is to enable Composer to use it as a key to locate and install packages. 
 
-##Composer target_dir parameter##
+##2. Composer target_dir parameter##
 
 Next, Composer uses the value entered as target-dir to extend the path and folder structure.
 

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -122,12 +122,16 @@ It is a good idea to take time to think through the implications of how Composer
 * Do not add folders to the "top" of your package repository that are not a part of your namespace. 
 * Remember, your entire repository is distributed; include only those files you wish to distribute.
 
-Following that advise, the minimum package install path looks like this:
+For vendors with multiple packages, the minimum package install path can look like:
 ```
 vendor/vendorname/packagename/VendorName/PackageName/Class
 ```
+For vendors with a single package, the minimum package install path can look like:
+```
+vendor/vendorname/packagename/VendorName/Class
+```
 
-Bear in mind, this will very likely seem confusing, perhaps even frustrating, at first. It's not a perfect situation and there are little things that would be nice if they were possible, like:
+Bear in mind, this could be confusing, perhaps even frustrating, at first. It's not a perfect situation and there are little things that would be nice if they were possible, like:
 
 * If the Composer name values were allowed in mixed case and then could be used as part of the namespace; 
 * If Composer did not use the same value for name twice in the path; 

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -117,14 +117,12 @@ Given good knowledge of the facts above, consider the best way to implement your
 It is a good idea to take time to think through the implications of how Composer works, how your package repository can be structured, and the impact of that software and those decisions on the implementation of the PSR-0 namespace.
 
 ###Advice to achieve the minimum install path, possible
-1. Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
-2. Assuming you cannot use the Composer *name* field, either:
-2.1. Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
-2.2. Or, build the Vendorname, Packagename values into your package repository folder structure as the first and second folders.
-3. Do not add folders to the "top" of your package repository that are not a part of your namespace. 
-4. Remember, your entire repository is distributed; include only those files you want to distribute.
-
-Following that advise, the minimum package install path would look like this:
+* Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
+* If you cannot do that, specify the Vendorname/Packagename using the Composer *target_dir* parameter -or- build the Vendorname, Packagename values into your package repository folder structure as the first and second folders.
+* Do not add folders to the "top" of your package repository that are not a part of your namespace. 
+* Remember, your entire repository is distributed; include only those files you wish to distribute.
+
+Following that advise, the minimum package install path looks like this:
 ```
 vendor/vendorname/packagename/VendorName/PackageName/Class
 ```

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -119,8 +119,8 @@ It is a good idea to take time to think through the implications of how Composer
 ###Advice to achieve the minimum install path, possible
 1. Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
 2. Assuming you cannot use the Composer *name* field, either:
-2.1 Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
-2.2 Or, build the Vendorname, Packagename values into your package repository folder structure as the first and second folders.
+2.1. Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
+2.2. Or, build the Vendorname, Packagename values into your package repository folder structure as the first and second folders.
 3. Do not add folders to the "top" of your package repository that are not a part of your namespace. 
 4. Remember, your entire repository is distributed; include only those files you want to distribute.
 

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -117,11 +117,12 @@ Given good knowledge of the facts above, consider the best way to implement your
 It is a good idea to take time to think through the implications of how Composer works, how your package repository can be structured, and the impact of that software and those decisions on the implementation of the PSR-0 namespace.
 
 ###Advice to achieve the minimum install path, possible
-* Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
-* Assuming you cannot use the Composer *name* field, either:
-**Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
-**Or, build the Vendorname, Packagename values into your package repository folder structure as the first and second folders.
-* Do not add folders to the "top" of your package repository that are not a part of your namespace. (And remember, your entire repository is distributed, so do not include files you do not wish to distribute.)
+1. Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
+2. Assuming you cannot use the Composer *name* field, either:
+2.1 Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
+2.2 Or, build the Vendorname, Packagename values into your package repository folder structure as the first and second folders.
+3. Do not add folders to the "top" of your package repository that are not a part of your namespace. 
+4. Remember, your entire repository is distributed; include only those files you want to distribute.
 
 Following that advise, the minimum package install path would look like this:
 ```

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -119,8 +119,8 @@ It is a good idea to take time to think through the implications of how Composer
 ###Advice to achieve the minimum install path, possible
 * Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
 * Assuming you cannot use the Composer *name* field, either:
-** Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
-** or, build the Vendorname, Package names into your package repository folder structure.
+**Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
+**Or, build the Vendorname, Packagename values into your package repository folder structure as the first and second folders.
 * Do not add folders to the "top" of your package repository that are not a part of your namespace. (And remember, your entire repository is distributed, so do not include files you do not wish to distribute.)
 
 Following that advise, the minimum package install path would look like this:

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -117,11 +117,11 @@ Given good knowledge of the facts above, consider the best way to implement your
 It is a good idea to take time to think through the implications of how Composer works, how your package repository can be structured, and the impact of that software and those decisions on the implementation of the PSR-0 namespace.
 
 ###Advice to achieve the minimum install path, possible
-1. Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
-2. Assuming you cannot use the Composer *name* field, either:
-* Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
-* or, build the Vendorname, Package names into your package repository folder structure.
-3. Do not add folders to the "top" of your package repository that are not a part of your namespace. (And remember, your entire repository is distributed, so do not include files you do not wish to distribute.)
+* Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
+* Assuming you cannot use the Composer *name* field, either:
+** Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
+** or, build the Vendorname, Package names into your package repository folder structure.
+* Do not add folders to the "top" of your package repository that are not a part of your namespace. (And remember, your entire repository is distributed, so do not include files you do not wish to distribute.)
 
 Following that advise, the minimum package install path would look like this:
 ```
@@ -130,9 +130,9 @@ vendor/vendorname/packagename/VendorName/PackageName/Class
 
 Bear in mind, this will very likely seem confusing, perhaps even frustrating, at first. It's not a perfect situation and there are little things that would be nice if they were possible, like:
 
-* if the Composer name values were allowed in mixed case and then could be used as part of the namespace; 
-* if Composer did not use the same value for name twice in the path; 
-* if Composer were able to install a package from a subfolder. 
+* If the Composer name values were allowed in mixed case and then could be used as part of the namespace; 
+* If Composer did not use the same value for name twice in the path; 
+* If Composer were able to install a package from a subfolder. 
 
 But, as is true with our own software, incremental improvements, code in hand, people willing to help solve problems, etc., is the way the things advance. Patience is always appreciated.
 

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -119,20 +119,20 @@ It is a good idea to take time to think through the implications of how Composer
 ###Advice to achieve the minimum install path, possible
 1. Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
 2. Assuming you cannot use the Composer *name* field, either:
-- Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
-- or, build the Vendorname, Package names into your package repository folder structure.
+* Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
+* or, build the Vendorname, Package names into your package repository folder structure.
 3. Do not add folders to the "top" of your package repository that are not a part of your namespace. (And remember, your entire repository is distributed, so do not include files you do not wish to distribute.)
 
 Following that advise, the minimum package install path would look like this:
 ```
 vendor/vendorname/packagename/VendorName/PackageName/Class
 ```
 
-Bear in mind, this will very likely seem confusing, perhaps even frustrating, at first. It's not a perfect situation. 
+Bear in mind, this will very likely seem confusing, perhaps even frustrating, at first. It's not a perfect situation and there are little things that would be nice if they were possible, like:
 
-* It would be nice, for example, if it were easier to reuse the Composer primary key as part of the namespace in mixed case. 
-* If Composer did not use the same value for name twice in the path. 
-* If one were able to install a package from a subfolder. 
+* if the Composer name values were allowed in mixed case and then could be used as part of the namespace; 
+* if Composer did not use the same value for name twice in the path; 
+* if Composer were able to install a package from a subfolder. 
 
 But, as is true with our own software, incremental improvements, code in hand, people willing to help solve problems, etc., is the way the things advance. Patience is always appreciated.
 

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -118,12 +118,12 @@ It is a good idea to take time to think through the implications of how Composer
 
 ###Advice to achieve the minimum install path, possible
 1. Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
-2. Assuming you cannot use the Composer *name* field:
-* Either specify the Vendorname/Packagename using the Composer *target_dir* parameter.
-* Or, build the Vendorname, Package name into your package repository folder structure.
-3. Do not add folders to your package repository that are not a part of your namespace or include files you do not wish to distribute. 
+2. Assuming you cannot use the Composer *name* field, either:
+- Specify the Vendorname/Packagename using the Composer *target_dir* parameter;
+- or, build the Vendorname, Package names into your package repository folder structure.
+3. Do not add folders to the "top" of your package repository that are not a part of your namespace. (And remember, your entire repository is distributed, so do not include files you do not wish to distribute.)
 
-Following that advise, a minimal package install path can look like this:
+Following that advise, the minimum package install path would look like this:
 ```
 vendor/vendorname/packagename/VendorName/PackageName/Class
 ```

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -5,7 +5,7 @@ It's helpful to understand how [Composer](http://getcomposer.org/) works and how
 
 ##Composer Name Parameter##
 
-The first data relevant to the package install path is the name provided Composer.
+The first data relevant to the package install path is the name you provide to Composer.
 
 ###What is the purpose of the name parameter?###
 
@@ -24,7 +24,7 @@ These values are used as a key to locate a package in the package repository. (M
 Composer uses the literal vendor and the two-part name to begin the install path to your package.
 
 ```
-    vendor/vendor-name/package-name
+vendor/vendor-name/package-name
 ```
 
 ###Examples###
@@ -111,19 +111,19 @@ vendor/vendor-name/package-name/Values/Provided/In/Target/Dir/Packagename/Folder
 ```
 
 ###Namespace Implications###
-Given good knowledge of the facts above, consider the best way to implement your namespace. There are ways to minimize the folder structure, if such is a concern. 
-
-There are ways to organize collections of software for those vendors with many packages. There is data needed by Composer to install your package with other software.
+Given good knowledge of the facts above, consider the best way to implement your namespace. There are techniques to minimize the folder structure, if such is a concern. There are ways to organize collections for those vendors with many packages. Just under, your package folder structure, as it is, will be used in the install path.
 
 ##Conclusion##
 It is a good idea to take time to think through the implications of how Composer works, how your package repository can be structured, and the impact of that software and those decisions on the implementation of the PSR-0 namespace.
 
 ###Advice to achieve the minimum install path, possible
 1. Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
-2. Do not use a value with *target_dir*. 
-3. Do not add folders to your package repository that are not a part of your namespace. Instead, make your root folder your first level of the namespace (assuming you are not able to use the Composer name value.)
+2. Assuming you cannot use the Composer *name* field:
+* Either specify the Vendorname/Packagename using the Composer *target_dir* parameter.
+* Or, build the Vendorname, Package name into your package repository folder structure.
+3. Do not add folders to your package repository that are not a part of your namespace or include files you do not wish to distribute. 
 
-Following that advise, a minimal package install path will look like this:
+Following that advise, a minimal package install path can look like this:
 ```
 vendor/vendorname/packagename/VendorName/PackageName/Class
 ```

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -121,7 +121,7 @@ It is a good idea to take time to think through the implications of how Composer
 ###Advice to achieve the minimum install path, possible
 1. Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
 2. Do not use a value with *target_dir*. 
-3. DO not add folders to your package repository that are not a part of your namespace. Instead, make your root folder your first level of the namespace (assuming you are not able to use the Composer name value.)
+3. Do not add folders to your package repository that are not a part of your namespace. Instead, make your root folder your first level of the namespace (assuming you are not able to use the Composer name value.)
 
 Following that advise, a minimal package install path will look like this:
 ```

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -118,7 +118,7 @@ There are ways to organize collections of software for those vendors with many p
 ##Conclusion##
 It is a good idea to take time to think through the implications of how Composer works, how your package repository can be structured, and the impact of that software and those decisions on the implementation of the PSR-0 namespace.
 
-###Advice to achieve the minimum install path, possible### 
+###Advice to achieve the minimum install path, possible
 1. Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
 2. Do not use a value with *target_dir*. 
 3. DO not add folders to your package repository that are not a part of your namespace. Instead, make your root folder your first level of the namespace (assuming you are not able to use the Composer name value.)

diff --git a/PSR-0 and Composer.md b/PSR-0 and Composer.md
@@ -0,0 +1,139 @@
+PSR-0 and Composer
+==================
+
+It's helpful to understand how [Composer](http://getcomposer.org/) works and how to best utilize the environment as you implement your [PSR-0 Namespace](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-0.md#examples). There are factors that you, where you, as a user of the environment, will not be able to change and you should be aware of those points. There are areas where your choices directly impact the folder path and the implementation of your namespace.
+
+##Composer Name Parameter##
+
+The first data relevant to the package install path is the name provided Composer.
+
+###What is the purpose of the name parameter?###
+
+Composer requires a two-part, lowercase name that serves as a unique key for installing the package.
+
+This two-part name represents the vendor name and the package name.
+
+You enter these values into the name parameter of your package composer.json file. 
+
+In many cases, the same value is used for vendor name and package name.
+
+These values are used as a key to locate a package in the package repository. (Most use Packagist for this purposes and match the name entered there.)
+
+###Install path and folders###
+
+Composer uses the literal vendor and the two-part name to begin the install path to your package.
+
+```
+    vendor/vendor-name/package-name
+```
+
+###Examples###
+
+```
+vendor/molajo/filters
+
+vendor/monolog/monolog
+
+vendor/symphony/http-foundation
+```
+
+###Relevance to Namespacing###
+
+Since the Composer name is required in lowercase, it is unlikely that you will find it is useful as a node in your package namespace.
+
+If you enter the same value for Vendor name as Package name, that value will still be used two times in the install path.
+
+It is important to remember that the purpose of this data is to enable Composer to use it as a key to locate and install packages. 
+
+##Composer target_dir parameter##
+
+Next, Composer uses the value entered as target-dir to extend the path and folder structure.
+
+A folder is created for each node in the target-dir value.
+
+```
+vendor/vendor-name/package-name/Values/Provided/In/Target/Dir
+```
+
+###Example:###
+
+```
+vendor/symphony/http-foundation/Symfony/Component/HttpFoundation
+```
+
+###Relevance to Namespacing###
+
+If your package folder structure does not contain the beginning of your namespace, you can use target-dir to add nodes needed to implement your namespace.
+
+If your package folder structure contains the entirety of your namespace (or if you were able to reuse the lowercase Composer name as the start of your namespace), you do not need to provide a value for target-dir.
+
+##3. Your Package Repository##
+
+Finally, Composer copies in the folders and files from your package repository at the current location of the install path.
+
+If you did not specify a target_dir, that location begins:
+
+```
+vendor/vendor-name/package-name/
+```
+
+If you specified a target_dir, that location begins:
+
+```
+vendor/vendor-name/package-name/Values/Provided/In/Target/Dir/
+```
+
+###Install Path Examples with Package Folder Inclusion###
+Each folder in your repository becomes a folder and part of the install path. If your package repository looks like this:
+
+```
+doc
+  etc
+src
+  Packagename
+		Folder1
+		Folder2
+		Folder3
+			Class1
+tests
+	etc
+```
+Path to Class1 if you did not specify a target_dir, that location begins:
+
+```
+vendor/vendor-name/package-name/src/Packagename/Folder3/Class1
+```
+
+Path to Class1 if you did specify a target_dir, that location begins:
+
+```
+vendor/vendor-name/package-name/Values/Provided/In/Target/Dir/Packagename/Folder3/Class1
+```
+
+###Namespace Implications###
+Given good knowledge of the facts above, consider the best way to implement your namespace. There are ways to minimize the folder structure, if such is a concern. 
+
+There are ways to organize collections of software for those vendors with many packages. There is data needed by Composer to install your package with other software.
+
+##Conclusion##
+It is a good idea to take time to think through the implications of how Composer works, how your package repository can be structured, and the impact of that software and those decisions on the implementation of the PSR-0 namespace.
+
+###Advice to achieve the minimum install path, possible### 
+1. Leverage the Composer *name* key, if you can use lowercase nodes in your namespace.
+2. Do not use a value with *target_dir*. 
+3. DO not add folders to your package repository that are not a part of your namespace. Instead, make your root folder your first level of the namespace (assuming you are not able to use the Composer name value.)
+
+Following that advise, a minimal package install path will look like this:
+```
+vendor/vendorname/packagename/VendorName/PackageName/Class
+```
+
+Bear in mind, this will very likely seem confusing, perhaps even frustrating, at first. It's not a perfect situation. 
+
+* It would be nice, for example, if it were easier to reuse the Composer primary key as part of the namespace in mixed case. 
+* If Composer did not use the same value for name twice in the path. 
+* If one were able to install a package from a subfolder. 
+
+But, as is true with our own software, incremental improvements, code in hand, people willing to help solve problems, etc., is the way the things advance. Patience is always appreciated.
+
+In the broader scheme of things, Composer and PSR-0 are ushering in a level of coordination that is quite remarkable and it is good that your work will now be a part.
No results found