If I'm writing a helper for an established library, should I create a TheirLibrary::MyHelper module in their namespace, or stay out and make my own ::TheirLibraryMyHelper?
I'm thinking to be predictably consistent, libraries often have precedent for adding extensions to their namespace, such as Spec::Rails, which is a plugin of rails helpers for RSpec, in the existing ::Spec namespace.
On the other hand, I don't feel I "own" the other authors namespace, so should I have any business adding sub-namespaces to it?
I would stay out of their namespace (whatever you end up choosing to name your extension namespace) because that means you aren't going to accidentally collide with something they decide to do down the road.
Looking around, I noticed that the convention for "plugin" or "extension" gems are required as:
require 'coolthing/plugin' which corresponds to the namespace Coolthing::Plugin
while other projects are
require 'coolthing-plugin' which corresponds to the unique namespace CoolthingPlugin
Generally only those that are "official" are embedded into the original namespace. Those that are follow-on additions from separate parties should use their own namespace.
Related
As far as I know, namespace is used for preventing class, function, ... collision in PHP. In Laravel 8 when we create a model for example, the name space is App\Models and when we want to use this model, we have to use it like use App\Models\MyModel. My question is when we use use Illuminate\Support\Arr, why we don't use the full path explicitly vendor\laravel\framework\......
It’s part of the PSR-4 auto loading standard which replaces the PSR-0 auto loading standard. Composer compiled an autoload.php from your project’s and dependencies’ composer.json. As part of the bootstrapping process that file is included in the application and registers each namespace.
I just downloaded Laravel 5 and started migrating to it. However, I find the required use of namespaces really annoying.
I don't feel like I am getting much from it, other than cluttering my code.
How can I disable the namespacing requirement?
I don't think you should disable or remove namespaces. The main reason for namespacing is to avoid conflicts with classes that have the same name. As soon as an application gets larger you will have classes that have the same name. Example from the Framework source:
Illuminate\Console\Application and Illuminate\Foundation\Application
Both are called the same. Only because of the namespacing you can import the right class. Of course you could also name them:
ConsoleApplication and FoundationApplication
But while the namespace normally is only used when importing a class at the top of a file:
use `Illuminate\Console\Application`
The name itself is used everywhere in the code. That's something that really clutters up your code, too long class names.
Besides the naming thing, namespaces also encourage better structure and help with knowing where your files are. That's because Laravel's default structure is PSR-4 compliant. That means if you have a controller App\Http\Controllers\HomeController you can be certain that you will find a HomeController.php under app/Http/Controllers.
I am aware of that, but it's not needed in the project I am working on.
Maybe it doesn't make sense for the current project but getting used to namespaces will help you tackle bigger projects in the future
And being a Sublime Text user, which doesn't have autoimport, it really gets to be a pain
I don't know Sublime Text that well, but CodeIntel might have auto import. Otherwise consider switching to another editor / IDE. I can highly recommend JetBrains PhpStorm
In the end, if you still don't want to use namespaces, keep using Laravel 4 or search for another framework that follows less good practices...
Removing namespaces from your app classes
While a totally don't recommend this, it is possible to at least remove some of the namespacing in your application.
For example the default controller namespace App\Http\Controllers can be changed to no namespace at all in RouteServiceProvider:
protected $namespace = '';
And for your models you can just remove the namespace in the file and your good. But keep in mind that without namespaces PSR-4 autoloading won't work anymore. You will have to autoload your files using classmap in composer.json
You can avoid using namespaces for own classes by defining them in the global namespace in your composer.json file. Like this:
"autoload": {
"psr-0": {
"": ["app/Http/Controllers/",
"app/models/",
"app/helpers"
]
},
You will also have to change your app/Providers/RouteServiceProvider.php to:
protected $namespace = '';
for routing to work.
This is probably a stupid question, but I'm new to Ruby on Rails and I could use a little guidance. I want to have a helper/utility class that performs a group of network operations and returns results. Where do I put that class and how do I use it.
I've created network_helper.rb in my app/modulename/helpers directory. In my controller when I try to do
myNetworkHelper = ModuleName::NetworkHelper.new
results = myNetworkHelper.getResults
I get an error
undefined method `new' for MyModule::NetworkHelper:Module
I'm sure this is just a misunderstanding of how ruby on rails works. Can I get some clarification?
Would it be better to make this a class instead of a module and put it in libs? And can I add subfolders in libs and have them automatically loaded?
Lib or Classes
Little utility classes like this typically go in the lib folder, though some people prefer to create a folder called classes. Whichever you choose, make sure you import the folder in config/application.rb, as the lib folder is not autoloaded:
config.autoload_paths += %W(#{config.root}/lib)
Concerns
If instead of a utility class, you want to extend some of your models with reusable code, you may also wish to look at the new Rails 4 concerns folders which encourage you to extract reusable modules:
see: How to use concerns in Rails 4
To use new, the thing your calling it on must be a class, not a module. You're using a module. Change module to class in lib/utilities/network_utility.rb.
I cannot verify this at the moment, however I believe one place you can store your custom modules and classes is the lib directory. Alternatively, you should be able to store them in the app directory in the manner you have indicated by adding the following line to your environment.rb:
config.load_paths << File.join(Rails.root, "app", "modulename")
Also, check out Yehuda Katz's answer, which I think not only answers your question better, but also contains some very interesting and useful information and concepts relating to your situation. Hope that helps!
Add your class to app/lib folder instead of lib, so that you don't change autoload paths!
Explanations:
The accepted answer suggests adding the classes to lib.
But according to this discussion:
The lib folder does not belong to the autoload paths since Rails 3.
So it's discouraged to add lib under autoload path. Use app/lib instead.
I have changed this question to better reflect what it is I do not understand.
For example if I try to access the methods in the railties class AppBuilder.
require 'rails/generators/rails/app/app_generator'
g = Rails::AppBuilder.new
puts g.rakefile.inspect
I get an error message activesupport-3.1.3/lib/active_support/secure_random.rb:5:in `': uninitialized constant SecureRandom (NameError)
I do not understand this. Should not each class be "independent" from other classes? Is that not the whole point of object oriented programing?
And now If it is not so more importantly how can I figure out what dependences I need to add? Is it some kind of workflow to solve this? Can I somehow figure out what dependencies to add looking at the documentation? Do this problem have something to do with load path? Can I load all dependences from a gem or rails or whatever? I just don't get it!
doc: http://api.rubyonrails.org/classes/Rails/AppBuilder.html github: https://gist.github.com/rails/rails/blob/master/railties/lib/rails/generators/rails/app/app_generator.rb
there is no easy way to find out which dependencies are used within AppBuilder, cause most of the dependencies are setup somewhere else. so most of the times you need to do some trial and error to get the dependencies right.
the code that you posted has bad style. please get familiar with how to write ruby code properly. buy yourself a book i.e. eloquent ruby or just start reading ruby blogs.
dependencies in ruby is quite simple. every file that you require will be loaded and the load will recurse through the files and then load other requires. the loading will only work if all the required files are on the load path. this load path is similar to your system path and you can add directories to it to tell ruby where to look for files.
in general, there are dedicated entry-points for libraries and their dependencies. those are normally documented, so that if you use them, you get all dependencies right from the beginning. an example for this would be to require 'rails' in order to use rails or require 'active_support/all' if you just want to use active-support. if you wan't to chery-pick files/classes than you are on your own finding out which other classes you need. that part has nothing to do with oop, it's more an dependency-issue (other languages have explicit decleration of dependencies).
in your case, the next step would be to add require "securerandom" to the beginning of your file and then check wich error comes up next.
I've written a command-line tool for manipulating with genome scaffolds called "Scaffolder". At the moment all the tools I want to use are hard-coded into the library. For instance these tools "validate" or "build" the scaffold. I'd like to split these tools out into their own gems, make it more modular, and to allow third parties to write their own commands.
The ideal case would be that I run "gem install scaffolder-validate" and this gem-bundled command would then be available as part of scaffolder. I know a couple of libraries make it easy to build a command-line interface: thor, commander, gli, .... However I don't think any of them cater for this type of functionality.
My question is how can I use a gem structure to create a module structure for installing these commands? Specifically how can the installed commands be auto-detected and loaded? With some prefix in the gem name scaffolder-* then searching rubygems? How could I test this with cucumber?
So, one thing you can do is to decide on a canonical name for your plugins, and then use that convention to load things dynamically.
It looks like your code is all under a module Scaffolder, so you can create plugins following the following rules:
Scaffolder gems must be named scaffold-tools-plugin-pluginname
All plugins expose one class, named Scaffolder::Plugin::Pluginname
That class must conform to some interface you document, and possibly provide a base class for
Given that, you can then accept a command-line argument of the plugins to load (assuming OptionParser):
plugin_names = []
opts.on('--plugins PLUGINS','List of plugins') do |plug|
plugin_names << plug
end
Then:
plugin_classes = []
plugin_names.each do |plugin_name|
require "scaffold-tools-plugin-#{plugin_name}"
plugin_classes << Kernel.const_get("Scaffold::Plugin::#{plugin_name}")
end
Now plugin_classes is an Array of the class objects for the plugins configured. Supposing they all conform to some common constructor and some common methods:
plugin_classes.each do |plugin_class|
plugin = plugin_class.new(args)
plugin.do_its_thing(other,args)
end
Obviously, when doing a lot of dynamic class loading like this, you need to be careful and trust the code that you are running. I'm assuming for such a small domain, it won't be a concern, but just be wary of requireing random code.
Hm, tricky one. One simple idea I have is that the main gem just tries to require all the others and catches the load error when they are not there and disables the respective features. I do this in one of my gems. If HighLine is present, the user gets prompted for a password, if it isn't there has to be a config file.
begin
require 'highline'
rescue LoadError
highline = false
end
If you have a lot of gems this could become ugly though...