In a nutshell, I keep finding forums on how to use the route prefixes, but I am wondering where it is in the source code that Laravel converts route prefixes into parameters that can be used in the views example: {customer_id}
It looks like on 794 of Illuminate/Routing/Route.php getPrefix() is used to get the prefix of the route instance; however, I'm not seeing where that is actually called.
I am trying to test a controller in Laravel 5.2 with PHPUnit/Mockery, Doctrine 2, and about 15 other dependencies. I have route prefixes of admin and customer that need to be pulled down as parameters. Everything on the live site works fine, so I know the actual code is correct. The other parameters work fine -- just not static prefixes. The tests worked great with Eloquent and had no problems converting the prefixes to parameters before my manager added a bunch of new dependencies. Now the prefix parameter returns null during testing on every test. One of the new dependencies broke something involved with testing--likely autoloading.
I could be looking in the wrong direction seeing how we are using so many dependencies that makes it extremely difficult to track down problems, but I've already found that Illuminate\Support\Facades\Route;
was autoloaded prior to the merge, and now it needs to be manually added to the testcase. I'm wondering if this isn't the same thing I need to do to get the route prefixes to work properly.
It looks like I was looking in the wrong place and converting the first static prefix to a variable was a new custom feature that parsed the route in helpers.php added by a coworker. That method was then called from middleware--which I had middleware turned off for testing, so the test never retrieved that first parameter.
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.
Creating in-repo-addon in Ember.JS gives a lot of possibilities. Today I've stumbled into a case when I wanted to register all classes in directory (for example my-dir) into Dependency Injector (same way it's done with services by Ember, but I wanted to use some other namespace).
For example I want to allow developer to create multiple classes inside proxy directory, and register all of them in DI under proxy: namespace. So later we can use:
Ember.Component.extend({
myProxy: Ember.inject('proxy:my'),
});
You'll need to do this using an initializer. More details on this here: https://guides.emberjs.com/v2.12.0/applications/dependency-injection/
The hard part may be getting all proxy items in s folder to automatically register ...
Edit
Looks like I didn't spend enough time thinking about this. You should be able to do at least part of this easily. There are two parts to this.
Part 1
Ember currently uses the ember-resolver to handle lookups for various items. If you check the tests for the resolver you'll notice that you should be able to map in anything you want: https://github.com/ember-cli/ember-resolver/blob/master/tests/unit/resolvers/classic/basic-test.js
So in your case, if you do a Ember.getOwner(this).lookup('proxy:main') from within an Ember instantiated class (a route, controller or component for instance) it would look in app/proxy/main.js which your addon could be populating.
Details on the Ember.getOwner lookup are available here: https://emberjs.com/api/classes/Ember.html#method_getOwner
Part 2
So at this point you can lookup proxies (which would be doable in an init method). But if we want to get truly elegant we'd want to allow Ember.inject.proxy('main') syntax.
Doing so would involve calling a private method inside of Ember.inject in an initializer. Because that naming scheme is changing in the new Javascript modules RFC, it may be unwise to try to add this syntactic sugar ...
So I'd advise avoiding touching that private API unless it's really important to your app design.
how can I use the controllers created at
/administrator/components/com_mycom/controllers/*
in
/components/com_mycom/mycom.php
In detail:
I have a »log« controller with an »add« method, and I would like to use this from the frontend. I one is not logged in in the backend the task is not executed and a 500 error rises. So just would like to include the backend controllerpath in the frontend, so that JController::getInstance( 'Mycom' ) still works.
Greetings…
EDIT:
After a long time of searching I could find a more or less undocumented Parameter of the:
JController::getInstance() method, namely the second one: $config = array(). Going through the source code I found out that there is one key of the »config-array« that is of interest, which is: »base_path«.
The call of:
JController:getInstance( 'Mycom, array('base_path' =>JPATH_ADMINISTRATOR.DS.'components'.DS.'com_mycom')' );
always delivers the backend controller and one can use them safely in the frontend, BUT one must take care that then also the views are taken from the backend side of the component. In my case, I just use it to make ajax-calls so it does not matter, but one needs to be careful with using this method when planning to create »frontend views« with »backend controller«.
Greetings…
I had recently a similar problem where I wanted to use the whole CRUD system form back-end also in front-end.
This is the method that worked for me (and I am not saying that this is recommended or best practice):
I've just modeled the folders / file structure from backend. PHP files contained something like:
require_once JPATH_ADMINISTRATOR . '/components/com_mycom/controllers/log.php';
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.
I'm creating a DB web application with grails for my company and found myself in the need to change the default scaffolding templates.
So far so good, everything gets generated with the modified templates (controllers, views, ..).
Now, however, I get a request to create some "composite screens" with functionalities and a layout that differ from the overwritten templates.
So now my question is: is it possible in grails to create one or more templates (next the the default one) and pass this template name as an argument to the generate-* commands?
Thanks in advance!
EDIT: Adding the template name to the generate commands was just an idea, if it's possible to do this a different way, I'll be happy too.
Grails commands are scripts in grails/scripts. If you follow its logic you will see two things.
1) There is only one parameter passed to the script → domain.
2) Class for generating views is DefaultGrailsTemplateGenerator. You can analyse sourcecode and check what this class offers.
Update
Link to DefaultGrailsTemplateGenerator in GitHub.
I am not sure about the generate command parameters, but if you add another .gsp page into scaffolding directory, I believe it will try to run it through generation process.
So for example I used to have a show.gsp page as well as showBasic.gsp page, which showed fewer properties.