Doctrine2 Classloader, how to load multiple directories with exact same namespace - classloader

Is it possible to load multiple directories under the exact same namespace like this?
$loader = new ClassLoader('DoctrineExtensions',
"/path/to/vendor/doctrine2-extensions-beberlei/lib");
$loader->register();
$loader = new ClassLoader('DoctrineExtensions',
"/path/to/vendor/doctrine2-extensions-srosato/lib");
$loader->register();
I have read the documentation but it seems that it supports specials cases and general cases only (say DoctrineExtensions\SpecialCase being the special case and DoctrineExtensions being the general case) but I want to have two general cases at once, is this currently feasible?

Impossible. Doctrine 2 ClassLoader follows the PSR #0 http://groups.google.com/group/php-standards/web/psr-0-final-proposal
This means we're straight to 1 NS === 1 Directory.
Regards,

Related

Can you require a whole set of modules or classes via one require statement?

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

Where in Source Code Does Laravel 5.2 Convert Route Prefixes to Parameters

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.

How do I remove entities in Doctrine 2?

How do I remove entities in Doctrine 2? I want to know how to do this through the command line and with PHP. Thanks!
Edit:
I'm not sure if I'm asking this question right (I'm new to Doctrine). I want to leave the Entity file in the directory, but I want to delete its table from the database. This stems from Zend based modular architecture where modules can be installed/uninstalled without the module directory being removed. If a module is uninstalled, I want its entities removed. The opposite is also true.
As far as I know, there is no way to do this. You have to manually remove associated database tables.
You can just remove \ORM annotation from entity if you want to exclude it from entity generation process.
I did some looking into Doctrine's API and eventually figured it out:
$classes = array();
$entityManager = ...
$classes[] = $entityManager->getClassMetadata('Entities\MyEntity1');
$classes[] = $entityManager->getClassMetadata('Entities\MyEntity2');
$classes[] = $entityManager->getClassMetadata('Entities\MyEntity3');
$classes[] = $entityManager->getClassMetadata('Entities\MyEntity4');
//Doctrine Schema Tool
$st = new Doctrine\ORM\Tools\SchemaTool( $entityManager );
$st->dropSchema($classes);
This will remove the tables associated with Entities\MyEntity1, 2, 3 and 4 from the database.
Also, using the exact same code above except the last line, the following methods are useful:
$st->createSchema($classes);
AND
$st->updateSchema($classes);
You can find all the info in Doctrine's documentation:
http://www.doctrine-project.org/projects/orm/2.0/api

Unit Testing Drupal with DrupalUnitTestCase fails on database-setup

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.

dynamic configuration with boost program_options

Is there a way to load a dynamic INI file like the one below.
[basic]
number_of_servers=3
[server1]
ip=10.20.30.40
password=sdfslkhf
[server2]
ip=10.20.30.41
password=sdfslkhf
[server3]
ip=10.20.30.42
password=sdfslkhf
Here the idea is that the servers that are defined here is very specific to the software's deployment; so the admin decides how many servers participate in the configuration.
Is there a way to handle this in boost program_options?
Another, potentially more standard way, would be like this:
[basic]
number_of_servers=3
[server]
name=server1
ip=10.20.30.40
password=sdfslkhf
[server]
name=server2
ip=10.20.30.41
password=sdfslkhf
[server]
name=server3
ip=10.20.30.42
password=sdfslkhf
This way you don't need to worry about undefined section names, and I think this style is more widely used as well (definitely it's how QuickFIX does it, in a way very similar to what I outlined).
And you can probably remove the number_of_servers entry, and just use the count() function to find how many server sections there are.
There is an optional bool parameter to allow for unregistered entries in the parse_config_file function. It's set to false by default. See the documentation here:
http://www.boost.org/doc/libs/1_45_0/doc/html/boost/program_options/parse_config_file_id991860.html
If you call this function with true then it will add any unregistered entries into the variables_map as strings. You can check whether they exist with the variables_map::count function.
I hope that helps.
Sure you can. The server sections have a pattern: just load all those matching the pattern into a list of servers.
The challenges I faced while resolving this was to make sure the sections are kept together and are no way mixed up.
In the end I relied on a options_description with the known/finite options and then using the parsed_options that come out of parse_config_file, I had to collect all unrecognized options ( collect_unrecognized ). Then I had to iterate it to pick the options in order.
Thanks every one for their contribution.