|
ContributingToSubstruct
Guidelines for contributing to Substruct
Phase-Implementation IntroductionIf you'd like to add something to Substruct we'd love to see what you have to offer. Please follow the following guidelines when proposing any patch. Respect the original styleRespect the coding style of the original files you're editing. If a patch is submitted which doesn't satisfy the component's coding conventions, then either a committer will need to rewrite the submission or it will be rejected. Getting it right in this first place will save you having to rewrite it. Spaces Not TabsPLEASE NO TABS! The source should be indented using spaces rather than tabs. The standard indentation is 2 spaces per indent - but respect the number of spaces used by the original. Some IDEs include automatic source (re)formatting. If you use an IDE, please check that this feature is either disabled or set to use (2) spaces. If a patch is submitted which uses tabs rather than spaces, then either a committer will have to reformat it before it's applied or the patch will be rejected. Again, it's easier to get it right in the first place rather than have to reformat and resubmit your patch. Test CasesPlease include any tests required by your code changes. We expect that any patch should not break the existing tests, or cause them to fail. Patches with missing and/or broken tests will be rejected. All tests should pass when you run rake test:plugins:all PLUGIN=substruct Creating Patch FilesPlease create your patch against the latest revision of the files in the source code repository (TRUNK) since this makes the job of applying the patch much easier. If you don't have a version checked out, then check one out. If you have, then please do a fresh update before you make your changes. The patch should be in unified format. You can create a patch in this format (from Subversion) by using: svn diff File >> patchfile Try to give your patch files meaningful names. This makes it easier for developers who need to apply a number of different patches. Submitting your PatchPlease use our Issue tracker on Google Code to submit all patch files. Provide a clear description of what the patch file does, and why you're submitting it. Multiple files should be archived via zip, gzip, or tar. |
Is there any information on creating modules?
For those that doesn't know how to work with plugins very well, you can make changes made inside substruct reload automatically with something like that, creating an initializer and saying to reload it always:
/config/initializers/always_load_these_paths.rb
SUBSTRUCT_ROOT="#{RAILS_ROOT}/vendor/plugins/substruct" Dependencies.load_once_paths.delete("#{SUBSTRUCT_ROOT}/app/controllers") Dependencies.load_once_paths.delete("#{SUBSTRUCT_ROOT}/app/helpers") Dependencies.load_once_paths.delete("#{SUBSTRUCT_ROOT}/app/models") Dependencies.load_once_paths.delete("#{SUBSTRUCT_ROOT}/lib")steps: download substruct_xxx.tar.gz file tar -xzf substruct_xxx.tar.gz rm -rf vendor svn co http://substruct.googlecode.com/svn/trunk vendor # replace vendor with the SVN version rake db:create RAILS_ENV=test # if it fails, possibly remove the socket options from config/database.yml rake substruct:db:bootstrap RAILS_ENV=test # load up db # now you can run tests rake test:plugins:all PLUGIN=substruct
Errata for errors running rake substruct:db:bootstrap with the current tar.gz source and svn copy of the bleeding edge vendor/ directory when checked out. Sorry for such a long comment but I've seen too many where more hand holding and spoon feeding seems to be required so hope I covered it ok with violating any codes of conduct ;>)
Scenerio: Having built a couple sites with the Substruct framework, I like very much, I thought I'd dig deeper and work with the bleeding edge source in the svn pile. So I proceeded to get the latest tar.gz, delete the vendor/ dir and get the latest svn copy from the project source and then export the read-only copy to my local svn repo.
SVN stuff Start in my Projects directory where all my projects start by collecting the source. In the case of using the bleeding edge svn repo source for Substruct there's a couple steps. First set up a default svn repo tree as recommended in the Subversion docs.
Get the Substruct base from the links on the Substruct site. Download the released tar ball and untar to the Projects dir
Ready to import into your local svn repo now.
I create a new directory "work" from which I'll import the checked out copy into the Eclipse with Aptana 2 IDE I prefer to work with, your methods or environment will dictate what you do. This is where I perfer to leave the starting files in my Project dir, check in or import that normally into version control and then checkout in my work directory where the files are updated via work done in my IDE or other development environment or where our changes go until we decide a new commit is ready or a good idea.
Preliminary checks and a couple common errors others are seeing in purusing the Substruct threads.
Set RAILS_ENV 2.1.2 if not done in environment.rb. You can install rails 2.1.2 alongside another 2.3.5 or whatever if you haven't already using "gem install -v=2.1.2 rails"
Errors encountered 05012010
when first running rake substruct:db:bootstrap and script/server both fail
1)after running rake substruct:db:bootstrap --trace undefined method `map' for nil:NilClass? Rails::GemDependency?.add_frozen_gem_path
2)ran rake substruct:db:bootstrap --trace again and got the following error