-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Config writing gruidelines #21
Comments
I also believe we need a mandatory comment for each INI file. Something like a Another commenting and structuring guidelines would also help, like keeping primitive configurations on top and dependency arguments on bottom, both clearly identified as such. |
; Doctrine2.ini
; ... ini bla ble bli Foo bar
repo[] = Doctrine/phar ; Doctrine phar repository (Foundation-like) |
Main rationale for Use cases: repo[Doctrine] = doctrine/doctrine2/lib/Doctrine ; Points to the folder lib/Doctrine inside http://github.com/doctrine/doctrine2 repo[Doctrino] = git://example.com/sample.git/lib/Doctrino ; Points to the folder lib/Doctrino inside the repo on custom domain GitHub is the default, but any git could do the work. I've also added the key as a string that reflects the namespace we're importing. Dependencies could be tracked like this: repo[Zend\Dom] = framework/zf2/library/Zend/Dom ; This is a dependency
repo[Respect\Template] = Respect/Template/library |
We should ignore this Anyway we should write some guidelines to keep INI files shiny. |
+0 |
We should keep a nice and small subset of guidelines on wrtting INI files, mainly to be used as a requirement to make a INI a Respected, thought something like this:
The text was updated successfully, but these errors were encountered: