I am trying to import many classes using one require statement. Is this possible?
I have the following file structure:
In my main.cr I have the following:
require "./module-a"
require "./module-b"
require "./module-c"
ModuleA.who_am_i()
ModuleB.who_am_i()
instanceB = ClassB.new
instanceB.who_am_i()
ModuleC.who_am_i()
instanceC = ClassC.new
instanceC.who_am_i()
When I run this program, I get the following:
Showing last frame. Use --error-trace for full trace.
In main.cr:9:13
9 | instanceB = ClassB.new
^
Error: undefined constant ClassB
Did you mean 'Class'?
exit status 1
ClassB is defined in the file module-b/module-b.cr. The fix would be to change the require statement to ./module-b/*. For module-c, I defined ClassC in its own file. Is there a way to import all classes with just 1 require statement? Or do I have to specify each class I want to require?
I am thinking if there is a javascript equivalent, where I define 1 index.js file in a folder that does multiple modules.export statements to export all functions and classes.
The following repl describes the whole setup...
Repl.it Link
Thanks for your help!
Thanks to the Crystal Programming community on Discord (worth joining - thanks to Blacksmoke16 and jack arthur from the server), I was able to come up with this solution:
main.cr
require "./**"
ModuleA.who_am_i()
ModuleB.who_am_i()
instanceB = ModuleB::ClassB.new
instanceB.who_am_i()
ModuleC.who_am_i()
instanceC = ModuleC::ClassC.new
instanceC.who_am_i()
Although it is not as elegant as Node, it does the job.
Thanks to #matthewm (on the Discord server):
This solution is requiring all the files and nested files starting
from the directory the file with the requires is in. One problem you
might run into with doing only that is that you are defaulting to the
require order of whatever crystal chooses. If you have a module_c that
depends on module_b but you do require ./**, Crystal might try to
require module_c before module_b and it will fail so you will need
either always require files directly and in the correct order or
require files individually before requiring everything at once:
require "./module_b"
require "./**" # files in here depend on module_b to be loaded first
Related
I'm writing API tests using Postman. I'm organizing them into folders by endpoint, and subfolders by test cases within the endpoint folders. There are multiple cases for each endpoint and for each case there are post calls that set up data prior the the csubject-endpoint call that I'm making assertions against.
I already have 100s of calls in this suite. The test runner, unfortunately, does not provide the folder names in its output, so it's difficult to see at a glance which particular case I am looking at when, for example, it reports a test fail.
Is there a convenient way to obtain the folder names for a given call in its test script? With this, I could prepend the case name to the test name, and that would make my tests vastly more readable.
I think a variable containing the current request path in the folder hierarchy would be the best, but for now I didn't find such a feature.
Instead I may suggest such a workaround solution:
In each folder prerequest scripts you set a variable:
pm.environment.set("folder", "folder1/folder1.1/")
the value of folder variable you have to maintain separately for each folder.
Then on a collection level you put a collection test like this:
pm.test("location: " + pm.environment.get("folder"), true)
After running your collection in the Runner you will get the output
from collection tests at the beginning of the test results for each request
showing the folder location.
The effort of setting folder variables pays off when you estimate the results of complex tests. I used to change the names of the requests but it is even more complicated.
UPDATE:
You can also find the info in results hovering over a gray shortcut of path on the left of the request status. A tooltip displays a full path, what in fact eliminates the need of the above solution if you only want to observe the results, but the solution can be useful if you want to make some logs containing the path.
I don't think that there is anything like that from within the application - The closet I can see is the pm.info.requestName function which references the request name that the test belongs too.
This is a basic use case but you could add this to the test name to give you a 'quick glance' and what was run against what request.
pm.test(`${pm.info.requestName} - Status code is 200`, () => {
pm.response.to.have.status(200)
})
If you take a look at Newman it might have something within the summary object that you could extract, in a script, to get the folder name but I've never done this.
Closest thing right now would be this:
I believe I included this in my logged bugs / feature requests out to their team.
Can anyone guide me towards the right direction as to where I should place a script solely for loading data into ndb. As I wish to upload all data into the gae ndb so that the application could perform query on it.
Right now, the loading of data is in my application. I wish to placed it separately from the main application.
Should it be edited in the yaml file?
EDITED
This is a snippet of the entity and the handler to upload the data into GAE ndb.
I wish to placed this chunk of code separately from my main application .py. Reason being the uploading of this data won't be done frequently and to keep the codes in the main application "cleaner".
class TagTrend_refine(ndb.Model):
tag = ndb.StringProperty()
trendData = ndb.BlobProperty(compressed=True)
class MigrateData(webapp2.RequestHandler):
def get(self):
listOfEntities = []
f = open("tagTrend_refine.txt")
lines = f.readlines()
f.close()
for line in lines:
temp = line.strip().split("\t")
data = TagTrend_refine(
tag = temp[0],
trendData = temp[1]
)
listOfEntities.append(data)
ndb.put_multi(listOfEntities)
For example if I placed the above code in a file called dataLoader.py, where should I call this script to invoke?
In app.yaml alongside my main application(knowledgeGraph.application)?
- url: /.*
script: knowledgeGraph.application
You don't show us the application object (no doubt a WSGI app) in your knowledge.py module, so I can't know what URL you want to serve with the MigrateData handler -- I'll just guess it's something like /migratedata.
So the class TagTrend_refine should be in a separate file (usually called models.py) so that both your dataloader.py, and your knowledge.py, can import models to access it (and models.py will need its own import of ndb of course). (Then of course access to the entity class will be as models.TagTrend_refine -- very basic Python).
Next, you'll complete dataloader.py by defining a WSGI app, e.g, at end of file,
app = webapp2.WSGIApplication(routes=[('/migratedata', MigrateData)])
(of course this means this module will need to import webapp2 as well -- can I take for granted a knowledge of super-elementary Python?).
In app.yaml, as the first URL, before that /.*, you'll have:
url: /migratedata
script: dataloader.app
Given all this, when you visit '/migratedata', your handler will read the "tagTrend_refine.txt" file that you uploaded together with your .py, .yaml, and so on, files in your overall GAE application, and unconditionally create one entity per line of that file (assuming you fix the multiple indentation problems in your code as displayed above, but, again, this is just super-elementary Python -- presumably you've used both tabs and spaces and they show up OK in your editor, but not here on SO... I recommend you use strictly, only spaces, never tabs, in Python code).
However this does seem to be a peculiar task. If /migratedata gets visited twice, it will create duplicates of all entities. If you change the tagTrend_refine.txt and deploy a changed variation, then visit /migratedata... all old entities will stick around and all the new entities will join them. And so forth.
Moreover -- /migratedata is NOT idempotent (if visited more than once it does not produce the same state as running it just once) so it shouldn't be a GET (and now we're on to super-elementary HTTP for a change!-) -- it should be a POST.
In fact I suspect (but I'm really flying blind here, since you see fit to give such tiny amounts of information) that you in fact want to upload a .txt file to a POST handler and do the updates that way (perhaps avoiding duplicates...?). However, I'm no mind reader, so this is about as far as I can go.
I believe I have fully answered the question you posted (though perhaps not the one you meant but didn't express:-) and by SO's etiquette it would be nice to upvote and accept this answer, then, if needed, post another question, expressing MUCH more clearly and completely what you're trying to achieve, your current .py and .yaml (ideally with correct indentation), what they actually do and why you'd like to do something different. For POST vs GET in particular, just study When should I use GET or POST method? What's the difference between them? ...
Alex's solution will work, as long as all you data can be loaded in under 1 minute, as that's the timeout for an app engine request.
For larger data, consider calling the datastore API directly from your own computer where you have the source. It's a bit of a hassle because it's a different API; it's not ndb. But it's still a pretty simple API. Here's some code that calls the API:
https://github.com/GoogleCloudPlatform/getting-started-python/blob/master/2-structured-data/bookshelf/model_datastore.py
Again, this code can run anywhere. It doesn't need to be uploaded to app engine to run.
I make an application writed in Rails, it's growing fast and I learning with it. But I'm don't understand about helpers.
application_helper.rb
module ApplicationHelper
# This file it's empty
end
users_helper.rb
module UsersHelper
def avatar
# Do something
end
end
customer_helper.rb
module CustomerHelper
# This file it's empty
end
Why in any customer's view can call avatar helper method on user helper module?
Then, why separate helpers in many files?
Thanks in advance.
P.S: Rails' version 4.
Because all helpers are included in all controllers, by default. The separate files are really just for logical separation in this scenario. You can change that behaviour though:
By default, each controller will include all helpers.
In previous versions of Rails the controller will include a helper
whose name matches that of the controller, e.g., MyController will
automatically include MyHelper. To return old behavior set
config.action_controller.include_all_helpers to false.
http://api.rubyonrails.org/classes/ActionController/Helpers.html
To add to Mike Campbell's answer:
Framework
As magic as it is, Rails is a set of files which are called
sequentially
These files hold classes, methods, etc; but they're still files.
And that means that when you run an action through Rails, it loads up
a series of other dependent files to help it run (that's what a
framework is)
The design of Rails is such that your helper methods are all
loaded each time you run an action. I don't know why, but it helps
administer the methods for different areas of your app
So to answer your question, there's no real reason why the helpers are split up, at least with Rails 4
When using sinatra-r18n to handle internationalisation, the r18n lib exposes a variable t for use within your helpers, routes and templates, as per these instructions.
I have written a simple unit test using rack-unit to confirm that some of my pluralisations work but the test throws an error claiming t is nil.
I've tried referencing it via app.t, MySillyApp.t (where MySillyApp is the name of my Sinatra app), MySillyApp.settings.t etc and none of them give me access to the t I need.
What I am trying to achieve is a confirmation that my translation files include all the keys I need corresponding to plurals of various metric units my app needs to understand. Perhaps there is a more direct way of testing this without going via the Sinatra app itself. I'd welcome any insight here.
I had similar task to check localized strings in my Cucumber scenarios.
I've made working example.
Here you can find how strings got translated.
This file halps to understand how to add R18n support to your testing framework:
require 'r18n-core'
...
class SinCucR18nWorld
...
include R18n::Helpers
end
As you can see instead of rack/unit I'm using RSpec/Cucumber, sorry.
Using DrupalUnitTestCase to unit test a Drupal module, fails. I probably forget something.
The test runs fine untill I create an instance of some class:
$foo = new FooBar();
In that case, Drupal decides to do some magic and attempts to call the database, in order to find some file in its registry.
Test PDOStatement->execute() failed: <em class="placeholder">PDOException</em>: SQLSTATE[42S02]: Base table [error]
or view not found: 1146 Table 'td_development.simpletest50921registry' doesn't exist: SELECT
filename FROM {registry} WHERE name = :name AND type = :type; Array
(
[:name] => FooBar
[:type] => interface
)
DrupalUnitTestCase, as opposed to DrupalWebTestCase do not set up a database, by design. So the reason why this fails is clear.
However, I don't want Drupal to go looking in a database when all I want is to create some instance. How to avoid Drupal looking up the file in its registry?
You probably can't.
The possibilities of using UnitTestCase as the parent class are very limited. As soon as you do anything that requires the database (and creating a new class does because the autoload features of Drupal 7 depend on the database), you have to use WebTestCase.
The only thing that might work is explicitly including all files that are required for that class to work. Because the autoload is only called if the class does not exist yet (could also be a class that your class uses or depends on). But that is relatively fragile and you will always have to include all these files manually in the correct order, which means that your unit tests depend on the inner workings of your class. Which isn't nice either.
You can also try this
spl_autoload_register('your_function');
if (function_exists('drupal_autoload_class')) {
spl_autoload_unregister('drupal_autoload_class');
spl_autoload_register('drupal_autoload_class');
spl_autoload_unregister('drupal_autoload_interface');
spl_autoload_register('drupal_autoload_interface');
}
This will move the Drupal autoload to the bottom and solve the problem.